Hi Paulex,

Thanks also to Leo for providing this implementation. I tried a couple of simple
tests on Windows on the getenv() and getenv(String) methods.

The getenv() method seems to work fine, giving me a list of the environment properties.
I compared this list to those output by the Sun and IBM VMs, and found only
one property missing (the rest were the same). It is a property with key "=::" and value "::\" (without the quote marks). I have no idea what they are for or
whether they are important. Can anyone shed any light on these?


When testing the getenv(String) method I hit a snag. If I try the following line:

 System.out.println(System.getenv("PATH"));

on the current classlib, I get "null" output, whereas on J9 and Sun 50 I get
the correct path contents printed. I looked a little closer and found that
this is because my path environment variable is actually called "Path". So
it seems that on Windows the RI and IBM vms are case insensitive,
but Harmony is not. The spec for getenv(String) states:

"On UNIX systems the alphabetic case of 'name' is typically significant,
while on Microsoft Windows systems it is typically not. For example, the
expression 'System.getenv("FOO").equals(System.getenv("foo"))' is
likely to be true on Microsoft Windows."

It seems we see this difference with Harmony because the current
implementation tries to carry out a lookup in a Map with the environment
variable name as the key. Since this lookup is case sensitive, we do not find
the entry.

IMHO we should match the RI behaviour on this one. I would propose
a solution that involves making Environment.getenv(String) carry out a
direct call to a native function that in turn calls GetEnvironmentVariable() [1] on
Windows and (I think) getenv() on Linux[2]. This way the case-sensitivity
should match that typical to the platform. Do you agree?


I would also remove the static initialisation block from that class, and move
its contents into the getenv() method instead, just returning the Map
directly without need to staticly store it in the class. I suggest this for two
reasons:
1) It reduces the long term memory requirements of the Environment
class. With the current implementation all the Strings are loaded into
memory the first time the class is loaded, and then they stay in memory
until the class is unloaded or the VM exits, even if they are never used
again.
2) With the current implementation, it is possible that the returned
environment variables are out of date. There could be a scenario where
the Environment.getenv() method is queried, then some actions happen
in an application that cause environment variables to change, and the
getenv() is queried again. The result from getenv() would not change
frmo one call to the next even though the environment has. I think the
right solution here is to rebuild the Map every time getenv() is called.

What do you think of these suggestions Paulex, Leo?

Regards,
Oliver


[1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getenvironmentvariable.asp
[2] http://man.he.net/man3/getenv

Paulex Yang wrote:
Oli

Thanks Leo for volunteering, I've checked in his patch for HARMONY-1155 at revision r431560, i.e., the implementation of Environment class, would you help to verify if that implementation is OK to use? or it takes effect automatically at once? Thank you.

Oliver Deakin wrote:
Leo Li wrote:
Hi, Oliver:
    I am willing to implement the
org.apache.harmony.luni.platform.Environment class with
the  two  getenv() methods.

Great, thanks for volunteering Leo!


Good luck!


On 8/8/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:

Great news.

In the future, could you please prefix the subject line with something
appropriate, like [general]?  It helps people prioritize and such...

thanks


Oliver Deakin wrote:
> Hi all,
>
> I'm pleased to announce that a new 5.0 level IBM VME will be made
> available soon at:
>  http://www-128.ibm.com/developerworks/java/jdk/harmony/index.html
>
> The new VME downloads are named Harmony-vme-win.IA32-v4.zip and
> Harmony-vme-linux.IA32-v4.tar.gz. I would like to stress that if you
> download these packages now, they will *not* work with the class library
> code currently in Harmony Subversion. I have created a new JIRA
> (HARMONY-1084) containing patches for Harmony classlib and the Eclipse
> Harmony plugin which are required to be able to use the new VME. The
> patches make the following changes:
> - Change Java build target from jsr14 to 1.5 :)
> - Change the bootclasspath system property name from
> com.ibm.oti.system.class.path to org.apache.harmony.boot.class.path
> - Create a new org.apache.harmony.luni.platform.Environment class that > contains two (currently stubbed) getenv() methods. Once these methods
> are implemented, VM writers will be able to redirect System.getenv()
> calls to this class.
> - Rename clearvm.dll/libclearvm.so to harmonyvm.dll/libharmonyvm.so, and
> update the launchers reference to this library.
> - Rename clearvm.properties to harmonyvm.properties, and update the
> Eclipse plugin to find this file.
> - Update tests.api.java.lang.reflect.ArrayTest and
> tests.api.java.lang.ThreadGroupTest to reflect changes between 1.4 and
> 5.0 behaviour.
>
>
> Once the classlib patch has been applied, you will need to download the > new VME in order to continue developing with the IBM VM. The previous
> version of the VME will no longer be compatible.
>
> I will send out a further mail when the new VME is available to download
> and use.
>
> Regards,
> Oliver
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]








--
Oliver Deakin
IBM United Kingdom Limited


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to