jtreg testing integrated

[Joseph D. Darcy]

Andrew John Hughes wrote:
> On 23/05/2008, Joseph D. Darcy <Joe.Darcy at sun.com> wrote:
>> Andrew John Hughes wrote:

[snip]

>>  One of my many not-yet-written blog entries is a discussion of the
>> diminishing differences between an "openjdk=true" build of the JDK sources
>> and a Sun product/proprietary build of the sources.  The vast majority of
>> the meaningful content of sources used to build, say, OpenJDK 7, is the same
>> as that used to build Sun's proprietary product.  For example, overall in
>> the langtools area, we don't have any closed code today and we actively
>> don't want any introduced!  However, the few differences do tend to get a
>> disproportionate amount of attention.
>>
> 
> Given the langtools are now in a separate tree in OpenJDK6, could the
> ClosedJDK6 builds not start using this instead?  It would mean some
> overhead and change initially, but once the update was done, it would
> reduce maintenance overall IMO.

Yes, such a switchover would be possible in principle.  I acknowledge 
the likely long-term engineering benefits, but I suspect the folks 
running the 6 update releases would be reticent to move over to the 
different code base.

[snip]

>>  One artifact of more than a decade of development before being an open
>> source project is that not all of the regression tests are in the open; of
>> course, that is not directly visible to the OpenJDK project.  A much
>> smaller, but more visible, artifact is a case like my generics Probe test,
>> written in 2004, that assumes the availability of a class which happens to
>> not be in OpenJDK.  What should this test be today with the current
>> situation of the JDK code?  I don't think simply moving the test to the
>> closed area is the best solution and more maintenance purposes I prefer to
>> not break the test into open and closed portions; I expect the understanding
>> of good solutions to these boundary cases to be refined over time.
>>
> 
> The revelation that some of the ClosedJDK classes are obfusticated is
> new to me too. Is this all the test is looking for?  If so, it might
> be one of the few that does deserve to be segregated for the closed
> build, although I agree that the majority need more detailed handling.

The JDK is quite a complicated piece of software; I've learned many more 
things about it during the course of OpenJDK 6!  With US crypto 
regulations as they currently are, the crypto class files in Sun's 
commercial product must be obfuscated.

What my test does is to load the classes in question reflectively and 
then poke at them using the getGenericFoo methods 
(getGenericConstructors, etc.).  As opposed to the getFoo methods, the 
getGenericFoo methods use the signature attribute to compute their 
result.  Some of the classes loaded are these obfuscated classes.  In 
the past, the obfuscator didn't preserve the signature attribute 
properly and the toGenericFoo methods would throw exceptions and 
otherwise not work.  The test makes sure that the getGenericFoo methods 
work on these classes too.  Just to be clear, the obfuscated classes are 
*not* in OpenJDK.

-Joe