Review request #1: 6863566 (Java should support the freedesktop.org startup notification specification)

Damjan Jovanovic damjan.jov at gmail.com
Thu Oct 15 18:04:30 UTC 2009


The environment variable:
* Must not be inherited by child processes
* Ideally, should not be seen by Java apps

AFAIK Java has no API to unset environment variables.

Even if it did, it would be too late for an AWT window to unset it,
because child processes can be launched sooner and would still inherit
the environment variable.

My previous solution
(http://bugs.openjdk.java.net/attachment.cgi?id=119) was to modify the
*nix launcher so it moves the variable into a java.lang.System
property early during Java startup, but then people were unhappy about
modifying the launcher
(http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-July/002216.html
and replies).

So what's left? What solution would be acceptable? Please suggest something.

Thank you
Damjan

On Thu, Oct 15, 2009 at 5:10 PM, Michael McMahon
<Michael.McMahon at sun.com> wrote:
> It doesn't seem right to filter out arbitrary environment variables
> like that (inside ProcessEnvironment). Sorry, I haven't been following this
> issue closely,
> but is it not possible to unset this variable somewhere else?
>
> - Michael.
>
> Alan Bateman wrote:
>>
>> Martin, Michael - have either of you looked at the filtering that they are
>> proposing to add to ProcessEnvironment?
>>
>>
>> Anthony Petrov wrote:
>>>
>>> Hello,
>>>
>>> Please review the next version of the fix contributed by Damjan
>>> Jovanovic:
>>>
>>> RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094
>>> There you can also find some latest comments regarding the fix.
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.1/
>>>
>>> Since the patch includes changes to the
>>> src/solaris/classes/java/lang/ProcessEnvironment.java, I'm
>>> CC'ing the Core Libs alias to review the changes in that file.
>>>
>>>
>>> From AWT perspective, the changes look good to me.
>>>
>>> --
>>> best regards,
>>> Anthony
>>
>
>



More information about the core-libs-dev mailing list