RFR (xs) 8166203 NoClassDefFoundError should not be thrown if class is in_error_state

[Coleen Phillimore]

http://cr.openjdk.java.net/~iklam/jdk9/8166203_init_state_error_bug/test/runtime/lambda-features/InterfaceInitializationStates.java.udiff.html

Same comment as the others.

Just take out the try block for Iunlinked.

Thank you for fixing this!
Coleen


On 10/12/16 4:08 AM, serguei.spitsyn at oracle.com wrote:
> Hi Ioi,
>
> The fix looks good to me.
> But I agree with David below that the catch statement is somewhat 
> confusing.
> The test needs to fail in such a case with a message like "Unexpected 
> NoClassDefFoundError <...>".
>
> Thanks,
> Serguei
>
>
>
> On 10/11/16 22:58, David Holmes wrote:
>> Hi Ioi,
>>
>> On 12/10/2016 2:47 PM, Ioi Lam wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8166203
>>> http://cr.openjdk.java.net/~iklam/jdk9/8166203_init_state_error_bug/
>>>
>>> Summary:
>>>
>>> Kudos to Coleen for noticing the bug.
>>>
>>> When dumping the CDS archive, we would throw NoClassDefFoundError 
>>> inside
>>> InstanceKlass::link_class_impl() if the current class is 
>>> in_error_state.
>>> This was only intended to be a convenient way to deal with verification
>>> errors during CDS dumping time. However, if the code is executed in
>>> normal VM execution time, it would violate the JLS.
>>>
>>> The fix is to throw the NoClassDefFoundError only when
>>> DumpSharedSpaces==true, to avoid affecting normal VM execution.
>>
>> Fix looks fine.
>>
>> Test change is somewhat confusing. What bug does this still refer to?
>>
>>  160         try {
>>  161             boolean bb = Iunlinked.v;
>>  162         } catch(NoClassDefFoundError e) {
>>  163             System.out.println("NoClassDefFoundError thrown 
>> because of bug");
>>  164         }
>>
>> Either the try block should complete exceptionally or the catch 
>> block, to indicate a failure.
>>
>> Thanks,
>> David
>>
>>
>>> Thanks
>>> - Ioi
>>>
>