Ubuntu

javascript script support through rhino should not be on bootclasspath

Reported by Bryan Forbes on 2008-08-05
66
This bug affects 9 people
Affects Status Importance Assigned to Milestone
OpenJDK
Fix Released
Medium
openbravo
Undecided
Unassigned
openjdk-6 (Ubuntu)
High
Unassigned

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]
...

Related branches

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.

Matthias Klose (doko) on 2008-08-06
Changed in openjdk-6:
importance: Undecided → High
milestone: none → ubuntu-8.10-beta
status: New → Confirmed
Changed in openjdk:
status: Unknown → Confirmed
Chris Cheney (ccheney) wrote :

This is the same issue that keeps OpenOffice.org from building with openjdk-6.

Chris Cheney (ccheney) wrote :

I found a patch to work around this issue for OpenOffice.org but it would still be nice to have this fixed in Intrepid. :-)

Onkar Shinde (onkarshinde) wrote :

Can you please try this workaround? There is a symlink named rhino.jar in /usr/lib/jvm/java-6-openjdk/jre/lib. See if removing it solves your problem.
Also you can try creating similar link in sun jdk path to see if it causes problem there.

I can confirm that deleting the symlink fixes the problem

Bryan Forbes (bryanforbes) wrote :

I can also confirm that removing that symlink fixes the problem.

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

Craig (candrews-integralblue) wrote :

Confirmed here also. Can we kill that symlink? :-)

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.

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 :-)

Alan Tam (at) wrote :

FYI, this bug (in version 6b11-2ubuntu2.1) is pushed into hardy-security, hence causing a security regression.

David Leon (fongsled) wrote :

This bug still exists in Jaunty. Are there plans to include the fix in Jaunty or Karmic?

I can confirm that this is still an issue in Jaunty.

Craig (candrews-integralblue) wrote :

Confirmed on Karmic.

Kees Cook (kees) on 2009-09-13
Changed in openjdk-6 (Ubuntu):
milestone: ubuntu-8.10-beta → ubuntu-9.10-beta

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.

When will this be solved?

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.

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.

Alex Zaycev (liner) wrote :

Openbravo 2.50MP9 or 2.50 MP10 can't be built with openjdk due to error. See this https://issues.openbravo.com/bug_view_advanced_page.php?bug_id=10454&history=1 . I know that openbravo does not support openjdk officially, but opebravo developers in their weblogs report openjdk as "greatly working".

Alex Zaycev (liner) on 2010-01-20
Changed in openbravo:
status: New → Confirmed
Matthias Klose (doko) wrote :

did you try to build using the workaround given in the bug report?

Hannes Wallnoefer (hannesw) wrote :

You mean removing the rhino.jar symlink from jre/lib/? It solves the problem, but breaks JSR 223 ScriptEngine support, which is the reason we're having this problem in the first place.

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.

Changed in openjdk:
status: Confirmed → In Progress

(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.

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.

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.

(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.

Changed in openjdk:
status: In Progress → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openjdk-6 - 6b18~pre1-0ubuntu1

---------------
openjdk-6 (6b18~pre1-0ubuntu1) lucid; urgency=low

  * New Openjdk6 b18 source code drop.
  * Use mangled copy of rhino. Closes: #512970. LP: #255149.
 -- Matthias Klose <email address hidden> Fri, 19 Feb 2010 18:17:23 +0100

Changed in openjdk-6 (Ubuntu):
status: Confirmed → Fix Released
Hannes Wallnoefer (hannesw) wrote :

Looks like the new package failed to build. Would it help to have the fix backported to IcedTea 1.7 as suggested in the upstream bug report in order to make sure this makes it into Lucid? I could drum up some support (lots of people waiting for this), but I don't want to do so in vain.

Targetting for 1.7.1

Changed in openjdk:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.