Re: Avoid creating a stacktrace prior to JDK 1.7

Lew schrieb:


The JDK itself violates this rule. For example
each time a Thread is created the following
check is run:

     /**
      * Performs reflective checks on given subclass to verify
      * that it doesn't override security-sensitive non-final
      * methods. Returns true if the subclass overrides any of
      * the methods, false otherwise.
      */
     private static boolean auditSubclass(final Class subcl) {
         Boolean result = AccessController.doPrivileged(
             new PrivilegedAction<Boolean>() {
                 public Boolean run() {
                     for (Class cl = subcl;
                          cl != Thread.class;
                          cl = cl.getSuperclass())
                     {
                         try {
 
cl.getDeclaredMethod("getContextClassLoader", new Class[0]);
                             return Boolean.TRUE;
                         } catch (NoSuchMethodException ex) {
                         }
                         try {
                             Class[] params = {ClassLoader.class};
 
cl.getDeclaredMethod("setContextClassLoader", params);
                             return Boolean.TRUE;
                         } catch (NoSuchMethodException ex) {
                         }
                     }
                     return Boolean.FALSE;
                 }
             }
         );
         return result.booleanValue();
     }

In the above the sunshine flow is that we get a boolean
value false, which means that two NoSuchMethodExceptions
are thrown. It seems that in connection with the reflection
API using the exceptions for business logic has become
the prefered idiom contrary to the advice.

But this is probably due to a lack of a better reflection
API. Or we can even analysis it deeper. Since the reflection
API methods can return so much information AND since java
does not have multi valued returns, the exceptions have
been abused for returning additional information.

In the Go Programming language one would do something:

     getDeclaredMethod(String,Class[]) (Method,Error)

Shit happens!

P.S.: Actually the situation is worse in JDK 1.7, the
audit is done but then cached during the call of
isCCLOverridden(). This is good. But each call of
isCCLOverridden() does also poll the cache for
removal of inaccessible keys! Hm, not sure what
I should think about that.

Bye