https://bz.apache.org/bugzilla/show_bug.cgi?id=56530
--- Comment #18 from Christopher Schultz <ch...@christopherschultz.net> --- The performance hit would only occur during class loading. By the time a few requests have been processed, class loading should have settled-down quite a bit. Some thoughts about performance: 1. This is mostly introducing a single "if" and a test against a static final field (Jre7Compat.forLanguageTagMethod). The JIT will likely inline that method. 2. If the branch is not tolerable at runtime, perhaps the branch can be executed a single time to install a delegate adapter, something like this: WebappClassLoader: public static Java7 extends WebappClassLoader // etc, do Java 7 stuff public static Java6 extends WebappClassLoader // etc, do Java 6 stuff <init>: if(JreCompat.getInstance().isJre7Supported()) delegate = new Java7ClassLoader(); else delegate = new Java6ClassLoader(); loadClass(): return delegate.loadClass(); Or, if you don't want to use Java method dispatch because delegation is too slow, you can use WebappClassLoader like a factory like this: WebappClassLoader: getInstance(): return JreCompat.getInstance().isJre7Supported() ? new Java7() : new Java6(); Really, synchronization is going to dominate the performance equation here and not the presence (or absence) of a trivial null-check. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
