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?
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!
On 8/1/06, Richard Liang <[EMAIL PROTECTED]> wrote:
Andrew Zhang wrote:
> On 7/31/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
>>
>> On 7/31/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
>> >
>> > Shall we follow RI or spec? I'd like to suggest follow RI for this
>> > specific
>> > case, because:
>> >
>> > 1. If we follow spec, it may cause legacy applications fail.
>>
>>
>> I do not think that fixing this bug will affect legacy applications
>> badly,
>> because we will add new functionality that is turned on by special
>> configuration files. Old functionality will not be affected.
>
>
> Even with our special configuration, Harmony still behaves differently
> from
> RI, right?
>
> For some case, RI could load user specified configuration file while
> harmony
> could not, and vice versa.
>
> So I think legacy applications will be affected if they assume system
> class
> loader is used. :)
>
> 2. Other service provider in nio module are all loaded by system class
>> > loader.
>> >
>> > Any suggestions and comments?
>>
>>
>> This bug is 4 years old. One or two years more and it will become a
>> 'feature'
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4619777
>>
>> Anyway, I vote to follow spec but not RI :) (AFAIK as classpath did)
>
>
> I tried to run the test against sun 6.0 pre-rc-b65. The result is the
> same.
>
> Seems SUN doesn't take any action on this problem. As you mentioned,
it's
> already 4 years, and is not solved in jdk6. :(
>
> So I still think we should follow RI this time. :)
>
Shall we integrate the spec and RI? That is,
1) Try to load the Charset provider via the current thread's context
class loader
2) If fail to load the provider in step 1), try to use system class
loader to load the Charset provider.
Please correct me if I'm wrong. Thanks a lot.
Best regards,
Richard
> Thanks!
>
>
>> --
>> Mikhail Fursov
>>
>>
>
>
--
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]
--
Andrew Zhang
China Software Development Lab, IBM
