Review Request JDK-8136930 Examine implications for custom launchers, equivalent of java -X options in particular

[Daniel D. Daugherty]

On 6/10/16 1:08 PM, Robert Gibson wrote:
> On 10 Jun 2016, at 18:38, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>> On 6/10/16 8:52 AM, Alan Bateman wrote:
>>> On 10/06/2016 15:00, Coleen Phillimore wrote:
>>>
>>>> :
>>>>
>>>> The difference between these module options and the other non-conforming options is that the others actually do something in the JVM.  The module options only set properties for the JDK.   So we have code in the JVM that only affects the JDK. This breaks encapsulation between the two code bases and is traditionally not what you want to do in significant code bases like Hotspot and jdk.
>>>>
>>>> This is mostly the reason that I object to these options.  They are in the wrong place.  They do not affect processing in the JVM so should not be parsed there.  There are other known mechanisms for communicating with the jdk that should be followed, passing -D options directly or using the launcher.
>>> Some of these options configure the modules that are observables, others augment the readability graph or exports. So they are very significant to the runtime/VM. It was an implementation choice (and I think the right one) to keep most of the implementation out of libjvm.
>>>
>>> As regards using system properties then this is exactly what we are trying to move away from.
>>>
>>> The complexity that is the space in `-addmods` and `-limitmods` is indeed an issue.
>> I just re-read this...
>>
>> A space in the VM option? As in '-addmods<space><mod_name>'? That's a
>> completely new idea for VM options processing and one that we took
>> great pains to avoid when '-agentlib' and '-agentpath' were added
>> back in the JDK1.5 timeframe.
>>
>> Alan, surely you remember this from the early JSR-163 and JVM/TI days...
>>
>> Dan
> Hi,
> See also, for example,
> https://bugs.openjdk.java.net/browse/JDK-8159136
>
> (NPE on current JDKs on WebStart launch with VM args “-addmods java.se.ee”)

That bug is for the JDK8u train. Why is an '-addmods java.se.ee' option
being passed to JDK8u? Or is JDK8u somehow launching a JDK9 instance?

Dan


>
> Thanks,
> Robert