RFR: 8210839 Improve interaction between source launcher and classpath

[Jonathan Gibbons]

On 09/21/2018 12:34 AM, Alan Bateman wrote:
> On 20/09/2018 19:18, Jonathan Gibbons wrote:
>> :
>>
>> A side-effect of the change is that the obscure/annoying error message
>>     class found on application class path: {0}
>> is no longer required.
>>
>> The changes to CLTest.java are white-space only.
>>
>> Email: 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055437.html
>> Email: 
>> http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012427.html 
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8210839
>> Webrev: http://cr.openjdk.java.net/~jjg/8210839/webrev.00/index.html
> Changing to local-first before delegating seems right here.
>
> For loadClass then I would expect it to synchronize on 
> getClassLoaderLock(name) and check the loaded class cache with 
> findLoadedClases(name) before calling findClass. There is a related 
> discussion on whether this class loader should be parallel capable but 
> that isn't important right thing.
>
> The getResourceXXX look rights except the check at L616 which I assume 
> will never match as the parent cannot return a URL that locates the 
> resource in memory. In addition, it's not wrong for a resource to be 
> located by the parent at the same location (it would be strange but 
> has always been possible).

The check at L616 is because super.getResources will do "the normal 
delegation thing" and will return an enumeration of the resources in the 
parent class loader followed by resources in the child class loader. 
Since we already have found the classes in the child class loader, we 
want to avoid the duplicate that will be found by super.getResources.


>
> -Alan.