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

Delegator and StackOverflowError

2010-01-06T13:36:48Z

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

2010-01-06T06:42:01Z

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.

2010-01-05T06:35:48Z

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

2010-01-04T18:16:12Z

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

2010-01-04T18:01:14Z

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

2010-01-04T17:47:35Z

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

2010-01-04T16:07:19Z

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

2010-01-04T16:07:03Z

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

2010-01-04T16:02:30Z

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

Re: Caching wrapped objects in custom WrapFactory

2010-01-04T15:38:36Z

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

2010-01-04T15:34:07Z

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

Re: Caching wrapped objects in custom WrapFactory

2010-01-04T14:03:41Z

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

2010-01-04T13:54:17Z

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

2010-01-04T13:19:32Z

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

2010-01-04T13:32:17Z

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