JTreg upwards compatibility?

[Jonathan Gibbons]

Hi Martin,

Yeah, mea culpa, that was an unintended side effect of a change
to improve the reporting in .jtr files.

The change was that previously, bootclasspath tests implied the
use of the /othervm modifier.  That was cleaned up/simplified
as part of the work to document in the .jtr file which mode was
being used and why.

It's also a step in the direction of making the /othervm optional
so that if you specify VM options, then jtreg will find and use a suitable
VM (possibly creating it) instead of simply rejecting the test if it
doesn't specify /othervm.

-- Jon

On 05/12/2016 10:16 AM, Martin Buchholz wrote:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/041017.html
> We patched VarargsArrayTest and CustomizedLambdaFormTest
>
> On Thu, May 12, 2016 at 9:22 AM, Jonathan Gibbons
> <jonathan.gibbons at oracle.com> wrote:
>> martin,
>>
>> Can you elaborate a bit more on the issues you are seeing?
>> Are they due to changes in jtreg itself, or for example, changes
>> in the recommended libraries, like TestNG and JUnit?
>>
>> Can you point to JBS issues or changesets where tests have
>> had to be updated?  I did a quick search through Mercurial
>> for jdk9/dev and jdk8u/jdk8u for changes to
>> CustomizedLambdaFormTest, but didn't find anything obvious.