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 Mon, 07 Aug 2006 09:38:51 GMT
Andrew Zhang wrote:
> What shall we do if context classloader is null?

Try with the System classloader, and if that fails throw an exception.

Tim

> RI still could load the configuration file even if context classloader is
> null.
> 
> On 8/4/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>
>> 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
>> >>>      .getResources(PROVIDER_CONFIGURATION_FILE_NAME);
>> >>>    // 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.
>>
>> Regards,
>> Tim
>>
>> > 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
>>
>>
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

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


Mime
View raw message