mozilla.dev.tech.js-engine.rhino Google Group

Delegator and StackOverflowError

jpa...@gmail.com (Jarosław Pałka) — Wed, 06 Jan 2010 13:36:48 UT

Hi,
I tried to use Delegator class to implement some functionality on variable
assignment. I have my object that implements Scriptable and would like to
call additional functionality when instances of this objects are assigned to
variable. Here is a part of my JUnit test for this class.
final Context context = ContextFactory.getGlobal().ent erContext();

Ast FunctionNode types

neoalch...@gmail.com (NeoAlchemy) — Wed, 06 Jan 2010 06:42:01 UT

What classifies in AST package (if it makes a difference) as a
FUNCTION_EXPRESSION vs FUNCTION_STATEMENT vs
FUNCTION_EXPRESSION_STATEMENT? I have a list here on various function
statements.
function foo() {}
foo = function() {}
foo = new function() {}
foo : function() {}
What would these be classified? Also would it make a difference if

org.mozilla.javascript.EcmaError: ReferenceError: "ByteString" is not defined.

u...@mozilla-xp.com/ (terry) — Tue, 05 Jan 2010 06:35:48 UT

when exec js in java got the errors ,wonder why got such error and how to solve them
thanks!
---
frmsrcurl: [link]

Re: Caching wrapped objects in custom WrapFactory

da...@6degrees.com (Daryl Stultz) — Mon, 04 Jan 2010 18:16:12 UT

Wow, this is a bit deeper than I thought. Thanks for the details. What's
your opinion of this:
[link]
Is this an implementation of what you consider problematic/challenging or is
this something different?

Re: Caching wrapped objects in custom WrapFactory

szege...@gmail.com (Attila Szegedi) — Mon, 04 Jan 2010 18:01:14 UT

Normally, it doesn't. I myself have a system that uses this approach that churns over a million script executions per day and encounters no problems. The problem is, you'll hardly be able to completely lock down the shared scope - while you can not easily put anything into it, you can, say, have one script extend or replace functions of standard objects (i.e. Array.push = function() { ... } - you get the idea) and have it be observed by all others. You can, of course, go through the full reachable JS object graph in the shared scope by recursively calling getIds() and then call ScriptableObject.seal() on every one of them.

Re: Caching wrapped objects in custom WrapFactory

szege...@gmail.com (Attila Szegedi) — Mon, 04 Jan 2010 17:47:35 UT

There could be some further separation of scope-independent data (basically, the MemberBox objects obtained through reflection, i.e. actual java.lang.reflect.* objects) and scope-dependent data (JavaMembers instances).
Yes, ClassCache attached to a scope is on purpose since it has the Class->JavaMembers map. JavaMembers has a bunch of NativeJavaMethod instances, which are JavaScript functions (they extend BaseFunction), and as such need to answer true to "instanceof Function", hence they are scope specific, as they bind their prototype to the object returned by the expression "Function.prototype" in that scope.

Re: Caching wrapped objects in custom WrapFactory

jcompag...@gmail.com (Johan Compagner) — Mon, 04 Jan 2010 16:07:19 UT

it could do it (doesnt do it)
At least not the code i look at currently (still using 1.6R7)
But then if we cache that reflection in a static weakhashmap<Class,xxxx>
we could just not get it from the top level scope ClassCache but directly
internally so what JavaMembers do have a private static
WeakHashmap<Class,JavaMembers> member...

Re: Caching wrapped objects in custom WrapFactory

da...@6degrees.com (Daryl Stultz) — Mon, 04 Jan 2010 16:07:03 UT

This page:
[link]
under "Sharing Scopes" states "for our purposes it gives us an easy way to
share a set of read-only variables across multiple scopes". Is this section
describing the "shared-prototype top-level scope pattern" you dislike? Your

Re: Caching wrapped objects in custom WrapFactory

da...@6degrees.com (Daryl Stultz) — Mon, 04 Jan 2010 16:02:30 UT

Could it, should it, does it? Is this a feature/implementation request?

Re: Caching wrapped objects in custom WrapFactory

jcompag...@gmail.com (Johan Compagner) — Mon, 04 Jan 2010 15:38:36 UT

the thing is that JavaMembers could cache the reflect stuff inside itself in
a WeakHashmap
So that it doesnt have to do the reflection over and over again.
Then it should not matter if there is a ClassCache or not.

Re: Status and Future of Rhino

travis.en...@gmail.com (Travis Ennis) — Mon, 04 Jan 2010 15:34:07 UT

Norris,
Thanks for the update. Are these latest features available in the CVS
repository?
Thanks,
Travis

Re: Caching wrapped objects in custom WrapFactory

da...@6degrees.com (Daryl Stultz) — Mon, 04 Jan 2010 14:03:41 UT

Thanks, Attila, this is good information I'll file away until I get the time
to address performance.

Re: Caching wrapped objects in custom WrapFactory

szege...@gmail.com (Attila Szegedi) — Mon, 04 Jan 2010 13:54:17 UT

Caching is performed once per class and top-level scope, and results stored in an instance of ClassCache that is associated with the topmost scope.
As an implication, if you use a new top-level scope for every script execution (which you normally do), you'll end up with the cache being recreated on a per-scope basis. If you use a shared-prototype top-level scope, you'll avoid this (but then you have to use shared-prototype top-level scope pattern, which I generally dislike).

Re: Caching wrapped objects in custom WrapFactory

da...@6degrees.com (Daryl Stultz) — Mon, 04 Jan 2010 13:19:32 UT

My concern was not memory use but the expense of method lookups via
reflection. I imagine Rhino does a lot of caching of the lookups, then?

Re: JSON.parse() problem

christian.gri...@nexthink.com (Christian Grigis) — Mon, 04 Jan 2010 13:32:17 UT

Works great.
Thank you Raphael and Norris for the very prompt response!
-Christian