commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Bentmann (JIRA)" <j...@apache.org>
Subject [jira] Commented: (EXEC-30) Make environment variables respect casing rules of platforms
Date Fri, 14 Nov 2008 11:04:44 GMT

    [ https://issues.apache.org/jira/browse/EXEC-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647581#action_12647581
] 

Benjamin Bentmann commented on EXEC-30:
---------------------------------------

Env vars are inherently platform-dependent (that's why Sun once tried to remove them from
the JRE) so any Java code that (unconditionally) relies on platform-specific details such
as case-sensitivity is by design not portable (in the context of Java, some people would call
that broken...).

So, what are the legitimate use cases for querying the env vars? Either one sticks to variables
(and their casing) that are known to work the same on all target platforms like {{PATH}} or
one really queries platform-specific vars but then properly guarded by a condition to check
for the current platform. That is to say, I currently don't see how good code would be negatively
affected by the proposed change.

> Make environment variables respect casing rules of platforms
> ------------------------------------------------------------
>
>                 Key: EXEC-30
>                 URL: https://issues.apache.org/jira/browse/EXEC-30
>             Project: Commons Exec
>          Issue Type: Improvement
>    Affects Versions: 1.0
>         Environment: Windows
>            Reporter: Benjamin Bentmann
>            Assignee: Siegfried Goeschl
>            Priority: Critical
>         Attachments: EXEC-30.patch
>
>
> Intro: Environment variables on Windows are case-insensitive (see [ExpandEnvironmentStrings|http://msdn.microsoft.com/en-us/library/ms724265(VS.85).aspx]).
As a little experiment, run the following code snippet on Windows with Java 1.5
> {code:java}
> System.out.println(System.getenv("PATH"));
> System.out.println(System.getenv("path"));
> System.out.println(System.getenv("Path"));
> System.out.println(System.getenv().get("PATH"));
> System.out.println(System.getenv().get("path"));
> System.out.println(System.getenv().get("Path"));
> {code}
> which can for example output
> {noformat}
> <successfully resolved variable>
> <successfully resolved variable>
> <successfully resolved variable>
> null
> null
> <successfully resolved variable>{noformat}
> IMHO, this is an example of how an API should *not* be designed. The two overloads of
{{System.getenv()}} look very similar but behave completely different. Even having this documented,
this subtle peculiarity makes Java programming prone to errors that prevent platform-independence.
> Commons Exec is currently providing a case-sensitive view of the Windows shell environment.
This makes it effectively impossible for client to code to reliably lookup an environment
variable without performing further tweaks to the map returned from {{EnvironmentUtil}}. Furthermore,
these tweaks would have to be performed only depending on the current OS, so the client code
would need to consider platform details. I believe this violates the basic principle of platform-independence
intended by Java.
> So here my suggestion: Have Commons Exec provide a case-preserving map that obeys the
casing rules of the platform for key lookup. This way, the simple code line
> {code:java}
> EnvironmentUtils.getProcEnvironment().get("PATH")
> {code}
> will consistently return the specified variable on Windows and Unix.
> Just to mention it: An alternative approach might be to have the map always be case-sensitive
but normalize variable names to upper-case on case-insensitive platforms.
> Regardless how this issue ends, the documentation for {{getProcEnvironment()}} should
clearly state how it deals with casing.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message