JDK 10 RFR of JDK-8173905: Test tools/jar/multiRelease/RuntimeTest.java fails under JDK 10

[Amy Lu]

Thank you Paul and Claes!

I updated the webrev, renamed the template files and updated 
createJarSourceFiles method. Now templateSourceMap is not needed. Also 
updated the style around array initializers.

http://cr.openjdk.java.net/~amlu/8173905/webrev.01
(For your ref: 
http://cr.openjdk.java.net/~amlu/8173905/RuntimeTest.webrev.00_webrev.01.diff)

Thanks,
Amy


On 5/25/17 12:38 AM, Paul Sandoz wrote:
> Hi Amy,
>
> Looks good,
>
> A minor suggestion i would rename the template files to be the  <name> + “.template”. Then you don’t need the map “templateSourceMap”, and it becomes clearer what files the templates are associated with. Also i would try and retain the same directory structure as well e.g. recursively traversing a directory transforming any file whose name ends with template into a concrete file in versioned area of the same relative path.
>
> Paul.
>
>> On 24 May 2017, at 03:22, Amy Lu <amy.lu at oracle.com> wrote:
>>
>> After the version update to "10" in JDK 10 ( JDK-8029942 ), test tools/jar/multiRelease/RuntimeTest.java starts failing because the release version is hardcoded, not only in the test itself, but also in test data files for the jar that tested on.
>>
>> I've updated the test to generate those data files on the fly based on the template and $version, and the hardcoding of release version also be replaced by the value based on Runtime.version().major(). In this way, test don't need to be updated again for JDK 11.
>>
>> Compared the newly generated "data" files with the old "data", no diff (except the version).
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8173905
>> webrev: http://cr.openjdk.java.net/~amlu/8173905/webrev.00/
>>
>> Tested on all platforms.
>>
>> Thanks,
>> Amy