Looking ahead: proposed Hg forest consolidation for JDK 10

[Lindenmaier, Goetz]

Hi,

the problems we encounter with jtreg are not that much that it’s not
compatible with tests in 8. It’s not compatible with older builds
of 9.
It’s a problem to run a new jtreg with an older build of jdk9.
Our internal sources of 9 are aprox. 5 months behind and we always
test them with an older jtreg.
We never now when and to what version we should go if these break.
For our openJdk 9 build it’s easy as we build tip, and so jtreg tip should work.

Unfortunately I don’t remember the issues we encountered. But looking at the
repo “remove support for acception old-style module system options” would
be a candidate.

But what kind of bugs are you fixing there you would have to downport
to a runner for 8?  Bugs that crash the runner? They are rare, aren't they?

Best regards,
  Goetz.

From: Joseph D. Darcy [mailto:joe.darcy at oracle.com]
Sent: Thursday, October 13, 2016 1:25 AM
To: Jonathan Gibbons <jonathan.gibbons at oracle.com>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk9-dev at openjdk.java.net
Subject: Re: Looking ahead: proposed Hg forest consolidation for JDK 10

On 10/12/2016 8:52 AM, Jonathan Gibbons wrote:


On 10/12/16 12:16 AM, Lindenmaier, Goetz wrote:

> > We find it difficult to keep the jtreg runner in sync with our

> > current version of jdk9, especially as we have two of them (We

> > test openJdk and SAP JVM 9, and within SAP JVM 9 hotspot and

> > jdk often differ in a few builds.)

> > I would appreciate if the runner could be included in the

> > root/test directory.

>

> I'm not quite sure what you are referring to by the jtreg runner.

I mean the code in http://hg.openjdk.java.net/code-tools/jtreg

Goetz,

What sort of troubles have you been having here?  The intent is to provide
one version of jtreg that works for all supported JDK versions. Currently,
the intent is that jtreg supports running tests on all versions back to JDK 5.

That being said, jtreg does advance slowly, and there is a value to identify
the minimum required version of jtreg in the test/TEST.ROOT file for each
repository that contains jtreg tests. If nothing else, you could use that value
to help select a specific version of jtreg, assuming you build/provide
multiple versions.

I do accept that folk working on the jigsaw/jake forest will sometimes have
to use the latest version of jtreg (i.e. tip, not the latest tagged version) but
that is part of living and working on "the bleeding edge", and which does
not sound like your situation.

In short, I think the cost of the logistics to keep jtreg in the main JDK forest,
including the need to backport changes, would far outweigh any benefits,
especially when there is related concern about the overall size of an aggregate
consolidated repo.

I agree with Jon that it is strongly preferable to have jtreg be separate from any particular JDK release since it can be shared among multiple release trains and the development cycle of jtreg is not fundamentally tied to the development cycle of a particular JDK release (although many recent jtreg features have been in support of Jigsaw in 9).

Cheers,

-Joe