JDK 9 RFR of JDK-8048620: Remove unneeded/obsolete -source/-target options in hotspot tests

[David Holmes]

Hi Joe,

I can provide you one Review. It seems to me the -source/-target were 
being set to ensure a minimum version (probably on -target was needed 
but -source had to come along for the ride), so removing them seems fine.

Note hotspot protocol requires copyright updates at the time of checkin 
- thanks.

Also you will need to create the changeset against the group repo for 
whomever your sponsor is (though your existing patch from the webrev 
will probably apply cleanly).

A second reviewer (small R) is needed. If they don't sponsor it I will.

Cheers,
David



On 2/07/2014 2:42 AM, Joe Darcy wrote:
> *ping*
>
> -Joe
>
> On 06/27/2014 04:57 PM, Joe Darcy wrote:
>> Hello,
>>
>> As a consequence of a policy for retiring old javac -source and
>> -target options (JEP 182 [1]), in JDK 9, only -source/-target of 6/1.6
>> and higher will be supported [2]. This work is being tracked under bug
>>
>>     JDK-8011044: Remove support for 1.5 and earlier source and target
>> options
>>     https://bugs.openjdk.java.net/browse/JDK-8011044
>>
>> Many subtasks related to this are already complete, including updating
>> regression tests in the jdk and langtools repos. It has come to my
>> attention that the hotspot repo also has a few tests that use -source
>> and -target that should be updated. Please review the changes:
>>
>>     http://cr.openjdk.java.net/~darcy/8048620.0/
>>
>> Full patch below. From what I could tell looking at the bug and tests,
>> these tests are not sensitive to the class file version so they
>> shouldn't need to use an explicit -source or -target option and should
>> just accept the JDK-default.
>>
>> There is one additional test which uses -source/-target,
>> test/compiler/6932496/Test6932496.java. This test *does* appear
>> sensitive to class file version (no jsr / jret instruction in target 6
>> or higher) so I have not modified this test. If the test is not
>> actually sensitive to class file version, it can be updated like the
>> others. If it is sensitive and if testing this is still relevant, the
>> class file in question will need to be generated in some other way,
>> such as as by using ASM.
>>
>> Regardless of the outcome of the technical discussion around
>> Test6932496.java, I'd appreciate if a "hotspot buddy" could shepherd
>> this fix through the HotSpot processes.
>>
>> Thanks,
>>
>> -Joe
>>
>> [1] http://openjdk.java.net/jeps/182
>>
>> [2]
>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-January/000328.html
>>
>> --- old/test/compiler/6775880/Test.java    2014-06-27
>> 16:24:25.000000000 -0700
>> +++ new/test/compiler/6775880/Test.java    2014-06-27
>> 16:24:25.000000000 -0700
>> @@ -26,7 +26,6 @@
>>   * @test
>>   * @bug 6775880
>>   * @summary EA +DeoptimizeALot:
>> assert(mon_info->owner()->is_locked(),"object must be locked now")
>> - * @compile -source 1.4 -target 1.4 Test.java
>>   * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -Xbatch
>> -XX:+DoEscapeAnalysis -XX:+DeoptimizeALot
>> -XX:CompileCommand=exclude,java.lang.AbstractStringBuilder::append Test
>>   */
>>
>> --- old/test/runtime/6626217/Test6626217.sh    2014-06-27
>> 16:24:26.000000000 -0700
>> +++ new/test/runtime/6626217/Test6626217.sh    2014-06-27
>> 16:24:26.000000000 -0700
>> @@ -54,7 +54,7 @@
>>
>>  # Compile all the usual suspects, including the default 'many_loader'
>>  ${CP} many_loader1.java.foo many_loader.java
>> -${JAVAC} ${TESTJAVACOPTS} -source 1.4 -target 1.4 -Xlint *.java
>> +${JAVAC} ${TESTJAVACOPTS} -Xlint *.java
>>
>>  # Rename the class files, so the custom loader (and not the system
>> loader) will find it
>>  ${MV} from_loader2.class from_loader2.impl2
>> @@ -62,7 +62,7 @@
>>  # Compile the next version of 'many_loader'
>>  ${MV} many_loader.class many_loader.impl1
>>  ${CP} many_loader2.java.foo many_loader.java
>> -${JAVAC} ${TESTJAVACOPTS} -source 1.4 -target 1.4 -Xlint
>> many_loader.java
>> +${JAVAC} ${TESTJAVACOPTS} -Xlint many_loader.java
>>
>>  # Rename the class file, so the custom loader (and not the system
>> loader) will find it
>>  ${MV} many_loader.class many_loader.impl2
>> --- old/test/runtime/8003720/Test8003720.java    2014-06-27
>> 16:24:26.000000000 -0700
>> +++ new/test/runtime/8003720/Test8003720.java    2014-06-27
>> 16:24:26.000000000 -0700
>> @@ -26,7 +26,7 @@
>>   * @test
>>   * @bug 8003720
>>   * @summary Method in interpreter stack frame can be deallocated
>> - * @compile -XDignore.symbol.file -source 1.7 -target 1.7 Victim.java
>> + * @compile -XDignore.symbol.file Victim.java
>>   * @run main/othervm -Xverify:all -Xint Test8003720
>>   */
>>
>>
>