Re: RFR (S) : 8026941 : [TESTBUG] java.lang.ClassNotFoundException: java.lang.invoke.InvokeGeneric

[igor.ignatyev@oracle.com]

Ok, I will just filter out hard-coded list and add the version of test with enumeration on all classes as a proof to a new bug about deadlock.

-- Igor

----- Reply message -----
From: "Vladimir Ivanov" <vladimir.x.ivanov at oracle.com>
To: "Igor Ignatyev" <igor.ignatyev at oracle.com>, "hotspot-compiler-dev at openjdk.java.net compiler" <hotspot-compiler-dev at openjdk.java.net>
Subject: RFR (S) : 8026941 : [TESTBUG] java.lang.ClassNotFoundException: java.lang.invoke.InvokeGeneric
Date: Thu, Dec 12, 2013 21:12

Igor,

Why don't you simply filter out all package-private & private classes 
out of classNames array, but leave the list hard-coded in the test? All 
public classes are part of public API, so the list shouldn't change.

Best regards,
Vladimir Ivanov

On 12/12/13 8:24 PM, Igor Ignatyev wrote:
> Hi all,
>
> Problem:
> Test compiler/jsr292/ConcurrentClassLoadingTest has a hard-coded list of
> classes to load, after JDK-8024761 'j.l.i.InvokeGeneric' doesn't exist,
> so test fails w/ CNFE
>
> Fix:
> To testlibrary, added class to print all public classes -- ClassesPrinter
> In ConcurrentClassLoadingTest, hard-coded list was replaced by the list
> of public classes from j.l.i which exist in bootCP.
>
> At first, I tried to use all classes from j.l.i, not only public, but it
> can lead to deadlock. After discussion w/ Vladimir I, we decided that
> since it isn't related to original bug (8022595) we should limited
> classes to public only. I will file a separate product bug about that
> deadlock.
>
> webrev: http://cr.openjdk.java.net/~iignatyev/8026941/webrev.00/
> jbs: https://bugs.openjdk.java.net/browse/JDK-8026941
> testing: jprt
>
> Thanks,
> Igor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131212/7dc9cf4e/attachment.html