Fwd: RFR 8073423: Remove LazyClassPathEntry support if no longer needed

harold seigel harold.seigel at oracle.com
Thu Jun 25 13:25:25 UTC 2015


Hi Lois,

Thanks for the review.

I tried the bad.jar / good.jar example that you mention below both with 
my proposed change and without my proposed change.  In both cases, the 
JVM ignored bad.jar and successfully found the class in good.jar.

Why do you think the JVM would stop traversing the BootClassPath if one 
of the jar files on the path couldn't be opened?

Thanks, Harold

On 6/24/2015 7:30 PM, Lois Foltan wrote:
>
> On 6/24/2015 1:23 PM, harold seigel wrote:
>> Hi,
>>
>> Please review this updated webrev for bug JDK-8073423: 
>> http://cr.openjdk.java.net/~hseigel/bug_8073423.2/
>>
>> The updated webrev differs from the previous one in two ways:
>>
>> 1. The LazyBootClassLoader option is deprecated instead of just deleted.
>>
>> 2. To preserve compatibility, bad jar files detected while setting up
>>    the boot class loader path are ignored.  With the previous fix, they
>>    caused the JVM to terminate.  (This caused test JTReg test
>>    hotspot/test/runtime/LoadClass/LoadClassNegative.java to fail.)
>
> Hi Harold,
>
> Looks good.  Just for my clarification on #2, previously if there was 
> a bad jar file on the boot class loader's -Xbootclasspath/a, a 
> LazyClassPathEntry was created and an attempt was not made to open the 
> bad jar file until there was a need.  Now, that bad jar file is not 
> put on the boot class path list at all, isn't this a change in 
> behavior?  Someone could have have two .jar files in the 
> -Xbootclasspath/a directory specified, say bad.jar and good.jar. Today 
> if an attempt to open bad.jar, a ClassNotFoundException is thrown.  
> With this change, bad.jar is no longer on the boot class path and the 
> class being requested has the potential of being found in good.jar, 
> and the test passes.
>
> Thanks,
> Lois
>
>>
>> This updated webrev was tested with hotspot JTreg tests, JCK lang and 
>> VM tests, and UTE Quick tests.  Additionally, the deprecation of the 
>> LazyBootClassLoader option was tested by hand.
>>
>> Thanks, Harold
>>
>> -------- Forwarded Message --------
>> Subject:     RFR 8073423: Remove LazyClassPathEntry support if no 
>> longer needed
>> Date:     Wed, 01 Apr 2015 15:06:25 -0400
>> From:     harold seigel <harold.seigel at oracle.com>
>> Organization:     Oracle Corporation
>> To:     hotspot dev runtime <hotspot-runtime-dev at openjdk.java.net>
>>
>>
>>
>> Hi,
>>
>> Please review this change to remove LazyClassPathEntry support from the
>> JVM.  With the demise of rt.jar, this is no longer used.
>>
>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8073423/
>>
>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8073423
>>
>> The change was tested with JCK lang, vm, and api tests, hotspot jtreg
>> tests, and testbase split_verifier and quick tests. Additionally, I
>> tested '$JAVA_HOME/bin/java -XX:+LazyBootClassLoader -version" to test
>> for the deprecation message for -XX:+LazyBootClassLoader.
>>
>>  Thanks, Harold
>>
>>
>>
>



More information about the hotspot-runtime-dev mailing list