harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][nio-charset] RI is inconsistent with spec when loading charset provider
Date Fri, 04 Aug 2006 09:20:18 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.

Sound like a good idea.


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

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