You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Andrew Zhang <zh...@gmail.com> on 2006/08/01 03:48:38 UTC
Re: [classlib][nio-charset] RI is inconsistent with spec when loading charset provider
On 7/31/06, Mikhail Fursov <mi...@gmail.com> wrote:
>
> On 7/31/06, Andrew Zhang <zh...@gmail.com> 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. :)
Thanks!
> --
> Mikhail Fursov
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib][nio-charset] RI is inconsistent with spec when loading
charset provider
Posted by Tim Ellison <t....@gmail.com>.
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....@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
Re: [classlib][nio-charset] RI is inconsistent with spec when loading charset provider
Posted by Andrew Zhang <zh...@gmail.com>.
What shall we do if context classloader is null?
RI still could load the configuration file even if context classloader is
null.
On 8/4/06, Tim Ellison <t....@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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib][nio-charset] RI is inconsistent with spec when loading
charset provider
Posted by Tim Ellison <t....@gmail.com>.
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
Re: [classlib][nio-charset] RI is inconsistent with spec when loading
charset provider
Posted by Richard Liang <ri...@gmail.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][nio-charset] RI is inconsistent with spec when loading
charset provider
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
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.
>
>>
>> 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!
>>
>>
>
>
--
Best Regards!
Jimmy, Jing Lv
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
Re: [classlib][nio-charset] RI is inconsistent with spec when loading
charset provider
Posted by Paulex Yang <pa...@gmail.com>.
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.
>
> 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!
>
>
--
Paulex Yang
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
Re: [classlib][nio-charset] RI is inconsistent with spec when loading charset provider
Posted by Andrew Zhang <zh...@gmail.com>.
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 <ri...@gmail.com> wrote:
>
>
>
> Andrew Zhang wrote:
> > On 7/31/06, Mikhail Fursov <mi...@gmail.com> wrote:
> >>
> >> On 7/31/06, Andrew Zhang <zh...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib][nio-charset] RI is inconsistent with spec when loading charset provider
Posted by Andrew Zhang <zh...@gmail.com>.
Richard, good idea!
If no one objects, I'll try to implement it.
On 8/1/06, Richard Liang <ri...@gmail.com> wrote:
>
>
>
> Andrew Zhang wrote:
> > On 7/31/06, Mikhail Fursov <mi...@gmail.com> wrote:
> >>
> >> On 7/31/06, Andrew Zhang <zh...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib][nio-charset] RI is inconsistent with spec when loading charset provider
Posted by Stepan Mishura <st...@gmail.com>.
On 8/1/06, Richard Liang wrote:
>
>
>
> Andrew Zhang wrote:
> > On 7/31/06, Mikhail Fursov <mi...@gmail.com> wrote:
> >>
> >> On 7/31/06, Andrew Zhang <zh...@gmail.com> 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.
I agree.
Thanks,
Stepan.
Please correct me if I'm wrong. Thanks a lot.
>
> Best regards,
> Richard
>
>
>
------------------------------------------------------
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
Re: [classlib][nio-charset] RI is inconsistent with spec when loading
charset provider
Posted by Richard Liang <ri...@gmail.com>.
Andrew Zhang wrote:
> On 7/31/06, Mikhail Fursov <mi...@gmail.com> wrote:
>>
>> On 7/31/06, Andrew Zhang <zh...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org