harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Qiu" <sean.xx....@gmail.com>
Subject Re: [classlib][prefs] default provider of prefs
Date Sun, 04 Jan 2009 07:18:20 GMT
2008/12/31 Nathan Beyer <ndbeyer@apache.org>

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

+1 the spec explicitly tell the behavior of RI.
I think we should follow RI in this case.


>
> 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
>
> >
> >>
> >> [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
Sean, Xiao Xia Qiu

China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message