jtreg testing integrated

[Joseph D. Darcy]

Andrew John Hughes wrote:
>>  >  Yes, getting accurate, descriptive, and neutral (and concise) wording can
>>  > be tricky, as "proprietary" is also disparaging in some contexts ;-)
>>  >
>>
>>
>> Er... it's very much intended to be disparaging.  There's a good basis
>>  for that, whereas I don't see one for simply classifying all other
>>  builds as below the standard of this 'production build' -- well,
>>  outside Sun anyway :)
>>
> 
> It occurred to me I should probably clarify this a little more, and
> the rest of the discussion with a little context.
> 
> OpenJDK is pretty much the first extended content I and many other GNU
> Classpath/GCJ/etc. developers have had with Sun's JDK.  Prior to this,
> if it was used at all, it would be to run a simple test case because
> the output differed between the Classpath implementation and Sun's
> reference implementation.  Certainly no-one who worked on these
> projects will have seen the source code; this is a pre-requisite for
> this work.
> 
> This is still very much the case; with the use of IcedTea you are
> seeing a switch not from shipping Sun's proprietary JDK but from
> shipping a variety of Classpath-based solutions.  The proprietary JDK
> doesn't really enter into the mainstream of most distributions such as
> Fedora, Debian or Ubuntu.  If it's packaged at all, it lurks in a
> separate repository for non-Free packages.

Which is why OpenJDK 6 is good news :-)

> Thus, I get a little alarmed when I read comments about special cases
> being added to the GPLed implementation to handle issues with the
> proprietary JDK.  This is not because this is inherently wrong, but
> simply because I can foresee this causing additional problems or
> inconveniences for those who are now packaging and shipping OpenJDK.
> Indeed, I believe Mark started looking into this specifically for this
> reason; so that the tests could be run on the OpenJDK being packaged
> in distributions and so the community could have a goal to work
> towards in fixing any issues.
> 
> So I apologise if any of my comments read as being abrasive or as not
> understanding the issues of Sun's 'production build'.  But it's
> something very foreign to us, and something I'd expect to remain so,
> while the production build remains a proprietary product.

Sending email from a fsf.org address, I wouldn't be surprised if you had 
disparaging thoughts about proprietary, non-Free, software even if you 
didn't voice them ;-)  So no slight was taken and my use of "production 
JDK" wasn't intended to detract from any OpenJDK distributions.

I've worked on the JDK at Sun for a while now so I have a different 
perspective on the code.  For me, in addition to everything it was 
before for the previous 10+ years, the (Open)JDK code base is now also 
an open source project under the GPL.  This has been and continues to be 
an adjustment to how we in Sun think about and work with the code and 
there are still some issues to work through, including addressing the 
copyright/licensing concerns recently raised by Debian's review of an 
OpenJDK package as well as adjusting the regression tests to be more 
appropriate for OpenJDK.

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.

I strongly support Mark's initiative to publish and compare OpenJDK 
regression test results.  Now that jtreg is (finally!) available under 
open source, I think it is natural to use the regression tests that come 
as part of the JDK source as one shared way to get a read on the quality 
of the resulting bits.

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.

-Joe