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
