Launchpad has imported 13 comments from the remote bug at http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=179.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2008-08-05T15:33:19+00:00 Mark J. Wielaard wrote: The current setup of the javax.scripting engine that handles javascript through rhino depends on having all the rhino classes on the bootclasspath. See: http://mail.openjdk.java.net/pipermail/build-dev/2008-June/001176.html The problem is that the current javax.scripting javascript engine relies on all of the rhino classes being on the bootclasspath. This interferes badly when someone tries to compile their own rhino with possible different signatures (because the version on the bootclasspath is picked up first). See: http://www.openoffice.org/issues/show_bug.cgi?id=91641 To work around this the javascript engine needs to refactored to use a separate classloader to load the rhino classes. Reply at: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149/comments/0 ------------------------------------------------------------------------ On 2008-10-15T15:56:50+00:00 Mark J. Wielaard wrote: So, as a workaround for now, when you want to use a non-system installed rhino, instead of using: -classpath /path/to/local/rhino.jar use: -Xbootclasspath/p:/path/to/local/rhino.jar Reply at: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149/comments/7 ------------------------------------------------------------------------ On 2008-12-04T13:55:23+00:00 Hannes Wallnoefer wrote: I've thought about this a bit, and I think the only reasonable way to fix it (short of repackaging rhino with the jvm like Sun does) is to have the RhinoScriptEngine implementation bundled with the Rhino classes instead of the jre library. If rhino.jar is loaded though a custom classloader and the ScriptEngine sits on the jvm side, it has to go through reflection API for each interaction with Rhino, which is painful to say the least. If, OTOH, the ScriptEngine(Factory) is loaded by the same classloader as rhino.jar all that is needed are a few lines of class loading and casting. Bundling a ScriptEngine implementation with rhino would have a number of other advantages, like allowing people to use a more cutting edge Rhino version than the one bundled with the jvm (maybe using alternative name/mimetype/extensions to avoid clashes with Sun's internal rhino engine). The easy way to get there would be to import the openjdk rhinoengine code into rhino, but I doubt the GPLed code is compatible with Rhino's MPL1.1/GPL2 dual license. As an alternative, implementing a ScriptEngine withing Rhino looks like a viable alternative. Reply at: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149/comments/9 ------------------------------------------------------------------------ On 2008-12-04T13:59:48+00:00 Hannes Wallnoefer wrote: Of course, a related approach would be to split the Rhine engine implementation out of rt.jar into a separate jar file and load that with the same classloader as rhino.jar. Being a Rhino developer I just tend to think the other way around :-) Reply at: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149/comments/10 ------------------------------------------------------------------------ On 2009-12-09T02:49:09+00:00 Kohsuke-kawaguchi wrote: The change proposed in #3 isn't happening in Rhino after one year. And while it's a sensible change on its own from Rhino side, it's not a good fix for this bug, since it has a compatibility problem, in that applications that are using older Rhino.jar will break if IcedTea once removes its copy of rhino.jar (in favor of RhinoScriptEngine in rhino.jar in the user space.) So I recommend the package renaming. While it's not a very smart solution, it results in the best overall user experience. I've been involved in XML technologies that are integrated into JDK, so I hope it helps add some credibility to what I'm saying. As I explained in the bug http://bugs.sun.com/view_bug.do?bug_id=6876736 , this issue is biting a number of projects, including my Hudson, and unfortunately I have to recommend people to switch to Sun JDK. A timely resolution of this issue is much appreciated. Reply at: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149/comments/15 ------------------------------------------------------------------------ On 2010-01-14T01:44:10+00:00 Gnu-andrew-n wrote: I'm afraid it's not as simple as that. IcedTea doesn't package Rhino, it uses the system installed version. So to have the packages renamed, you'd need the system installation of Rhino to be patched in that manner. We don't want to be maintaining our own fork of Rhino within IcedTea. I think we need to look at a solution whereby Rhino is loaded with a lower priority classloader that can be overridden. An interim solution, other than the -Xbootclasspath setting suggested by Mark, would be to remove the symlink from the JDK install. Reply at: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149/comments/17 ------------------------------------------------------------------------ On 2010-01-15T13:08:05+00:00 Hannes Wallnoefer wrote: Regarding my proposal in comment #2 of including the ScriptEngine implementation in Rhino: I've done some work on this in Rhino using the code from scripting.dev.java.net, but unfortunately ran into some erratic behaviour when selecting scripting engines (see my last comment on that bug) https://bugzilla.mozilla.org/show_bug.cgi?id=379385#c3 (In reply to comment #5) > We don't want to be maintaining our own fork of Rhino within IcedTea. I think > we need to look at a solution whereby Rhino is loaded with a lower priority > classloader that can be overridden. > > An interim solution, other than the -Xbootclasspath setting suggested by Mark, > would be to remove the symlink from the JDK install. Yes, this would be the best solution - if it is feasible, which I'm not sure about. I would welcome any efforts in that direction from OpenJDK developers. I tried hacking the OpenJDK scripting engine code myself at one time, but was a bit overwhelmed by its build system (and build times). I agree with Kohsuke that this is seriously hurting projects using their own version of Rhino. Reply at: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149/comments/18 ------------------------------------------------------------------------ On 2010-02-07T11:38:26+00:00 Gnu-andrew-n wrote: Instead of just symlinking the system Rhino JAR, we need to create a copy with the alternate namespace of com.sun.org.mozilla. That means rewriting the class files so we need to look for an appropriate solution for doing this. Reply at: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149/comments/23 ------------------------------------------------------------------------ On 2010-02-13T14:48:34+00:00 Mark J. Wielaard wrote: (In reply to comment #7) > Instead of just symlinking the system Rhino JAR, we need to create a copy with > the alternate namespace of com.sun.org.mozilla. That means rewriting the > class files so we need to look for an appropriate solution for doing this. It would be better to load it through a separate class loader (not the extension class loader, which is used now because the symlink is in the ext lib path) so you don't need to make any copies and it never is seen on the source compiler/bootstrap path. Having the ScriptEngine added to rhino itself as suggested in comment #2 would make that easy. The trouble with creating a copy and rejiggering all the package names is that you will have a separate copy that you will need to keep in sync with the distro supplied one some way. Double the effort on security and bug fixes. Reply at: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149/comments/24 ------------------------------------------------------------------------ On 2010-02-17T23:27:30+00:00 Gnu-andrew-n wrote: Mark, I agree it's not an ideal solution but I'd rather we had _a_ solution than none at all. This bug has been open for over eighteen months. Long term, of course it would be better to see the necessary upstream changes in Rhino and OpenJDK to provide a cleaner solution. But for now, the rewriter is in IcedTea6 and it now uses a jar file rewritten to the sun.org.mozilla namespace. http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=4ac1082a1626 Given rewriting the jar file is just two fairly independent Makefile targets and a AGPL 3 licensed Java file, it could easily be used by distros in their Rhino packages so that both jars are updated together. This will appear in IcedTea6 1.8. It may also be worth considering backporting it to the 1.7 branch if there is sufficient demand for a fix. Reply at: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149/comments/25 ------------------------------------------------------------------------ On 2010-02-17T23:58:17+00:00 Hannes Wallnoefer wrote: Thanks a lot for fixing this, Andrew! I'm looking forward to being able to run and compile our code with OpenJDK without resorting to obscure command line switches. For the record, I actually have started to work on a patch that includes the ScriptEngine with Rhino: https://bugzilla.mozilla.org/show_bug.cgi?id=379385#c5 The only problem (and the reason it hasn't been committed yet) is some strange non-deterministic behaviour in which rhino engine is chosen. I haven't gotten to the bottom of this, my guess is that the script engine selection algorithm just isn't prepared to deal with multiple engines with the same name. In case somebody wants to tackle the custom classloader approach, another solution would be to place the script engine implementation in a dedicated jar file that is not on any system class loader, e.g. jsr223-rhino.jar, and use the custom class loader to load that and the rhino jar. You definitely want the script engine implementation to be loaded with the custom class loader in order to use the javax.script interfaces to drive it. If only Rhino itself is loaded via custom classloader, you'd have to implement the script engine via reflection, which wouldn't be much fun. Reply at: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149/comments/26 ------------------------------------------------------------------------ On 2010-02-18T00:15:13+00:00 Hannes Wallnoefer wrote: (In reply to comment #9) > This will appear in IcedTea6 1.8. It may also be worth considering > backporting > it to the 1.7 branch if there is sufficient demand for a fix. Assuming backporting to 1.7 would help the patch to find its way into distributions like Debian testing or Ubuntu Lucid that would be greatly appreciated. Reply at: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149/comments/27 ------------------------------------------------------------------------ On 2010-02-21T16:29:56+00:00 Gnu-andrew-n wrote: Targetting for 1.7.1 Reply at: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/255149/comments/30 ** Bug watch added: OpenOffice.org Issue Tracker #91641 http://qa.openoffice.org/issues/show_bug.cgi?id=91641 ** Bug watch added: Mozilla Bugzilla #379385 https://bugzilla.mozilla.org/show_bug.cgi?id=379385 -- You received this bug notification because you are a member of OpenJDK, which is subscribed to openjdk-6 in Ubuntu. https://bugs.launchpad.net/bugs/255149 Title: javascript script support through rhino should not be on bootclasspath Status in openbravo: Confirmed Status in OpenJDK: Fix Released Status in “openjdk-6” package in Ubuntu: Fix Released Bug description: I'm trying to run a custom rhino to build Dojo, but OpenJDK keeps ignoring the rhino in the jar file I provide and keeps loading rhino from the system libs: $ java -verbose:class -jar ../shrinksafe/custom_rhino.jar ... [Opened /usr/lib/jvm/java-6-openjdk/jre/lib/rhino.jar] [Loaded org.mozilla.javascript.tools.shell.Main from /usr/lib/jvm/java-6-openjdk/jre/lib/rhino.jar] [Loaded org.mozilla.javascript.ContextFactory from /usr/lib/jvm/java-6-openjdk/jre/lib/rhino.jar] [Loaded org.mozilla.javascript.tools.shell.ShellContextFactory from /usr/lib/jvm/java-6-openjdk/jre/lib/rhino.jar] ... If I specify a classpath, it still loads from the system rhino library: $ java -classpath ../shrinksafe/ -verbose:class -jar ../shrinksafe/custom_rhino.jar ... [Opened /usr/lib/jvm/java-6-openjdk/jre/lib/rhino.jar] [Loaded org.mozilla.javascript.tools.shell.Main from /usr/lib/jvm/java-6-openjdk/jre/lib/rhino.jar] [Loaded org.mozilla.javascript.ContextFactory from /usr/lib/jvm/java-6-openjdk/jre/lib/rhino.jar] [Loaded org.mozilla.javascript.tools.shell.ShellContextFactory from /usr/lib/jvm/java-6-openjdk/jre/lib/rhino.jar] ... If I change over to using sun's JRE, it works fine: $ sudo update-java-alternatives --set java-6-sun $ java -verbose:class -jar ../shrinksafe/custom_rhino.jar ... [Loaded org.mozilla.javascript.tools.shell.Main from file:/home/bryan/bzr/dojo/util/shrinksafe/custom_rhino.jar] [Loaded org.mozilla.javascript.RhinoException from file:/home/bryan/bzr/dojo/util/shrinksafe/custom_rhino.jar] [Loaded org.mozilla.javascript.EvaluatorException from file:/home/bryan/bzr/dojo/util/shrinksafe/custom_rhino.jar] ... To manage notifications about this bug go to: https://bugs.launchpad.net/openbravo/+bug/255149/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~openjdk Post to : [email protected] Unsubscribe : https://launchpad.net/~openjdk More help : https://help.launchpad.net/ListHelp
