RFR: 8061244 Use of stack-less ClassNotFoundException thrown from (URL)ClassLoader.findClass() - was: Preview: JDK-8055854 Examine overhead in java.net.URLClassLoader (stack-less exceptions)

[Peter Levart]

I created an issue in Jira to track this investigation:

https://bugs.openjdk.java.net/browse/JDK-8061244

The latest webrev of proposed patch is still:

http://cr.openjdk.java.net/~plevart/jdk9-dev/ClassLoader.CNFE/webrev.02/

I invite the public to review it.

Thanks.

Peter

On 10/16/2014 10:44 AM, Peter Levart wrote:
> Hi,
>
> As for usage of SharedSecrets, they are not needed to access CNFE 
> package-private constructor from java.lang.ClassLoader, since they are 
> in the same package, and from java.net.URLClassLoader, the call to 
> super.findClass(name) does the job. So here's an updated webrev that 
> also includes more descriptive message:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ClassLoader.CNFE/webrev.02/
>
>
> Regards, Peter
>
> On 10/16/2014 09:35 AM, Peter Levart wrote:
>> On 10/16/2014 01:49 AM, Stanimir Simeonoff wrote:
>>> First, really nice tests.
>>>
>>> As for hiding: missing the real classloader impl. might be quite a 
>>> bumper
>>> for some middleware implementations. That would make pretty hard to 
>>> trace
>>> dependency issues without explicit logging, the latter is usually 
>>> available
>>> but still. Also it'd depend if the classloaders actually use
>>> super.findClass() or not.
>>> IMO, the option should be switchable via some system property.
>>
>> With a little tweak, the message of the stack-less exception thrown 
>> from findClass() methods can be extended to include the classloader's 
>> runtime class name and this message can be inherited by a replacement 
>> stack-full exception. So the stack-trace would look like:
>>
>> Exception in thread "main" java.lang.ClassNotFoundException: XXX 
>> (thrown by: sun.misc.Launcher$AppClassLoader)
>>     at java.lang.ClassLoader.loadClass(ClassLoader.java:366)
>>     at java.lang.Class.forName0(Native Method)
>>     at java.lang.Class.forName(Class.java:265)
>>     at Test.doIt(Test.java:7)
>>     at Test.main(Test.java:11)
>>
>> Instead of what we have now:
>>
>> Exception in thread "main" java.lang.ClassNotFoundException: XXX
>>     at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>>     at java.lang.ClassLoader.loadClass(ClassLoader.java:426)
>>     at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:317)
>>     at java.lang.ClassLoader.loadClass(ClassLoader.java:359)
>>     at java.lang.Class.forName0(Native Method)
>>     at java.lang.Class.forName(Class.java:265)
>>     at Test.doIt(Test.java:7)
>>     at Test.main(Test.java:11)
>>
>>
>> Would this be enough to cover your concern?
>>
>> Regards, Peter
>>
>>>
>>> I am not sure about the need to hide the stackless c-tor as the 
>>> effect can
>>> be achieved by overriding fillInStackTrace(); w/o the extra baggage of
>>> JavaLangAccess.
>>>
>>> Overall very decent improvement.
>>>
>>> Cheers
>>> Stanimir
>>>
>>>
>