Nathan Beyer wrote:
On Wed, Dec 31, 2008 at 12:16 AM, Regis <[email protected]> wrote:
Nathan Beyer wrote:
On Tue, Dec 30, 2008 at 11:40 PM, Regis <[email protected]> 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 <[email protected]>
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 <[email protected]> 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.
