openjdk team mailing list archive

[Bug Watch Updater <255149@xxxxxxxxxxxxxxxxxx>]

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