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

[Jaroslav Bachorik]

On 7.12.2015 12:20, David Holmes wrote:
> 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?
The same as http://docs.oracle.com/javase/8/docs/api/java/lang/management/RuntimeMXBean.html#getInputArguments--
Basically, this is about moving the RuntimeMXBean.getInputArguments() to a place which would not require dependency on java.management in order to get the VM input arguments.


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