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

[Peter Levart]

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