You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Regis <xu...@gmail.com> on 2008/12/30 11:25:15 UTC
[classlib][prefs] default provider of prefs
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.
Re: [classlib][prefs] default provider of prefs
Posted by Regis <xu...@gmail.com>.
Tony Wu wrote:
> Hi Regis,
>
> what if people want to set this property when launching java? will it
> be ignored if you do that in java code?
Yes, it will use the provider you set to the property, that's expected.
>
> On Tue, Dec 30, 2008 at 6:25 PM, Regis <xu...@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.
Re: [classlib][prefs] default provider of prefs
Posted by Tony Wu <wu...@gmail.com>.
Hi Regis,
what if people want to set this property when launching java? will it
be ignored if you do that in java code?
On Tue, Dec 30, 2008 at 6:25 PM, Regis <xu...@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.
>
--
Tony Wu
China Software Development Lab, IBM
Re: [classlib][prefs] default provider of prefs
Posted by Regis <xu...@gmail.com>.
JIRA raised at [1], and patch is available.
Would anyone want to try it?
[1] : https://issues.apache.org/jira/browse/HARMONY-6064
Nathan Beyer wrote:
> The only thing I'd consider would be doing a case-insensitive compare,
> perhaps by doing the following.
>
> osName = (osName == null ? null : osName.toLowerCase(Locale.ENGLISH));
> // only comparing ASCII, so assume english localge
>
> Also, need to check for null.
>
> if (osName != null && osName.startsWith("windows"))
>
> -Nathan
>
> On Wed, Dec 31, 2008 at 12:21 AM, Regis <xu...@gmail.com> wrote:
>> Thanks Nathan! So the code could be changed to:
>>
>> String osName = AccessController.doPrivileged(new
>> PrivilegedAction<String>() {
>> public String run() {
>> return System.getProperty("os.name"); //$NON-NLS-1$
>> }
>> });
>>
>> if (osName.startsWith("Windows")) {
>> factoryClassName =
>> "java.util.prefs.RegistryPreferencesFactoryImpl";
>> } else {
>> factoryClassName =
>> "java.util.prefs.FilePreferencesFactoryImpl";
>> }
>>
>>
>>
>> Nathan Beyer wrote:
>>> On Tue, Dec 30, 2008 at 11:54 PM, Regis <xu...@gmail.com> wrote:
>>>> Yes, but the value of "os.name" is human readable string, it must be
>>>> parsed
>>>> by hand, I'm not sure the format of the string is consistent on different
>>>> vm
>>>> or different versions of Windows, so I used File.pathSeparatorChar, as I
>>>> know only windows use "\\" as patch separator.
>>> According to what source is "os.name" to be used for human
>>> readability? It's not guaranteed to be anything, but I and many, many,
>>> many others have written code that utilizes it, as well as the
>>> correlated property, "os.arch". Additionally, "os.name" and "os.arch"
>>> are used as part of JNLP to define platform-specific resources [1].
>>>
>>> Here's a few sites that have attempted to catalog the various values,
>>> so as to allow for utilizing the values.
>>> http://mindprod.com/jgloss/properties.html#OSNAME
>>> http://lopica.sourceforge.net/os.html
>>>
>>> -Nathan
>>>
>>> [1]
>>> http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources
>>>
>>>
>>>> Nathan Beyer wrote:
>>>>> The System Property 'os.name' would be more appropriate for determining
>>>>> the OS.
>>>>>
>>>>> -Nathan
>>>>>
>>>>> On Tue, Dec 30, 2008 at 11:32 PM, Regis <xu...@gmail.com> wrote:
>>>>>> Nathan Beyer 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.
>>>>>> Maybe.
>>>>>>> Moving it to Java code is probably fine - the code just needs to use a
>>>>>>> default based on the OS.
>>>>>> I try the following patch, all tests are passed, so I think we could
>>>>>> move
>>>>>> it
>>>>>> to java code safely. I used File.pathSeparatorChar to test the
>>>>>> platform,
>>>>>> is
>>>>>> there any better way to do this?
>>>>>>
>>>>>>
>>>>>> Index: modules/luni/src/main/native/luni/shared/luniglob.c
>>>>>> =====================================================================
>>>>>> --- modules/luni/src/main/native/luni/shared/luniglob.c
>>>>>> +++ modules/luni/src/main/native/luni/shared/luniglob.c
>>>>>> @@ -162,21 +162,6 @@ JNI_OnLoad (JavaVM * vm, void *reserved)
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> - /* Set default PreferencesFactory implementation */
>>>>>> - (*vmInterface)->GetSystemProperty (vmInterface,
>>>>>> "java.util.prefs.PreferencesFactory", &propVal);
>>>>>> - if (propVal == NULL) {
>>>>>> - propRes = (*vmInterface)->SetSystemProperty (vmInterface,
>>>>>> - "java.util.prefs.PreferencesFactory",
>>>>>> -#ifdef _WIN32
>>>>>> - "java.util.prefs.RegistryPreferencesFactoryImpl");
>>>>>> -#else
>>>>>> - "java.util.prefs.FilePreferencesFactoryImpl");
>>>>>> -#endif
>>>>>> - if (VMI_ERROR_NONE != propRes) {
>>>>>> - /* goto fail2; */
>>>>>> - }
>>>>>> - }
>>>>>> -
>>>>>> /* Prefer Xalan compiler for better performance, see HARMONY-3209.
>>>>>> */
>>>>>> (*vmInterface)->GetSystemProperty (vmInterface,
>>>>>> "javax.xml.transform.TransformerFactory", &propVal);
>>>>>> if (propVal == NULL) {
>>>>>> Index: modules/prefs/src/main/java/java/util/prefs/Preferences.java
>>>>>> =====================================================================
>>>>>> --- modules/prefs/src/main/java/java/util/prefs/Preferences.java
>>>>>> +++ modules/prefs/src/main/java/java/util/prefs/Preferences.java
>>>>>> @@ -16,6 +16,7 @@
>>>>>>
>>>>>> package java.util.prefs;
>>>>>>
>>>>>> +import java.io.File;
>>>>>> import java.io.IOException;
>>>>>> import java.io.InputStream;
>>>>>> import java.io.OutputStream;
>>>>>> @@ -127,6 +128,13 @@ public abstract class Preferences {
>>>>>> return
>>>>>> System.getProperty("java.util.prefs.PreferencesFactory"); //$NON-NLS-1$
>>>>>> }
>>>>>> });
>>>>>> + if (factoryClassName == null) {
>>>>>> + if (File.pathSeparatorChar == '\\') {
>>>>>> + factoryClassName =
>>>>>> "java.util.prefs.RegistryPreferencesFactoryImpl";
>>>>>> + } else {
>>>>>> + factoryClassName =
>>>>>> "java.util.prefs.FilePreferencesFactoryImpl";
>>>>>> + }
>>>>>> + }
>>>>>> try {
>>>>>> ClassLoader loader =
>>>>>> Thread.currentThread().getContextClassLoader();
>>>>>> if(loader == null){
>>>>>>
>>>>>>
>>>>>>> -Nathan
>>>>>>>
>>>>>>> On Tue, Dec 30, 2008 at 4:25 AM, Regis <xu...@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.
>>
>
--
Best Regards,
Regis.
Re: [classlib][prefs] default provider of prefs
Posted by Regis <xu...@gmail.com>.
Thanks the advice, I'll raise JIRA and consolidate the patch.
Nathan Beyer wrote:
> The only thing I'd consider would be doing a case-insensitive compare,
> perhaps by doing the following.
>
> osName = (osName == null ? null : osName.toLowerCase(Locale.ENGLISH));
> // only comparing ASCII, so assume english localge
>
> Also, need to check for null.
>
> if (osName != null && osName.startsWith("windows"))
>
> -Nathan
>
> On Wed, Dec 31, 2008 at 12:21 AM, Regis <xu...@gmail.com> wrote:
>> Thanks Nathan! So the code could be changed to:
>>
>> String osName = AccessController.doPrivileged(new
>> PrivilegedAction<String>() {
>> public String run() {
>> return System.getProperty("os.name"); //$NON-NLS-1$
>> }
>> });
>>
>> if (osName.startsWith("Windows")) {
>> factoryClassName =
>> "java.util.prefs.RegistryPreferencesFactoryImpl";
>> } else {
>> factoryClassName =
>> "java.util.prefs.FilePreferencesFactoryImpl";
>> }
>>
>>
>>
>> Nathan Beyer wrote:
>>> On Tue, Dec 30, 2008 at 11:54 PM, Regis <xu...@gmail.com> wrote:
>>>> Yes, but the value of "os.name" is human readable string, it must be
>>>> parsed
>>>> by hand, I'm not sure the format of the string is consistent on different
>>>> vm
>>>> or different versions of Windows, so I used File.pathSeparatorChar, as I
>>>> know only windows use "\\" as patch separator.
>>> According to what source is "os.name" to be used for human
>>> readability? It's not guaranteed to be anything, but I and many, many,
>>> many others have written code that utilizes it, as well as the
>>> correlated property, "os.arch". Additionally, "os.name" and "os.arch"
>>> are used as part of JNLP to define platform-specific resources [1].
>>>
>>> Here's a few sites that have attempted to catalog the various values,
>>> so as to allow for utilizing the values.
>>> http://mindprod.com/jgloss/properties.html#OSNAME
>>> http://lopica.sourceforge.net/os.html
>>>
>>> -Nathan
>>>
>>> [1]
>>> http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources
>>>
>>>
>>>> Nathan Beyer wrote:
>>>>> The System Property 'os.name' would be more appropriate for determining
>>>>> the OS.
>>>>>
>>>>> -Nathan
>>>>>
>>>>> On Tue, Dec 30, 2008 at 11:32 PM, Regis <xu...@gmail.com> wrote:
>>>>>> Nathan Beyer 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.
>>>>>> Maybe.
>>>>>>> Moving it to Java code is probably fine - the code just needs to use a
>>>>>>> default based on the OS.
>>>>>> I try the following patch, all tests are passed, so I think we could
>>>>>> move
>>>>>> it
>>>>>> to java code safely. I used File.pathSeparatorChar to test the
>>>>>> platform,
>>>>>> is
>>>>>> there any better way to do this?
>>>>>>
>>>>>>
>>>>>> Index: modules/luni/src/main/native/luni/shared/luniglob.c
>>>>>> =====================================================================
>>>>>> --- modules/luni/src/main/native/luni/shared/luniglob.c
>>>>>> +++ modules/luni/src/main/native/luni/shared/luniglob.c
>>>>>> @@ -162,21 +162,6 @@ JNI_OnLoad (JavaVM * vm, void *reserved)
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> - /* Set default PreferencesFactory implementation */
>>>>>> - (*vmInterface)->GetSystemProperty (vmInterface,
>>>>>> "java.util.prefs.PreferencesFactory", &propVal);
>>>>>> - if (propVal == NULL) {
>>>>>> - propRes = (*vmInterface)->SetSystemProperty (vmInterface,
>>>>>> - "java.util.prefs.PreferencesFactory",
>>>>>> -#ifdef _WIN32
>>>>>> - "java.util.prefs.RegistryPreferencesFactoryImpl");
>>>>>> -#else
>>>>>> - "java.util.prefs.FilePreferencesFactoryImpl");
>>>>>> -#endif
>>>>>> - if (VMI_ERROR_NONE != propRes) {
>>>>>> - /* goto fail2; */
>>>>>> - }
>>>>>> - }
>>>>>> -
>>>>>> /* Prefer Xalan compiler for better performance, see HARMONY-3209.
>>>>>> */
>>>>>> (*vmInterface)->GetSystemProperty (vmInterface,
>>>>>> "javax.xml.transform.TransformerFactory", &propVal);
>>>>>> if (propVal == NULL) {
>>>>>> Index: modules/prefs/src/main/java/java/util/prefs/Preferences.java
>>>>>> =====================================================================
>>>>>> --- modules/prefs/src/main/java/java/util/prefs/Preferences.java
>>>>>> +++ modules/prefs/src/main/java/java/util/prefs/Preferences.java
>>>>>> @@ -16,6 +16,7 @@
>>>>>>
>>>>>> package java.util.prefs;
>>>>>>
>>>>>> +import java.io.File;
>>>>>> import java.io.IOException;
>>>>>> import java.io.InputStream;
>>>>>> import java.io.OutputStream;
>>>>>> @@ -127,6 +128,13 @@ public abstract class Preferences {
>>>>>> return
>>>>>> System.getProperty("java.util.prefs.PreferencesFactory"); //$NON-NLS-1$
>>>>>> }
>>>>>> });
>>>>>> + if (factoryClassName == null) {
>>>>>> + if (File.pathSeparatorChar == '\\') {
>>>>>> + factoryClassName =
>>>>>> "java.util.prefs.RegistryPreferencesFactoryImpl";
>>>>>> + } else {
>>>>>> + factoryClassName =
>>>>>> "java.util.prefs.FilePreferencesFactoryImpl";
>>>>>> + }
>>>>>> + }
>>>>>> try {
>>>>>> ClassLoader loader =
>>>>>> Thread.currentThread().getContextClassLoader();
>>>>>> if(loader == null){
>>>>>>
>>>>>>
>>>>>>> -Nathan
>>>>>>>
>>>>>>> On Tue, Dec 30, 2008 at 4:25 AM, Regis <xu...@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.
>>
>
--
Best Regards,
Regis.
Re: [classlib][prefs] default provider of prefs
Posted by Nathan Beyer <nd...@apache.org>.
The only thing I'd consider would be doing a case-insensitive compare,
perhaps by doing the following.
osName = (osName == null ? null : osName.toLowerCase(Locale.ENGLISH));
// only comparing ASCII, so assume english localge
Also, need to check for null.
if (osName != null && osName.startsWith("windows"))
-Nathan
On Wed, Dec 31, 2008 at 12:21 AM, Regis <xu...@gmail.com> wrote:
> Thanks Nathan! So the code could be changed to:
>
> String osName = AccessController.doPrivileged(new
> PrivilegedAction<String>() {
> public String run() {
> return System.getProperty("os.name"); //$NON-NLS-1$
> }
> });
>
> if (osName.startsWith("Windows")) {
> factoryClassName =
> "java.util.prefs.RegistryPreferencesFactoryImpl";
> } else {
> factoryClassName =
> "java.util.prefs.FilePreferencesFactoryImpl";
> }
>
>
>
> Nathan Beyer wrote:
>>
>> On Tue, Dec 30, 2008 at 11:54 PM, Regis <xu...@gmail.com> wrote:
>>>
>>> Yes, but the value of "os.name" is human readable string, it must be
>>> parsed
>>> by hand, I'm not sure the format of the string is consistent on different
>>> vm
>>> or different versions of Windows, so I used File.pathSeparatorChar, as I
>>> know only windows use "\\" as patch separator.
>>
>> According to what source is "os.name" to be used for human
>> readability? It's not guaranteed to be anything, but I and many, many,
>> many others have written code that utilizes it, as well as the
>> correlated property, "os.arch". Additionally, "os.name" and "os.arch"
>> are used as part of JNLP to define platform-specific resources [1].
>>
>> Here's a few sites that have attempted to catalog the various values,
>> so as to allow for utilizing the values.
>> http://mindprod.com/jgloss/properties.html#OSNAME
>> http://lopica.sourceforge.net/os.html
>>
>> -Nathan
>>
>> [1]
>> http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources
>>
>>
>>> Nathan Beyer wrote:
>>>>
>>>> The System Property 'os.name' would be more appropriate for determining
>>>> the OS.
>>>>
>>>> -Nathan
>>>>
>>>> On Tue, Dec 30, 2008 at 11:32 PM, Regis <xu...@gmail.com> wrote:
>>>>>
>>>>> Nathan Beyer 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.
>>>>>
>>>>> Maybe.
>>>>>>
>>>>>> Moving it to Java code is probably fine - the code just needs to use a
>>>>>> default based on the OS.
>>>>>
>>>>> I try the following patch, all tests are passed, so I think we could
>>>>> move
>>>>> it
>>>>> to java code safely. I used File.pathSeparatorChar to test the
>>>>> platform,
>>>>> is
>>>>> there any better way to do this?
>>>>>
>>>>>
>>>>> Index: modules/luni/src/main/native/luni/shared/luniglob.c
>>>>> =====================================================================
>>>>> --- modules/luni/src/main/native/luni/shared/luniglob.c
>>>>> +++ modules/luni/src/main/native/luni/shared/luniglob.c
>>>>> @@ -162,21 +162,6 @@ JNI_OnLoad (JavaVM * vm, void *reserved)
>>>>> }
>>>>> }
>>>>>
>>>>> - /* Set default PreferencesFactory implementation */
>>>>> - (*vmInterface)->GetSystemProperty (vmInterface,
>>>>> "java.util.prefs.PreferencesFactory", &propVal);
>>>>> - if (propVal == NULL) {
>>>>> - propRes = (*vmInterface)->SetSystemProperty (vmInterface,
>>>>> - "java.util.prefs.PreferencesFactory",
>>>>> -#ifdef _WIN32
>>>>> - "java.util.prefs.RegistryPreferencesFactoryImpl");
>>>>> -#else
>>>>> - "java.util.prefs.FilePreferencesFactoryImpl");
>>>>> -#endif
>>>>> - if (VMI_ERROR_NONE != propRes) {
>>>>> - /* goto fail2; */
>>>>> - }
>>>>> - }
>>>>> -
>>>>> /* Prefer Xalan compiler for better performance, see HARMONY-3209.
>>>>> */
>>>>> (*vmInterface)->GetSystemProperty (vmInterface,
>>>>> "javax.xml.transform.TransformerFactory", &propVal);
>>>>> if (propVal == NULL) {
>>>>> Index: modules/prefs/src/main/java/java/util/prefs/Preferences.java
>>>>> =====================================================================
>>>>> --- modules/prefs/src/main/java/java/util/prefs/Preferences.java
>>>>> +++ modules/prefs/src/main/java/java/util/prefs/Preferences.java
>>>>> @@ -16,6 +16,7 @@
>>>>>
>>>>> package java.util.prefs;
>>>>>
>>>>> +import java.io.File;
>>>>> import java.io.IOException;
>>>>> import java.io.InputStream;
>>>>> import java.io.OutputStream;
>>>>> @@ -127,6 +128,13 @@ public abstract class Preferences {
>>>>> return
>>>>> System.getProperty("java.util.prefs.PreferencesFactory"); //$NON-NLS-1$
>>>>> }
>>>>> });
>>>>> + if (factoryClassName == null) {
>>>>> + if (File.pathSeparatorChar == '\\') {
>>>>> + factoryClassName =
>>>>> "java.util.prefs.RegistryPreferencesFactoryImpl";
>>>>> + } else {
>>>>> + factoryClassName =
>>>>> "java.util.prefs.FilePreferencesFactoryImpl";
>>>>> + }
>>>>> + }
>>>>> try {
>>>>> ClassLoader loader =
>>>>> Thread.currentThread().getContextClassLoader();
>>>>> if(loader == null){
>>>>>
>>>>>
>>>>>> -Nathan
>>>>>>
>>>>>> On Tue, Dec 30, 2008 at 4:25 AM, Regis <xu...@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.
>
Re: [classlib][prefs] default provider of prefs
Posted by Regis <xu...@gmail.com>.
Thanks Nathan! So the code could be changed to:
String osName = AccessController.doPrivileged(new
PrivilegedAction<String>() {
public String run() {
return System.getProperty("os.name"); //$NON-NLS-1$
}
});
if (osName.startsWith("Windows")) {
factoryClassName =
"java.util.prefs.RegistryPreferencesFactoryImpl";
} else {
factoryClassName =
"java.util.prefs.FilePreferencesFactoryImpl";
}
Nathan Beyer wrote:
> On Tue, Dec 30, 2008 at 11:54 PM, Regis <xu...@gmail.com> wrote:
>> Yes, but the value of "os.name" is human readable string, it must be parsed
>> by hand, I'm not sure the format of the string is consistent on different vm
>> or different versions of Windows, so I used File.pathSeparatorChar, as I
>> know only windows use "\\" as patch separator.
>
> According to what source is "os.name" to be used for human
> readability? It's not guaranteed to be anything, but I and many, many,
> many others have written code that utilizes it, as well as the
> correlated property, "os.arch". Additionally, "os.name" and "os.arch"
> are used as part of JNLP to define platform-specific resources [1].
>
> Here's a few sites that have attempted to catalog the various values,
> so as to allow for utilizing the values.
> http://mindprod.com/jgloss/properties.html#OSNAME
> http://lopica.sourceforge.net/os.html
>
> -Nathan
>
> [1] http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources
>
>
>> Nathan Beyer wrote:
>>> The System Property 'os.name' would be more appropriate for determining
>>> the OS.
>>>
>>> -Nathan
>>>
>>> On Tue, Dec 30, 2008 at 11:32 PM, Regis <xu...@gmail.com> wrote:
>>>> Nathan Beyer 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.
>>>> Maybe.
>>>>> Moving it to Java code is probably fine - the code just needs to use a
>>>>> default based on the OS.
>>>> I try the following patch, all tests are passed, so I think we could move
>>>> it
>>>> to java code safely. I used File.pathSeparatorChar to test the platform,
>>>> is
>>>> there any better way to do this?
>>>>
>>>>
>>>> Index: modules/luni/src/main/native/luni/shared/luniglob.c
>>>> =====================================================================
>>>> --- modules/luni/src/main/native/luni/shared/luniglob.c
>>>> +++ modules/luni/src/main/native/luni/shared/luniglob.c
>>>> @@ -162,21 +162,6 @@ JNI_OnLoad (JavaVM * vm, void *reserved)
>>>> }
>>>> }
>>>>
>>>> - /* Set default PreferencesFactory implementation */
>>>> - (*vmInterface)->GetSystemProperty (vmInterface,
>>>> "java.util.prefs.PreferencesFactory", &propVal);
>>>> - if (propVal == NULL) {
>>>> - propRes = (*vmInterface)->SetSystemProperty (vmInterface,
>>>> - "java.util.prefs.PreferencesFactory",
>>>> -#ifdef _WIN32
>>>> - "java.util.prefs.RegistryPreferencesFactoryImpl");
>>>> -#else
>>>> - "java.util.prefs.FilePreferencesFactoryImpl");
>>>> -#endif
>>>> - if (VMI_ERROR_NONE != propRes) {
>>>> - /* goto fail2; */
>>>> - }
>>>> - }
>>>> -
>>>> /* Prefer Xalan compiler for better performance, see HARMONY-3209.
>>>> */
>>>> (*vmInterface)->GetSystemProperty (vmInterface,
>>>> "javax.xml.transform.TransformerFactory", &propVal);
>>>> if (propVal == NULL) {
>>>> Index: modules/prefs/src/main/java/java/util/prefs/Preferences.java
>>>> =====================================================================
>>>> --- modules/prefs/src/main/java/java/util/prefs/Preferences.java
>>>> +++ modules/prefs/src/main/java/java/util/prefs/Preferences.java
>>>> @@ -16,6 +16,7 @@
>>>>
>>>> package java.util.prefs;
>>>>
>>>> +import java.io.File;
>>>> import java.io.IOException;
>>>> import java.io.InputStream;
>>>> import java.io.OutputStream;
>>>> @@ -127,6 +128,13 @@ public abstract class Preferences {
>>>> return
>>>> System.getProperty("java.util.prefs.PreferencesFactory"); //$NON-NLS-1$
>>>> }
>>>> });
>>>> + if (factoryClassName == null) {
>>>> + if (File.pathSeparatorChar == '\\') {
>>>> + factoryClassName =
>>>> "java.util.prefs.RegistryPreferencesFactoryImpl";
>>>> + } else {
>>>> + factoryClassName =
>>>> "java.util.prefs.FilePreferencesFactoryImpl";
>>>> + }
>>>> + }
>>>> try {
>>>> ClassLoader loader =
>>>> Thread.currentThread().getContextClassLoader();
>>>> if(loader == null){
>>>>
>>>>
>>>>> -Nathan
>>>>>
>>>>> On Tue, Dec 30, 2008 at 4:25 AM, Regis <xu...@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.
Re: [classlib][prefs] default provider of prefs
Posted by Sean Qiu <se...@gmail.com>.
This reference is helpful.Thanks, Nathan
2008/12/31 Nathan Beyer <nb...@gmail.com>
> On Tue, Dec 30, 2008 at 11:54 PM, Regis <xu...@gmail.com> wrote:
> > Yes, but the value of "os.name" is human readable string, it must be
> parsed
> > by hand, I'm not sure the format of the string is consistent on different
> vm
> > or different versions of Windows, so I used File.pathSeparatorChar, as I
> > know only windows use "\\" as patch separator.
>
> According to what source is "os.name" to be used for human
> readability? It's not guaranteed to be anything, but I and many, many,
> many others have written code that utilizes it, as well as the
> correlated property, "os.arch". Additionally, "os.name" and "os.arch"
> are used as part of JNLP to define platform-specific resources [1].
>
> Here's a few sites that have attempted to catalog the various values,
> so as to allow for utilizing the values.
> http://mindprod.com/jgloss/properties.html#OSNAME
> http://lopica.sourceforge.net/os.html
>
> -Nathan
>
> [1]
> http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources
>
>
> >
> > Nathan Beyer wrote:
> >>
> >> The System Property 'os.name' would be more appropriate for determining
> >> the OS.
> >>
> >> -Nathan
> >>
> >> On Tue, Dec 30, 2008 at 11:32 PM, Regis <xu...@gmail.com> wrote:
> >>>
> >>> Nathan Beyer 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.
> >>>
> >>> Maybe.
> >>>>
> >>>> Moving it to Java code is probably fine - the code just needs to use a
> >>>> default based on the OS.
> >>>
> >>> I try the following patch, all tests are passed, so I think we could
> move
> >>> it
> >>> to java code safely. I used File.pathSeparatorChar to test the
> platform,
> >>> is
> >>> there any better way to do this?
> >>>
> >>>
> >>> Index: modules/luni/src/main/native/luni/shared/luniglob.c
> >>> =====================================================================
> >>> --- modules/luni/src/main/native/luni/shared/luniglob.c
> >>> +++ modules/luni/src/main/native/luni/shared/luniglob.c
> >>> @@ -162,21 +162,6 @@ JNI_OnLoad (JavaVM * vm, void *reserved)
> >>> }
> >>> }
> >>>
> >>> - /* Set default PreferencesFactory implementation */
> >>> - (*vmInterface)->GetSystemProperty (vmInterface,
> >>> "java.util.prefs.PreferencesFactory", &propVal);
> >>> - if (propVal == NULL) {
> >>> - propRes = (*vmInterface)->SetSystemProperty (vmInterface,
> >>> - "java.util.prefs.PreferencesFactory",
> >>> -#ifdef _WIN32
> >>> - "java.util.prefs.RegistryPreferencesFactoryImpl");
> >>> -#else
> >>> - "java.util.prefs.FilePreferencesFactoryImpl");
> >>> -#endif
> >>> - if (VMI_ERROR_NONE != propRes) {
> >>> - /* goto fail2; */
> >>> - }
> >>> - }
> >>> -
> >>> /* Prefer Xalan compiler for better performance, see
> HARMONY-3209.
> >>> */
> >>> (*vmInterface)->GetSystemProperty (vmInterface,
> >>> "javax.xml.transform.TransformerFactory", &propVal);
> >>> if (propVal == NULL) {
> >>> Index: modules/prefs/src/main/java/java/util/prefs/Preferences.java
> >>> =====================================================================
> >>> --- modules/prefs/src/main/java/java/util/prefs/Preferences.java
> >>> +++ modules/prefs/src/main/java/java/util/prefs/Preferences.java
> >>> @@ -16,6 +16,7 @@
> >>>
> >>> package java.util.prefs;
> >>>
> >>> +import java.io.File;
> >>> import java.io.IOException;
> >>> import java.io.InputStream;
> >>> import java.io.OutputStream;
> >>> @@ -127,6 +128,13 @@ public abstract class Preferences {
> >>> return
> >>> System.getProperty("java.util.prefs.PreferencesFactory"); //$NON-NLS-1$
> >>> }
> >>> });
> >>> + if (factoryClassName == null) {
> >>> + if (File.pathSeparatorChar == '\\') {
> >>> + factoryClassName =
> >>> "java.util.prefs.RegistryPreferencesFactoryImpl";
> >>> + } else {
> >>> + factoryClassName =
> >>> "java.util.prefs.FilePreferencesFactoryImpl";
> >>> + }
> >>> + }
> >>> try {
> >>> ClassLoader loader =
> >>> Thread.currentThread().getContextClassLoader();
> >>> if(loader == null){
> >>>
> >>>
> >>>> -Nathan
> >>>>
> >>>> On Tue, Dec 30, 2008 at 4:25 AM, Regis <xu...@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
Re: [classlib][prefs] default provider of prefs
Posted by Nathan Beyer <nb...@gmail.com>.
On Tue, Dec 30, 2008 at 11:54 PM, Regis <xu...@gmail.com> wrote:
> Yes, but the value of "os.name" is human readable string, it must be parsed
> by hand, I'm not sure the format of the string is consistent on different vm
> or different versions of Windows, so I used File.pathSeparatorChar, as I
> know only windows use "\\" as patch separator.
According to what source is "os.name" to be used for human
readability? It's not guaranteed to be anything, but I and many, many,
many others have written code that utilizes it, as well as the
correlated property, "os.arch". Additionally, "os.name" and "os.arch"
are used as part of JNLP to define platform-specific resources [1].
Here's a few sites that have attempted to catalog the various values,
so as to allow for utilizing the values.
http://mindprod.com/jgloss/properties.html#OSNAME
http://lopica.sourceforge.net/os.html
-Nathan
[1] http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax.html#resources
>
> Nathan Beyer wrote:
>>
>> The System Property 'os.name' would be more appropriate for determining
>> the OS.
>>
>> -Nathan
>>
>> On Tue, Dec 30, 2008 at 11:32 PM, Regis <xu...@gmail.com> wrote:
>>>
>>> Nathan Beyer 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.
>>>
>>> Maybe.
>>>>
>>>> Moving it to Java code is probably fine - the code just needs to use a
>>>> default based on the OS.
>>>
>>> I try the following patch, all tests are passed, so I think we could move
>>> it
>>> to java code safely. I used File.pathSeparatorChar to test the platform,
>>> is
>>> there any better way to do this?
>>>
>>>
>>> Index: modules/luni/src/main/native/luni/shared/luniglob.c
>>> =====================================================================
>>> --- modules/luni/src/main/native/luni/shared/luniglob.c
>>> +++ modules/luni/src/main/native/luni/shared/luniglob.c
>>> @@ -162,21 +162,6 @@ JNI_OnLoad (JavaVM * vm, void *reserved)
>>> }
>>> }
>>>
>>> - /* Set default PreferencesFactory implementation */
>>> - (*vmInterface)->GetSystemProperty (vmInterface,
>>> "java.util.prefs.PreferencesFactory", &propVal);
>>> - if (propVal == NULL) {
>>> - propRes = (*vmInterface)->SetSystemProperty (vmInterface,
>>> - "java.util.prefs.PreferencesFactory",
>>> -#ifdef _WIN32
>>> - "java.util.prefs.RegistryPreferencesFactoryImpl");
>>> -#else
>>> - "java.util.prefs.FilePreferencesFactoryImpl");
>>> -#endif
>>> - if (VMI_ERROR_NONE != propRes) {
>>> - /* goto fail2; */
>>> - }
>>> - }
>>> -
>>> /* Prefer Xalan compiler for better performance, see HARMONY-3209.
>>> */
>>> (*vmInterface)->GetSystemProperty (vmInterface,
>>> "javax.xml.transform.TransformerFactory", &propVal);
>>> if (propVal == NULL) {
>>> Index: modules/prefs/src/main/java/java/util/prefs/Preferences.java
>>> =====================================================================
>>> --- modules/prefs/src/main/java/java/util/prefs/Preferences.java
>>> +++ modules/prefs/src/main/java/java/util/prefs/Preferences.java
>>> @@ -16,6 +16,7 @@
>>>
>>> package java.util.prefs;
>>>
>>> +import java.io.File;
>>> import java.io.IOException;
>>> import java.io.InputStream;
>>> import java.io.OutputStream;
>>> @@ -127,6 +128,13 @@ public abstract class Preferences {
>>> return
>>> System.getProperty("java.util.prefs.PreferencesFactory"); //$NON-NLS-1$
>>> }
>>> });
>>> + if (factoryClassName == null) {
>>> + if (File.pathSeparatorChar == '\\') {
>>> + factoryClassName =
>>> "java.util.prefs.RegistryPreferencesFactoryImpl";
>>> + } else {
>>> + factoryClassName =
>>> "java.util.prefs.FilePreferencesFactoryImpl";
>>> + }
>>> + }
>>> try {
>>> ClassLoader loader =
>>> Thread.currentThread().getContextClassLoader();
>>> if(loader == null){
>>>
>>>
>>>> -Nathan
>>>>
>>>> On Tue, Dec 30, 2008 at 4:25 AM, Regis <xu...@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.
>
Re: [classlib][prefs] default provider of prefs
Posted by Regis <xu...@gmail.com>.
Yes, but the value of "os.name" is human readable string, it must be
parsed by hand, I'm not sure the format of the string is consistent on
different vm or different versions of Windows, so I used
File.pathSeparatorChar, as I know only windows use "\\" as patch separator.
Nathan Beyer wrote:
> The System Property 'os.name' would be more appropriate for determining the OS.
>
> -Nathan
>
> On Tue, Dec 30, 2008 at 11:32 PM, Regis <xu...@gmail.com> wrote:
>>
>> Nathan Beyer 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.
>> Maybe.
>>> Moving it to Java code is probably fine - the code just needs to use a
>>> default based on the OS.
>> I try the following patch, all tests are passed, so I think we could move it
>> to java code safely. I used File.pathSeparatorChar to test the platform, is
>> there any better way to do this?
>>
>>
>> Index: modules/luni/src/main/native/luni/shared/luniglob.c
>> =====================================================================
>> --- modules/luni/src/main/native/luni/shared/luniglob.c
>> +++ modules/luni/src/main/native/luni/shared/luniglob.c
>> @@ -162,21 +162,6 @@ JNI_OnLoad (JavaVM * vm, void *reserved)
>> }
>> }
>>
>> - /* Set default PreferencesFactory implementation */
>> - (*vmInterface)->GetSystemProperty (vmInterface,
>> "java.util.prefs.PreferencesFactory", &propVal);
>> - if (propVal == NULL) {
>> - propRes = (*vmInterface)->SetSystemProperty (vmInterface,
>> - "java.util.prefs.PreferencesFactory",
>> -#ifdef _WIN32
>> - "java.util.prefs.RegistryPreferencesFactoryImpl");
>> -#else
>> - "java.util.prefs.FilePreferencesFactoryImpl");
>> -#endif
>> - if (VMI_ERROR_NONE != propRes) {
>> - /* goto fail2; */
>> - }
>> - }
>> -
>> /* Prefer Xalan compiler for better performance, see HARMONY-3209. */
>> (*vmInterface)->GetSystemProperty (vmInterface,
>> "javax.xml.transform.TransformerFactory", &propVal);
>> if (propVal == NULL) {
>> Index: modules/prefs/src/main/java/java/util/prefs/Preferences.java
>> =====================================================================
>> --- modules/prefs/src/main/java/java/util/prefs/Preferences.java
>> +++ modules/prefs/src/main/java/java/util/prefs/Preferences.java
>> @@ -16,6 +16,7 @@
>>
>> package java.util.prefs;
>>
>> +import java.io.File;
>> import java.io.IOException;
>> import java.io.InputStream;
>> import java.io.OutputStream;
>> @@ -127,6 +128,13 @@ public abstract class Preferences {
>> return
>> System.getProperty("java.util.prefs.PreferencesFactory"); //$NON-NLS-1$
>> }
>> });
>> + if (factoryClassName == null) {
>> + if (File.pathSeparatorChar == '\\') {
>> + factoryClassName =
>> "java.util.prefs.RegistryPreferencesFactoryImpl";
>> + } else {
>> + factoryClassName =
>> "java.util.prefs.FilePreferencesFactoryImpl";
>> + }
>> + }
>> try {
>> ClassLoader loader =
>> Thread.currentThread().getContextClassLoader();
>> if(loader == null){
>>
>>
>>> -Nathan
>>>
>>> On Tue, Dec 30, 2008 at 4:25 AM, Regis <xu...@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.
Re: [classlib][prefs] default provider of prefs
Posted by Nathan Beyer <nd...@apache.org>.
The System Property 'os.name' would be more appropriate for determining the OS.
-Nathan
On Tue, Dec 30, 2008 at 11:32 PM, Regis <xu...@gmail.com> wrote:
>
>
> Nathan Beyer 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.
>
> Maybe.
>>
>> Moving it to Java code is probably fine - the code just needs to use a
>> default based on the OS.
>
> I try the following patch, all tests are passed, so I think we could move it
> to java code safely. I used File.pathSeparatorChar to test the platform, is
> there any better way to do this?
>
>
> Index: modules/luni/src/main/native/luni/shared/luniglob.c
> =====================================================================
> --- modules/luni/src/main/native/luni/shared/luniglob.c
> +++ modules/luni/src/main/native/luni/shared/luniglob.c
> @@ -162,21 +162,6 @@ JNI_OnLoad (JavaVM * vm, void *reserved)
> }
> }
>
> - /* Set default PreferencesFactory implementation */
> - (*vmInterface)->GetSystemProperty (vmInterface,
> "java.util.prefs.PreferencesFactory", &propVal);
> - if (propVal == NULL) {
> - propRes = (*vmInterface)->SetSystemProperty (vmInterface,
> - "java.util.prefs.PreferencesFactory",
> -#ifdef _WIN32
> - "java.util.prefs.RegistryPreferencesFactoryImpl");
> -#else
> - "java.util.prefs.FilePreferencesFactoryImpl");
> -#endif
> - if (VMI_ERROR_NONE != propRes) {
> - /* goto fail2; */
> - }
> - }
> -
> /* Prefer Xalan compiler for better performance, see HARMONY-3209. */
> (*vmInterface)->GetSystemProperty (vmInterface,
> "javax.xml.transform.TransformerFactory", &propVal);
> if (propVal == NULL) {
> Index: modules/prefs/src/main/java/java/util/prefs/Preferences.java
> =====================================================================
> --- modules/prefs/src/main/java/java/util/prefs/Preferences.java
> +++ modules/prefs/src/main/java/java/util/prefs/Preferences.java
> @@ -16,6 +16,7 @@
>
> package java.util.prefs;
>
> +import java.io.File;
> import java.io.IOException;
> import java.io.InputStream;
> import java.io.OutputStream;
> @@ -127,6 +128,13 @@ public abstract class Preferences {
> return
> System.getProperty("java.util.prefs.PreferencesFactory"); //$NON-NLS-1$
> }
> });
> + if (factoryClassName == null) {
> + if (File.pathSeparatorChar == '\\') {
> + factoryClassName =
> "java.util.prefs.RegistryPreferencesFactoryImpl";
> + } else {
> + factoryClassName =
> "java.util.prefs.FilePreferencesFactoryImpl";
> + }
> + }
> try {
> ClassLoader loader =
> Thread.currentThread().getContextClassLoader();
> if(loader == null){
>
>
>> -Nathan
>>
>> On Tue, Dec 30, 2008 at 4:25 AM, Regis <xu...@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.
>
Re: [classlib][prefs] default provider of prefs
Posted by Regis <xu...@gmail.com>.
Nathan Beyer 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.
Maybe.
>
> Moving it to Java code is probably fine - the code just needs to use a
> default based on the OS.
I try the following patch, all tests are passed, so I think we could
move it to java code safely. I used File.pathSeparatorChar to test the
platform, is there any better way to do this?
Index: modules/luni/src/main/native/luni/shared/luniglob.c
=====================================================================
--- modules/luni/src/main/native/luni/shared/luniglob.c
+++ modules/luni/src/main/native/luni/shared/luniglob.c
@@ -162,21 +162,6 @@ JNI_OnLoad (JavaVM * vm, void *reserved)
}
}
- /* Set default PreferencesFactory implementation */
- (*vmInterface)->GetSystemProperty (vmInterface,
"java.util.prefs.PreferencesFactory", &propVal);
- if (propVal == NULL) {
- propRes = (*vmInterface)->SetSystemProperty (vmInterface,
- "java.util.prefs.PreferencesFactory",
-#ifdef _WIN32
- "java.util.prefs.RegistryPreferencesFactoryImpl");
-#else
- "java.util.prefs.FilePreferencesFactoryImpl");
-#endif
- if (VMI_ERROR_NONE != propRes) {
- /* goto fail2; */
- }
- }
-
/* Prefer Xalan compiler for better performance, see
HARMONY-3209. */
(*vmInterface)->GetSystemProperty (vmInterface,
"javax.xml.transform.TransformerFactory", &propVal);
if (propVal == NULL) {
Index: modules/prefs/src/main/java/java/util/prefs/Preferences.java
=====================================================================
--- modules/prefs/src/main/java/java/util/prefs/Preferences.java
+++ modules/prefs/src/main/java/java/util/prefs/Preferences.java
@@ -16,6 +16,7 @@
package java.util.prefs;
+import java.io.File;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
@@ -127,6 +128,13 @@ public abstract class Preferences {
return
System.getProperty("java.util.prefs.PreferencesFactory"); //$NON-NLS-1$
}
});
+ if (factoryClassName == null) {
+ if (File.pathSeparatorChar == '\\') {
+ factoryClassName =
"java.util.prefs.RegistryPreferencesFactoryImpl";
+ } else {
+ factoryClassName =
"java.util.prefs.FilePreferencesFactoryImpl";
+ }
+ }
try {
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
if(loader == null){
> -Nathan
>
> On Tue, Dec 30, 2008 at 4:25 AM, Regis <xu...@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.
Re: [classlib][prefs] default provider of prefs
Posted by Nathan Beyer <nb...@gmail.com>.
That wasn't what was asked, nor was that what I commented about,
unless I'm missing something. What does putting the platform default
into native code have to do with the order of service provider load?
Any reason the algorithm can't be implemented all in Java with the
following steps.
1. Check System Property, if set, construct; if not set or failure, do step 2
2. Check SPI files, if available, load, construct, etc; if not set or
all fail, do step 3
3. Determine OS, load OS-specific provider
I haven't looked at the code yet - is the code setting the system
property to communicate the classname?
-Nathan
On Tue, Dec 30, 2008 at 7:18 PM, Charles Lee <li...@gmail.com> 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.
>
> On Tue, Dec 30, 2008 at 11:37 PM, Nathan Beyer <nd...@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...@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.
>> >
>>
>
>
>
> --
> Yours sincerely,
> Charles Lee
> China Software Development Lab, IBM
>
Re: [classlib][prefs] default provider of prefs
Posted by Regis <xu...@gmail.com>.
the JIRA has filed at:
https://issues.apache.org/jira/browse/HARMONY-6063
Regis wrote:
>
>
> Nathan Beyer wrote:
>> On Wed, Dec 31, 2008 at 12:16 AM, Regis <xu...@gmail.com> wrote:
>>>
>>> Nathan Beyer wrote:
>>>> On Tue, Dec 30, 2008 at 11:40 PM, Regis <xu...@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 <nd...@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...@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.
Re: [classlib][prefs] default provider of prefs
Posted by Regis <xu...@gmail.com>.
Nathan Beyer wrote:
> On Wed, Dec 31, 2008 at 12:16 AM, Regis <xu...@gmail.com> wrote:
>>
>> Nathan Beyer wrote:
>>> On Tue, Dec 30, 2008 at 11:40 PM, Regis <xu...@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 <nd...@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...@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.
Re: [classlib][prefs] default provider of prefs
Posted by Sean Qiu <se...@gmail.com>.
2008/12/31 Nathan Beyer <nd...@apache.org>
> On Wed, Dec 31, 2008 at 12:16 AM, Regis <xu...@gmail.com> wrote:
> >
> >
> > Nathan Beyer wrote:
> >>
> >> On Tue, Dec 30, 2008 at 11:40 PM, Regis <xu...@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 <nd...@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...@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
Re: [classlib][prefs] default provider of prefs
Posted by Nathan Beyer <nd...@apache.org>.
On Wed, Dec 31, 2008 at 12:16 AM, Regis <xu...@gmail.com> wrote:
>
>
> Nathan Beyer wrote:
>>
>> On Tue, Dec 30, 2008 at 11:40 PM, Regis <xu...@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
>
>>
>> [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 <nd...@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...@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.
>
Re: [classlib][prefs] default provider of prefs
Posted by Regis <xu...@gmail.com>.
Nathan Beyer wrote:
> On Tue, Dec 30, 2008 at 11:40 PM, Regis <xu...@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.
>
> [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 <nd...@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...@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.
Re: [classlib][prefs] default provider of prefs
Posted by Nathan Beyer <nd...@apache.org>.
On Tue, Dec 30, 2008 at 11:40 PM, Regis <xu...@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.
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.
[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 <nd...@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...@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.
>
Re: [classlib][prefs] default provider of prefs
Posted by Regis <xu...@gmail.com>.
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.
>
> On Tue, Dec 30, 2008 at 11:37 PM, Nathan Beyer <nd...@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...@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.
Re: [classlib][prefs] default provider of prefs
Posted by Charles Lee <li...@gmail.com>.
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.
On Tue, Dec 30, 2008 at 11:37 PM, Nathan Beyer <nd...@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...@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.
> >
>
--
Yours sincerely,
Charles Lee
China Software Development Lab, IBM
Re: [classlib][prefs] default provider of prefs
Posted by Nathan Beyer <nd...@apache.org>.
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...@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.
>