jtreg testing integrated

[Andrew John Hughes]

On 23/05/2008, Joseph D. Darcy <Joe.Darcy at sun.com> wrote:
> 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 :-)
>
>

I agree.  In fact, I'd go as far as to say fantastic :)

> > 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.
>

That's good to hear, and I personally didn't interpret the term that
way.  I'm just overtly aware that it so easily could be.

>  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.
>

As external observers of this transformation, we can see this issue
and appreciate how things are slowly changing for the better.  Our
comments are intended to help this process, rather than hinder, and I
hope this is the case.

Getting the OpenJDK into Debian will be a nice milestone, simply
because of this legal scrutiny it is currently undergoing.  I use
Debian on many of my machines (and have manually installed OpenJDK6 on
them) and this level of integrity is one of the main reasons I do so.

>  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.

>  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.
>

Me too.  It's great to see jtreg finally being Freed.  As I mentioned
previously on the list, I've tried running the tests previously in a
very adhoc way because I was eager to use these, not just for testing
OpenJDK but also (presumably from some masochistic desire) against GNU
Classpath.

>  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.

>  -Joe
>


-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8