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. So, yes, this could be refined by separating the caching in two - MemberBox[] objects are scope-independent, and more expensive to create, while JavaMembers are scope-specific and less expensive to create. Attila. On 2010.01.04., at 17:07, Johan Compagner wrote: > 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... > > But i guess the ClassCache attached to a scope is in purpose? > > johan > > > On Mon, Jan 4, 2010 at 17:02, Daryl Stultz <[email protected]> wrote: > >> On Mon, Jan 4, 2010 at 10:38 AM, Johan Compagner <[email protected] >>> wrote: >> >>> the thing is that JavaMembers could cache >> >> >> Could it, should it, does it? Is this a feature/implementation request? >> >> -- >> Daryl Stultz Attila. -- home: http://www.szegedi.org twitter: http://twitter.com/szegedi weblog: http://constc.blogspot.com _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
