Class cache of NativeJavaPackage

[Oliver Weise]

Hi all,

We use Rhino in an environment where the class loader that is used to load Java classes from JavaScript might change over time. It may also be that new versions of already available and used classes may become available over time.

We are evaluating what caches in Rhino prevent these new versions of classes to be used in JavaScript. We already found out about the org.mozilla.javascript.ClassCache instance at the top level scope where a simple clearCache() does the trick.

We however now encounter a problem if Java Classes are referenced and created via Java package expressions like:

var object = new Packages.my.package.containing.a.CustomClass()

As we see in the code every NativeJavaPackage object, responsible for representing a Java package in JS, has its own "class cache". It simply stores the retrieved sub-package/class as property slot on itself. This can be nicely seen in method NativeJavaPackage.getPkgProperty():

synchronized Object getPkgProperty(String name, Scriptable start,

                                       boolean createPkg)

    {

        Object cached = super.get(name, start);

        if (cached != NOT_FOUND)

            return cached;

        if (negativeCache != null && negativeCache.contains(name)) {

            // Performance optimization: see bug 421071

            return null;

        }

        ....

}

In order to also effectively clear this cache, I assume one would need to rebuild/clear it on the root package object "Packages" or would need to replace the root scope along with it altogether, which I think is rather heavy.

Is there any way to get rid of this package/class cache that I'm missing?

Thanks for any insight!

Oliver

[Greg Brail]

Haven't had the time to read the code in that area in detail yet -- Rhino has a longggg history and today there doesn't seem to be one person who knows all the corners of the code base.

I do know that the code base is very old and makes a bunch of assumptions about Java performance that might no longer be valid.

For instance, do we really need a package cache at all, given that class loading is a pretty fundamental part of Java these days?

Do you think you could try an experiment that disables the package cache and see what happens? Or if you have a use case I might be able to help you run some micro-benchmarks.

--
You received this message because you are subscribed to the Google Groups "mozilla-rhino" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mozilla-rhin...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Greg Brail | apigee | twitter @gbrail @apigee

[Oliver Weise]

Hi Greg, thanks for your answer, and sorry it took so long for me to follow.

I will try disabling the package cache once I have the necessary time to do so, I will ask then again, if that's ok with you. For now I have solved my problem by simply removing all slots on the "Packages" object when a manual cache flush is requested.

However, if there is something that needs to be cached it must be the test, if the property which is requested is actually a class, bc. when it is not it just assumes that a package is requested. And I think you have a point in questioning if this is really necessary nowadays.