jtreg testing integrated

[Mark Wielaard]

Hi Joe,

On Thu, 2008-05-22 at 14:14 -0700, Joe Darcy wrote:
> >> System.getProperty("java.runtime.name").startsWith("Java(TM)")
> >>
> >> Out of the box, our OpenJDK builds have "java.runtime.name" start with 
> >> "OpenJDK"; is that true in your IcedTea/OpenJDK builds too?
> >>     
> >
> > It depends on the version and the distribution. IcedTea6 now calls
> > itself OpenJDK, but IcedTea7 calls itself IcedTea. Ubuntu has a patch to
> > return "Java(TM)" here. And we might actually might want to make that
> > the default. 
> 
> I doubt Sun's lawyers would be happy with that!

haha :) But well, what can you do if it is a feature string actual
applications test against. More importantly soon we will see derivatives
of pass the TCK and hopefully they will then all be considered Java(TM)
anyway.

> > I was looking at this particular test and I didn't immediately see why
> > javax.crypto.SunJCE_x couldn't be replaced with a commonly available
> > class in OpenJDK. What is special about those classes that they need to
> > be explicitly tested against?
> >   
> 
> The crypto classes in Sun's product are obfuscated, US government 
> requirement, and the obfuscators have been know to corrupt the signature 
> attribute used by the reflection methods in question.

Couldn't we create a new test then for this case specifically? Something
like Jasmin can probably be used to write such "corrupt" classes. Mauve
contains a module that uses Jasmin to create "bad classes" to try to
fool the byte code verifier for example.

> >> For the javax/script tests, I was going to add "if (no javascript engine 
> >> and production JDK) fail else note/warning" logic so that our production 
> >> build gets the same coverage and if an OpenJDK build come with a 
> >> javascript engine, it would get testing too.
> >>     
> >
> > What do you precisely mean when you say that you have an "if production
> > JDK"? What functional feature does that test against?
> >   
> 
> I use the value in that system property.  In a helper class I define
> 
>   32     public static ScriptEngine getJsEngine(ScriptEngineManager m) {
>   33         ScriptEngine e  = m.getEngineByName("js");
>   34         if (e == null &&
>   35             
> System.getProperty("java.runtime.name").startsWith("Java(TM)")) {
>   36             // A js engine is requied for Sun's product JDK
>   37             throw new RuntimeException("no js engine found");
>   38         }
>   39         return e;
>   40     }

Aha. I don't think that is a good feature test. As said above the
runtime.name is not really a good selector (much too broad). And I
assume people will want to configure their OpenJDK derivative with or
without different scripting engines. In fact I was going to follow
David's advice and make IcedTea honor a ./configure --with-rhino flag.
It would be good if that could then also set some property so that the
correct tests are run.

Cheers,

Mark