OpenOffice.org build fails due to Rhino integration in OpenJDK

[Svante Schubert]

Hi Mark,

Mark Wielaard wrote:
> 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).
>   
Yes, the exchange of the Rhino would be a workaround and an update would
be about time, but it does not solve the general problem compiling a
different Rhino with this OpenJDK.
>   
>> 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.
>   
Interesting, one of the guys, which have the problem in their
environment should give this a try as workaround.
>   
>> 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.
>   
Adding by automation an 'internal.' in front of a package name to all
external libraries does not seem too hard to me, but I am not an expert
on this and certainly have overseen something.
In any case now people might use the Rhino API and it might be painful
if the Rhino library is exchanged later.
> 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
>   
Thank you very much, Mark!
> 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
>
>   
Cheers,
Svante