Request for review: 8010833: Test7116786.java is failing on most configs after fix for 8010667

[Coleen Phillimore]

There's a jar file because this test uses jasm and some binary hacking 
to generate .class files to test the verifier.   We generally move .jar 
files to the closed repository but there is value to having this test in 
the open for the open community. The new verify errors are an open feature.

So I agree with Harold to fix the test because it looks like a 
regression and decide what to do with the jar file later.

Coleen

On 3/27/2013 8:31 AM, harold seigel wrote:
> Thanks everyone for your comments.
>
> I'll check in the fix for the test so that it will pass, and then open 
> a new bug concerning logistical issues for this test.
>
> Thanks! Harold
>
> On 3/27/2013 12:34 AM, David Holmes wrote:
>> On 27/03/2013 8:06 AM, Christian Thalinger wrote:
>>>
>>> On Mar 26, 2013, at 2:38 PM, harold seigel 
>>> <harold.seigel at oracle.com> wrote:
>>>
>>>> Hi Vladimir,
>>>>
>>>> The test consists of a .java file and a .jar file.
>>>
>>> What?  It seems this slipped by everyone:
>>>
>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-August/004187.html 
>>>
>>>
>>> Binaries are not supposed to be integrated; everything should be 
>>> available as source:
>>>
>>> http://hg.openjdk.java.net/jdk8/build/raw-file/tip/README-builds.html
>>>
>>> "• Generated source or binary files should NEVER be added to the 
>>> repository (that includes javah output). There are some exceptions 
>>> to this rule, in particular with some of the generated configure 
>>> scripts."
>>
>> The README-builds is hardly an authoritative source for what is and 
>> is not allowed in the OpenJDK repositories. For the record there are 
>> quite a number of jar files and class files under hotspot/test and 
>> jdk/test in the open forest.
>>
>> David
>> ------
>>
>>> Does IcedTea remove this test?
>>>
>>> -- Chris
>>>
>>>>   The .java file just calls the various test cases that are in the 
>>>> .jar file.  The sources for these test cases, including the one for 
>>>> nonzero padding bytes, are not provided.  So, they won't get 
>>>> recompiled.
>>>>
>>>> Harold
>>>>
>>>> On 3/26/2013 5:24 PM, Vladimir Kozlov wrote:
>>>>> I am asking this because compiling jdk (jtreg var COMPILEJAVA) 
>>>>> could be different from tested jdk (jtreg var TESTJAVA). So you 
>>>>> may get old class version of the test file while testing jdk8.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 3/26/13 2:13 PM, Vladimir Kozlov wrote:
>>>>>> Harold,
>>>>>>
>>>>>> Is it possible to set 'testable' parameter for case58 based on class
>>>>>> file version?
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 3/26/13 1:15 PM, harold seigel wrote:
>>>>>>> Please review the following small change to fix bug 8010833
>>>>>>>
>>>>>>> Summary: The fix for 8010667 allows non-zero padding bytes for
>>>>>>> lookupswitch and tableswitch opcodes.  Previously, these had to be
>>>>>>> zero.  Test7116786 is now incorrect because it expects a 
>>>>>>> VerifyError
>>>>>>> exception for non-zero padding bytes for lookupswitch and 
>>>>>>> tableswitch
>>>>>>> opcodes.
>>>>>>>
>>>>>>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8010833/
>>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8010833/>
>>>>>>>
>>>>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8010833
>>>>>>>
>>>>>>> The change was tested by running the test and seeing that it 
>>>>>>> passes.
>>>>>>>
>>>>>>> Thanks, Harold
>>>>
>>>
>