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

[David Holmes]

On 7/12/2015 6:46 PM, Jaroslav Bachorik wrote:
> 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?

I was left unclear as to the exact intent of the API - which "arguments" 
does it provide? Commandline? launcher? VM?

Thanks,
David

> Thanks,
>
> -JB-
>
>>
>> -JB-
>>
>>
>>>>
>>>> -JB-
>>>>
>>>>
>>>>>
>>>>> Mandy
>>>>>
>>>>
>>>
>>
>