[jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1910) Performance : Deprecate usage of PrimitiveAwareClassLoader and alternately provide a more performant utility for handling primitives

[jaikiran pai (JIRA)]

     [ https://jira.jboss.org/jira/browse/EJBTHREE-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-1910.
------------------------------------

               Fix Version/s: 1.1.16
                  Resolution: Done
    Component Fix Version(s): jboss-ejb3-common:1.0.1


PrimitiveClassLoadingUtil.loadClass(String className, ClassLoader cl) API has now been introduced.

> Performance : Deprecate usage of PrimitiveAwareClassLoader and alternately provide a more performant utility for handling primitives  
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1910
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1910
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: common
>    Affects Versions: 1.1.15, Plugin 1.0.14
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>            Priority: Blocker
>             Fix For: 1.1.16
>
>
> 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
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira