harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Liang <richard.lian...@gmail.com>
Subject Re: [classlib][nio-charset] RI is inconsistent with spec when loading charset provider
Date Fri, 04 Aug 2006 05:34:08 GMT

Jimmy, Jing Lv wrote:
> 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 loader."
> 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 
> classloader.
> 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.
Hello All,

To make things simple, shall we just follow RI?

Maybe we need another type of JIRA, see "Non-bug have to be different 
wuth Spec". Kidding ;-)

Best regards,

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

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