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
