OpenOffice.org build fails due to Rhino integration in OpenJDK

[Mark Wielaard]

Hi Svante,

On Tue, 2008-08-05 at 17:13 +0200, Svante Schubert wrote:
> We have an issue with building OpenOffice.org with openjdk-6-jdk 6b11-5, 
> which most likely will effect the OpenOffice.org Fedora build as well.
>     http://www.openoffice.org/issues/show_bug.cgi?id=91641
> 
> It was most likely introduced by
>     
> http://icedtea.classpath.org/hg/icedtea6/file/63c7ccd8da7f/patches/icedtea-rhino.patch
> which adds Rhino with original package names to the OpenJDK.

Yes, that is most likely the patch indeed. See also:
http://mail.openjdk.java.net/pipermail/build-dev/2008-June/001176.html

I have added Caolan to the CC in the hope that he knows how the
OpenOffice package on Fedora handles this. (Maybe it hasn't been build
against a newer icedtea/openjdk yet?)

> Since than we are unable to compile a previous version of Rhino using 
> the above JDK, as always the Rhino interfaces from the JDK are found.

Yes, that would be a problem indeed. Do you need to compile your own
version of Rhino? I believe almost all distros come with a recent rhino
these days that you could depend on (just like icedtea/openjdk does
now).

> In believe that in our case it is not even possible to use the 
> none-standard -Xbootclasspath parameter as a workaround as the we can 
> not add the classes that we are going to compile into our classpath.

I think you can use -Xbootclasspath for javac to explicitly exclude the
rhino.jar (and only use the other standard bootclasses). But I haven't
tried myself yet.

> I suggest to rename the Rhino packages part of OpenJDK to allow to use 
> different versions of Rhino.

Renaming isn't a very good solution. As was earlier discussed:
http://mail.openjdk.java.net/pipermail/build-dev/2008-June/001180.html
We don't actually want to bundle extra copies of classes that a
distribution already packages separately. That would create a lot of
extra work when such a package needs to be rebuild or updated. And
embedding libraries also risks missing security updates.

But you are right that the problem is that that the javax.scripting
support for javascript currently relies on all the rhino classes being
on the bootclasspath. This is obviously wrong. I have opened a bug
report: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=179

I'll try to see if I can make some time for it. But no guarantees. So if
someone else wants to take a stab on making the rhino classes loaded
through a separate classloader that would be really nice.

Cheers,

Mark