harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regis <xu.re...@gmail.com>
Subject Re: [classlib][prefs] default provider of prefs
Date Wed, 31 Dec 2008 06:54:56 GMT


Nathan Beyer wrote:
> On Wed, Dec 31, 2008 at 12:16 AM, Regis <xu.regis@gmail.com> wrote:
>>
>> Nathan Beyer wrote:
>>> On Tue, Dec 30, 2008 at 11:40 PM, Regis <xu.regis@gmail.com> wrote:
>>>> Charles Lee wrote:
>>>>> Hi Nathan,Prefs has its priority list to load a factory builder. The
>>>>> first
>>>>> priority is System Property, the second is service info in any jar file,
>>>>> and
>>>>> the last the is platform default.
>>>>> If we have set the platform default value to the System Property in the
>>>>> luni
>>>>> before the prefs's constructor, that will make platform default be the
>>>>> first
>>>>> priority. And user can not specify the factory builder by service info
>>>>> in
>>>>> the jar file.
>>>> The algorithm of load provider is implementation specific, spec just say:
>>>>
>>>> "Every J2SE implementation must provide some means of specifying which
>>>> PreferencesFactory implementation is used to generate the root
>>>> preferences
>>>> nodes"
>>>>
>>>> Harmony's implementation just read the property, that satisfy the spec,
>>>> whether to follow RI is another story, I think.
>>> I disagree - we already follow Sun's algorithm, which is documented
>>> very well in the spec [1], though it says "implementation note", so
>>> that argument doesn't work for me.
>> In my understanding, "implementation note" just describe the behaviors of
>> RI, it say clearly
>>
>> "In Sun's JRE, the PreferencesFactory  implementation is located as follows:
>> "
>>
>> and
>>
>> "Every J2SE implementation must provide some means..."
>>
>>> Now that I've seen the code, my conclusion is that Harmony's
>>> implementation of this "implementation note" algorithm is just ugly
>>> and should be cleaned up. The algorithm is poorly encapsulated.
>>>
>>> Harmony already sticks to this behavior, there's no reason to change
>>> it now; it just needs to be cleaned up.
>> step 2 of Sun's algorithm need to search provider-configuration file in
>> system class loader, I can't found it in Harmony's code.
> 
> I was taking Charles Lee's word for it when we first said there was a
> 'priority list' and then said the spec haven't a defined mechanism.
> Assuming he wouldn't contradict himself and my inability to find any
> reference to it in short order, I concluded the code was just messy.
> 
> I believe we should add it into the code base though. Since it's part
> of the Javadoc and not separate documentation, it's pretty well set.
> We've made much more trivial comprimises to match RI functionality -
> throwing exceptions not documented, NOT throwing exceptions that were
> documented, etc. We can do that as a separate bug/enhancement though.
> 
> -Nathan
> 

Agree. I'll file a JIRA to track this issue.

>>> [1]
>>> http://java.sun.com/j2se/1.5.0/docs/api/java/util/prefs/Preferences.html
>>>
>>> -Nathan
>>>
>>> -Nathan
>>>
>>>>> On Tue, Dec 30, 2008 at 11:37 PM, Nathan Beyer <ndbeyer@apache.org>
>>>>> wrote:
>>>>>
>>>>>> I doubt there is any significant reason for it other than the default
>>>>>> is based on the OS and the native might have been an easy decision
>>>>>> point.
>>>>>>
>>>>>> Moving it to Java code is probably fine - the code just needs to
use a
>>>>>> default based on the OS.
>>>>>>
>>>>>> -Nathan
>>>>>>
>>>>>> On Tue, Dec 30, 2008 at 4:25 AM, Regis <xu.regis@gmail.com>
wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> The provider of prefs is controlled by the property
>>>>>>> "java.util.prefs.PreferencesFactory" in Harmony, and we also
have
>>>>>> different
>>>>>>> default values for it on Linux and Windows, but the default values
are
>>>>>> set
>>>>>>> in luni module at modules/luni/src/main/native/luni/shared/luniglob.c,
>>>>>>> are there any special concerns that we must do it in luni native
code?
>>>>>>> Or
>>>>>> is
>>>>>>> it possible set it in prefs module with java code, like this:
>>>>>>>
>>>>>>>       if (factoryClassName == null) {
>>>>>>>           if (isWindows) {
>>>>>>>               factoryClassName =
>>>>>>> "java.util.prefs.RegistryPreferencesFactoryImpl";
>>>>>>>           } else {
>>>>>>>               factoryClassName =
>>>>>>> "java.util.prefs.FilePreferencesFactoryImpl";
>>>>>>>           }
>>>>>>>       }
>>>>>>>
>>>>>>> I think there must be a way to get current platform at runtime
in
>>>>>>> java.
>>>>>>>
>>>>>>> --
>>>>>>> Best Regards,
>>>>>>> Regis.
>>>>>>>
>>>>>
>>>> --
>>>> Best Regards,
>>>> Regis.
>>>>
>> --
>> Best Regards,
>> Regis.
>>
> 

-- 
Best Regards,
Regis.

Mime
View raw message