PrimitiveAwareClassLoader was introduced as part of EJBTHREE-1626 to centralize the logic of handling primitives during classloading.

1) Recent performance analysis reports have shown that this is not very efficient when handling primitives. The following call:

clazz = new PrimitiveAwareClassLoader(cl).loadClass(name);

assuming "name" is a primitive can lead to the following flow in a JBoss AS environment:

• Start looking for the class in a synchronized block (BaseClassLoader)
• Acquire/release locks in BaseClassLoaderDomain
• On realizing that long (or other primitives) cannot be resolved, throw an CNFE from BaseClassLoader
• java.lang.ClassLoader (which btw, is in a synchronized method) catches this exception and ultimately calls PrimitiveAwareClassLoader.findClass, which finally returns the corresponding class object.

All this (expensive stuff) for just load a primitive type!

2) PrimitiveAwareClassLoader should have been more of a utility class for centralizing the logic of handling primitives instead of being a classloader, because if currently violates the rules of Class.forName http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#forName(java.lang.String,%20boolean,%20java.lang.ClassLoader) which says:

"If name denotes a primitive type or void, an attempt will be made to locate a user-defined class in the unnamed package whose name is name. Therefore, this method cannot be used to obtain any of the Class objects representing primitive types or void."

Currently using this PrimitiveAwareClassLoader with (either of the overloaded) Class.forName method(s) will result in breaking the contract set by the javadocs of Class.forName.

As a fix for #1 and #2, the PrimitiveAwareClassLoader will be deprecated and a utility class will be introduced to centralize the primitive handling