[preview] Adding java.lang.Runtime.getVMArguments() method

[Jaroslav Bachorik]

On 27.11.2015 13:21, Jaroslav Bachorik wrote:
> On 26.11.2015 12:59, Jaroslav Bachorik wrote:
>> On 26.11.2015 12:48, Jaroslav Bachorik wrote:
>>> On 25.11.2015 04:11, Mandy Chung wrote:
>>>>
>>>> > On Nov 24, 2015, at 6:24 PM, David Holmes <david.holmes at oracle.com>
>>>> wrote:
>>>> >
>>>> > On 25/11/2015 10:06 AM, Mandy Chung wrote:
>>>> >>
>>>> >>> On Nov 24, 2015, at 3:45 PM, Peter Levart <peter.levart at gmail.com>
>>>> wrote:
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> On 11/24/2015 05:49 PM, Jaroslav Bachorik wrote:
>>>> >>>> Hi,
>>>> >>>>
>>>> >>>> while working on an issue to clean up a code in java.base module
>>>> using reflection to access RuntimeMXBean (from java.management module)
>>>> in order to get hold of the VM arguments (yes, this won't work with
>>>> module boundaries in place) it was pointed out that this functionality
>>>> should be available in java.base without going through JMX.
>>>> >>>
>>>> >>> Isn't the following JDK9 API already providing that:
>>>> >>>
>>>> >>> ProcessHandle.current().info().arguments();
>>>> >>
>>>> >> This is what I also start going after.
>>>> >>
>>>> >> The launcher does some job on the command-line before passing to
>>>> the VM, e.g. @argfile support that expands the options specified in
>>>> the file, add -Djava.class.path and some system properties passing to
>>>> the VM, take out -J if they are JDK tool launchers etc.
>>>> >
>>>> > I haven't looked at the two APIs but the command-line is potentially
>>>> very different from the "VM arguments". The VM can get its arguments
>>>> from the command-line, the launcher, options file and environment
>>>> variables.
>>>>
>>>> Right - that’s what I was pointing out.  In any case, I think it would
>>>> need to think through the cases that Mark bring up.
>>> I checked ProcessHandle.Info.arguments() and it indeed extract the
>>> arguments from command line. In addition to omitting the arguments set
>>> by the channels different than the command-line there is also a risk of
>>> truncated command line - an example of the command-line reported for a
>>> jtreg test in debug mode is in the attachment. The command-line seems to
>>
>> ... ok. now the attachment ...
>>
>>> be restricted to 4096 characters on linux (PATH_MAX) so any arguments
>>> specified after this limit will be missed.
>>>
>>> In the light of this - wouldn't it make sense to use the functionality
>>> available in RuntimeMXBean.getInputArguments() to fill the arguments
>>> array reported by ProcessHandle.Info.arguments() method (instead of
>>> extending j.l.Runtime with just another method)?
>
> This doesn't seem to be a good idea. While this would work for
> ProcessHandle.current() it might be problematic for process handles for
> foreign processes. We would need to treat JVM processes differently to
> retrieve the same set of VM arguments as what is provided by
> RuntimeMXBean.getInputArguments() now.
>
> Adding j.l.Runtime.getVmArguments() method seems like the best thing we
> can do - the VM arguments are related to the current runtime and doing
> this it allows for decoupling from java.management.

Any further thoughts on this? Any objections against moving this 
functionality to j.l.Runtime since implementing this in ProcessHandle 
would lead to inconsistency between the arguments reported for 
'current()' and other processes?

Thanks,

-JB-

>
> -JB-
>
>
>>>
>>> -JB-
>>>
>>>
>>>>
>>>> Mandy
>>>>
>>>
>>
>