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.
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,
Richard
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
