[rfc][icedtea-web] run on any open/oracle jdk (and ibm jdk!)

[Jiri Vanek]

On 05/16/2014 12:24 AM, Omair Majid wrote:
> Hi,
>
> * Jiri Vanek <jvanek at redhat.com> [2014-05-15 06:56]:
>> Please threat this as regular review request :)
>
> This isn't a patch review; I am just commenting on the overall approach.


heheh :)) Somebody should review it ;)

>
>> On 05/13/2014 08:43 PM, Jiri Vanek wrote:
>>> This patch allows ITW to run on any openjdk or oracle jdk(I have not yet tested with IBM, but will do)
>
> This is fantastic to hear!
>
>>> This is probably not final version of the patch - as it break all
>>> tests using PluginAppletMocks - Its easy - tests do not run on
>>> bootclassapth, so the Ancestor of my Access class is in different
>>> classlaoder.
>>>
>>> Moving tests to bootclassapth[2] do not help, as then even worse
>>> things happens. But it should be solution-able. Anyway I think that
>>> removing those 9 tests is small cost for get rid of dependence on
>>> icedtea (plugin-hole patch)
>
> Yeah, there are upsides and downsides to most changes. Losing a few test
> for ability to build/run against unpatched OpenJDK sounds like a net win
> to me.

I would agree. Little bit wrong is, that those are good quite imprtatnt ests ;(
>
>>> There is nasty override of run method. Inside is copypasted code and it is vulnerable.  I will try
>>> to propose the change
>>>
>>>
>>> -  private runLoader()
>>> +          runLoader()
>>>
>>> to upstream. If they accept,  then actually no hacking will be needed and the hook will be pretty
>>> clear (except refelction based getters and setter, which is quite ok...)
>
> Good luck! The impression I got was that changes to sun.* packages are
> simply not allowed.

hmhmh:(

>
>>> (yah it really worked on plain upstream oraclejdk7 or openjdk7 :) )
>
>> Oh! It even worked on IBM JDk!
>
> :D
>
>> checking if sun.security.provider.X509Factory is available... no
>> configure: error: sun.security.provider.X509Factory not found.
>
> Yeah, this is used in only one place: to dump the certificate
>
>> checking if sun.security.x509.X500Name is available... no
>> configure: error: sun.security.x509.X500Name not found.
>
> This one is more important: it's used in verifying SSL certificates.
> It's accessed through HostNameChecker. I wonder if there is a public API
> for this.
>
>> and same for ValidatorException
>
> This one is used in VariableX509TrustManager.java, to catch exceptions
> thrown by the methods in X509TrustManager. These methods declare a public
> exception class CertificateException, though. Perhaps we should use
> that.


Yes. All those are solveable by adjusting classptah n case IBM java is used.
>
>> then compilation fails, because  classes like String or so are missing.
>> This is quite clear because IBM java is split to much more parts then oracle/open JDK.
>> To make compilation work, we have to extend our bootstrap JDK.
>
> I think this is the right approach. Instead of overriding the
> bootclasspath that's part of the JRE (using -Xbootclasspath), maybe we
> should append to it (using -Xbootclasspath/p).
>

Oh. This expalines the strange behaviour javac/java.

During runtime we -Xbootclasspath/a but in compile tie we use jsut pure  -Xbootclasspath
However, more is needed, as IBM java have those fiels quite spread.

BUT it do not explain why configure check do not work (unless it is using the botostrap JDK dir, which I think it do not) . Thats why I think that more will be needed:( (maybe even enhance our bootstrap?)

>> (which is a
>> bit broken, it still calls itself like jdk-1.6 - but should call itself
>> jdk-1.7) OR maybe we can get rid of it?
>
> This was done in the earlier icedtea-web days and it was simply copied
> from icedtea. Maybe we should get rid of this build cruft and simply use
> JDK_HOME/bin/java(c) and friends directly.

Agree. It will come as another changeset.
>
>> But we have to change javwas and plugin luncher  bootclassapth a bit...
>
> If done correctly, this might just be a cleanup.
>
>> How worthy is IBM java support?
>
> Personally, I would consider OpenJDK support the priority. If anything
> else works, I think that's a bonus.
>
>> Well - if we agree on IBM support or at least "support" then
>> I'mnotsure if we should try to push also
>
> I wouldn't mind cleaning some code if it makes other JDKs work too, but
> I am not sure if we can even think about "supporting" other JDKs. How
> would we, for example, check that calling a certain piece of
> undocumented code works the same in IBM JRE as it does in OpenJDK?
>
>> path to Openjdk. Well insome time it will bubble to Oracle bits, but
>> when to Ibm bits? maybe never....
>
> I can only speculate here, but I believe that the IBM JRE uses the same
> class library as the proprietary Oracle JDK. Just a different VM. If
> it is included in the proprietary Oracle JDK, it should become part of
> the IBM JDK too.
>
Maybe.... :)

Thank you for cometns. Any chnace for review at whole?