Preview: JDK-8055854 Examine overhead in java.net.URLClassLoader (stack-less exceptions)

[Stanimir Simeonoff]

Hi Peter,

The changes look good indeed. Actually in real environments the benefits
would be larger due to much deeper stack traces.

Perhaps the the doc of ClassLoader.findClass should advise calling the
super instead of throwing a new CNFE?

Stanimir

On Thu, Oct 16, 2014 at 11:44 AM, Peter Levart <peter.levart at gmail.com>
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
>>>
>>>
>>>
>