jtreg testing integrated
Joseph D. Darcy
Joe.Darcy at Sun.COM
Thu May 22 16:04:10 PDT 2008
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
More information about the distro-pkg-dev