RFR (XS): 8196550: [Testbug] runtime/appcds/MultiReleaseJars.java fails on JDK 11

[Calvin Cheung]

On 2/1/18, 7:51 AM, Ioi Lam wrote:
> Looks good, but how do we remember to revert it to the original code 
> after javac is updated?
>
> Or, maybe version 10 is good enough? It seems like this test doesn't 
> need to track the latest version of the JDK, but I'll let Calvin 
> comment on this, since he wrote the test.
I agree that the hard-coded version 10 should be reverted after javac 
has been updated because test case #3 is testing jarVersion being set to 
MAJOR_VERSION + 1:
             for (int i : new int[] {5, MAJOR_VERSION + 1}) {
                 jarVersion = "-Djdk.util.jar.version=" + i;
                 ...

thanks,
Calvin
>
> Thanks
> - Ioi
>
> On 1/31/18 10:03 PM, David Holmes wrote:
>> webrev: http://cr.openjdk.java.net/~dholmes/8196550/webrev/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8196550
>>
>> The test creates a MR jar utilising the "current version" of the JDK, 
>> which is passed to "javac --release" - but the support for --release 
>> 11 is not yet available in javac. Simple fix is to temporarily 
>> hard-wire version 10 as the "current" release.
>>
>> -    static final int MAJOR_VERSION = Runtime.version().major();
>> -    static final String MAJOR_VERSION_STRING = 
>> String.valueOf(Runtime.version().major());
>> +    static final int MAJOR_VERSION = 10; // Runtime.version().major();
>> +    static final String MAJOR_VERSION_STRING = 
>> String.valueOf(MAJOR_VERSION);
>>
>> This will be pushed to jdk/jdk ready for the version bump.
>>
>> Alternatively we can problem-list the test until javac is ready - but 
>> I thought it better to actually keep testing AppCDS.
>>
>> Thanks,
>> David
>