[jboss-jira] [JBoss JIRA] Updated: (JBCL-118) getResources in BaseClassLoader, ClassLoaderDomain, and friends uses Set<URL> with HashSet

[Tolga Tarhan (JIRA)]

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

Tolga Tarhan updated JBCL-118:
------------------------------

    Description: 
BaseClassLoader, ClassLoaderDomain and several other classes in JBossCL have public API methods which take Set as a parameter. We can't control what implementation of Set is passed in to these methods, but HashSet is commonly used, causing the URL.hashCode() performance problem (DNS lookup). 

I do not understand enough about the public API of JBossCL to know where these methods might be used from. However, I do know that these methods are called internally from several areas in JBossCL with a HashSet. 

I see a two-step solution: 

1) Change anywhere in JBossCL where HashSet is used to another Set implementation. This is a quick and non-API-breaking change that will actually take care of the most common scenarios. 

An example (from user code in the container): ClassLoader.getResources(String) eventually calls BaseClassLoader.loadResources(String) which creates a HashSet and passes that to ClassLoaderDomain.getResources(...) to be filled in, eventually returning the HashSet to the caller. Changing the internal usage of ClassLoaderDomain and friends to use a Set other than HashSet would fix this scenario. 

2) Consider if there is an API change required to prevent misuse of this by callers outside of JBossCL. I'm not sure if any of these methods are intended to be used from outside. Some are public, some are not. 

I'm willing to tackle solution #1 and may submit a patch later this evening. 

However, I need some help/discussion/advice before I could tackle #2. 

  was:
BaseClassLoader, ClassLoaderDomain and several other classes in JBossCL have public API methods which take Set<URL> as a parameter. We can't control what implementation of Set is passed in to these methods, but HashSet is commonly used, causing the URL.hashCode() performance problem (DNS lookup).

I do not understand enough about the public API of JBossCL to know where these methods might be used from. However, I do know that these methods are called internally form several areas in JBossCL with a HashSet.

I see a two-step solution:

1) Change anywhere in JBossCL where HashSet<URL> is used to another Set implementation. This is a quick and non-API-breaking change that will actually take care of the most common scenarios. 

An example (from user code in the container): ClassLoader.getResources(String) eventually calls BaseClassLoader.loadResources(String) which creates a HashSet<URL> and passes that to ClassLoaderDomain.getResources(...) to be filled in, eventually returning the HashSet to the caller.

2) Consider if there is an API change required to prevent misuse of this by callers outside of JBossCL.

I'm willing to tackle solution #1 and may submit a patch later this evening. 

However, I need some help/discussion/advice before I could tackle #2.



> getResources in BaseClassLoader, ClassLoaderDomain, and friends uses Set<URL> with HashSet
> ------------------------------------------------------------------------------------------
>
>                 Key: JBCL-118
>                 URL: https://jira.jboss.org/jira/browse/JBCL-118
>             Project: JBoss ClassLoader
>          Issue Type: Bug
>            Reporter: Tolga Tarhan
>
> BaseClassLoader, ClassLoaderDomain and several other classes in JBossCL have public API methods which take Set as a parameter. We can't control what implementation of Set is passed in to these methods, but HashSet is commonly used, causing the URL.hashCode() performance problem (DNS lookup). 
> I do not understand enough about the public API of JBossCL to know where these methods might be used from. However, I do know that these methods are called internally from several areas in JBossCL with a HashSet. 
> I see a two-step solution: 
> 1) Change anywhere in JBossCL where HashSet is used to another Set implementation. This is a quick and non-API-breaking change that will actually take care of the most common scenarios. 
> An example (from user code in the container): ClassLoader.getResources(String) eventually calls BaseClassLoader.loadResources(String) which creates a HashSet and passes that to ClassLoaderDomain.getResources(...) to be filled in, eventually returning the HashSet to the caller. Changing the internal usage of ClassLoaderDomain and friends to use a Set other than HashSet would fix this scenario. 
> 2) Consider if there is an API change required to prevent misuse of this by callers outside of JBossCL. I'm not sure if any of these methods are intended to be used from outside. Some are public, some are not. 
> I'm willing to tackle solution #1 and may submit a patch later this evening. 
> However, I need some help/discussion/advice before I could tackle #2. 

-- 
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