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

[Lois Foltan]

On 6/25/2015 9:25 AM, harold seigel wrote:
> 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?

Well I wasn't advocating that the VM should stop traversing, I more just 
wanted to understand if any changes in behavior would occur. Thanks for 
the clarification.  I am fine with this change.
Lois

>
> 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
>>>
>>>
>>>
>>
>