harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy, Jing Lv" <firep...@gmail.com>
Subject Re: [classlib][nio-charset] RI is inconsistent with spec when loading charset provider
Date Fri, 04 Aug 2006 03:17:18 GMT
Paulex Yang wrote:
> Andrew Zhang wrote:
>> Hi, all
>> Things are a little bit complex when I tried to implement this 
>> workaround.
>> Consider availableCharsets() method from Charset.java, which loads 
>> provider
>> classes from configuration file.
>> Please see my comments inline.
>> final ClassLoader cl = getContextClassLoader();
>>  if (null != cl) { // what shall we do if context class loader is null?
>>   try {
>>    //  context classloader is used to get resources.
>>    Enumeration e = cl
>>    // Examine each configuration file
>>    while (e.hasMoreElements()) {
>> // here, context classloader is used to load class.
>> // If system classloader is used as backup when context classloader 
>> fails to
>> load, it seems illogical, because it's context classloader who get
>> resources.
>> // It should be the same classloader who gets resources and loads
>> corresponding classes.
>>     loadConfiguredCharsets((URL) e.nextElement(), cl, charsets);
>>    }
>>   } catch (IOException ex) {
>>    // Unexpected ClassLoader exception, ignore
>>   }
>>  }
>> If we put another copy code after this section, using "system 
>> classloader"
>> instead of "context classloader", it also seems illogical. What shall 
>> we do
>> if context classloader fails to load a provider charset class? Should it
>> throw an error as spec requires or pass silently?
> Hmm... I think more serious problem here is that the classloader is used 
> not only to load the CharsetProvider class, but also to load the 
> configuration files, so if we choose to try context classloader then 
> system classloader, they may load different config files! IMHO, the 
> behavior will be contradict with both RI and spec. I suggest we give up 
> the *third way* and choose one(RI or spec) to follow, from others' 
> comments, Sun has been aware of this for long time, so they must have 
> reason not to fix the codes, maybe just because this is a not trivial 
> difference(it may be significant for server application which has multi 
> classloaders and special charsets), so I suggest we follow RI.

I notice some lines of spec of CharsetProvider:
in the end of Para 1, it reads clearly:
"Charset providers are looked up via the current thread's context class 
and in the Para 3, it reads:
"The provider must be accessible from the same class loader that was 
initially queried to locate the configuration file; this is *not* 
necessarily the class loader that loaded the file."

Seems Spec says nothing about which classloader is used to locate 
configuration file, but the tests has shown that it can be the system 

OK, then I think we can do like this:
use System Classloader to locate the configuration file, then use 
thread's context class loader to load providers; if fails, use System 
Classloader to load providers; if fails again, throw exception.

This shall not break "following RI" nor Spec because: 1. we has used 
context class(follow spec Para1); 2. we use System Classloader to locate 
configuration file, and the provider must be accessible to this 
classloader or it will throw exception(follow spec Para3, the first 
sentence); 3. spec never forbid us from using difference 
classloader(spec Para3, the second sentence); 4. at last we use System 
Classloader to load the provider if context classloader fails(we follow RI).

I feel very curious what does sun think about this problem. :) However 
let's work around, waiting for RI to correct code, or correct spec.

>> To sum up, it's hard to follow RI, and comply with spec 
>> simultaneously.  We
>> have to choose one of them. Spec or RI?
>> I don't think RI would change its behaviour in later release. In fact, 
>> the
>> "bug" still exists in SUN 6.0 rc version. Personally, +1 for following 
>> RI.
>> Any comments or better suggestions?
>> Thanks!


Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message