I admit the premise is a little bizarre, but we are writing a project that involves embedding the small footprint version of Rhino into our applet. One of the unique "features" of running inside an applet is that the classloader makes a request to the host server whenever trying to load a class that it can't find inside the jar. Rhino generates a number of these spurious class requests and I am trying to figure out the best way to cut them down.
Currently, when I load Rhino, I see that the following classes are missing: org/mozilla/javascript/VMBridge_custom.class org/mozilla/javascript/jdk15/VMBridge_jdk15.class org/mozilla/javascript/JavaAdapter.class org/mozilla/javascript/optimizer/Codegen.class I realize that JavaAdapter and the Codegen classes are missing because the "smalljar" build took them out. I'm willing to ignore that problem for the time being. Looking at the VMBridges classes first, isn't it possible to load the appropriate VMBridge by detecting the java version instead of iterating through the possible classes to load? Perhaps the custom VMBridge class could only be loaded according to a system property? Second place where alot of class loading goes on is in NativeJavaPackage, basically every property access has to somehow decide if a property is a Java class or a Java package. Looking at the code, I see the strategy is to attempt to load the class first, and if that fails assume that the given name is a Java package. Seems reasonably enough, but is a poor choice when used in an applet environment. Might I suggest an alternate approach which is to assume that properties which start with a lowercase letter are package names, and properties that start with an uppercase letter are classes. This follows suns naming conventions and I have never seen any java code which does not follow such a convention. As a hack, I am currently making use of the ClassShutter facility to exclude class names which look like packages (according to the naming convention) This seems to have this intended result of never trying to load packages as a class, which prevents alot of unecessary hits on our webserver. Many thanks to the developers for all of their excellent work on this project. --joel [EMAIL PROTECTED] _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
