I have come to a similar concern about command line options.

First, it won't be acceptable for customers to change their scripts that say 
'java myjavacommand'.
The best that I have come up with so far is to hide JDK9 command line options 
in _JAVA_OPTIONS (it's likely that things will still need to work with JDK8).  
One problem with that approach is that all of the commands use this single 
environment variable (there's not a _JAVA_OPTIONS and _JAVAC_OPTIONS).  There 
is a problem with javac/jimage complaining about options that only work with 
java.  Let's ignore that for a minute.

In my project, I have two module path modules, two upgrade path modules, 13 
export packages, and almost 900 classes in the XPatch directory.  I can't 
expect to tell customers how to handle all of that so the best that I can do is 
generate an argument file on installation (with full pathnames burned in since 
environment variables don't work) and tell them to put the 
@/full-pathname-to-argumentfile into _JAVA_OPTIONS everywhere in their 
environment.

Let's assume I buy into that and it's fine for my project.  It's quite likely 
that my project will have "3rd party" projects and they might have decided to 
do the same thing, assuming they have done the JDK9 migration.

Now my customer will need to manage putting all of this stuff into 
_JAVA_OPTIONS.  That's a pain and it's not clear that the modules, exports, and 
patches from other projects won't interfere with mine.
So we have moved from difficulties managing jars to command line option 
difficulties.


-----Original Message-----
From: Reinier Zwitserloot [mailto:rein...@zwitserloot.com] 
Sent: Friday, December 04, 2015 8:50 AM
To: jigsaw-dev
Subject: Re: Feature complete?

On Tue, Dec 1, 2015 at 2:24 PM, Alan Bateman <alan.bate...@oracle.com>
wrote:

> This seems a bit pessimistic. One thing that would be helpful is to 
> get more help testing of these libraries with the EA builds. If there 
> are libraries and applications on the class path today that are using 
> core reflection then they should continue to work as they do in JDK 8. 
> The
> *only* issue *starting out* should be where core reflection is being 
> used to get at JDK internal types, in which case a command-line option 
> might be needed to keep those deployments working.


Emphasis mine: "only"?

"Just add some command line switches" is not exactly a nice solution. From 
personal experience, the vast majority of java users do not know how to add 
configure command line switches to the various compile and build VMs being 
started by their build tools of choice, for example. Also, not something Alan 
mentioned here: Adding the command line switches is currently the _ONLY_ 
solution, so tools that are aware of the issue can't even fix it, other than by 
mangling modules (bad idea, I think we all agree on that I assume), or advising 
the userbase not to actually USE any of the modularity features and, 
preferably, to avoid switching to JDK9 altogether.

Emphasis mine: "starting out"?

This gets back to an earlier issue I raised on this mailing list: Okay, 
starting out this isn't an issue, but by having no way to opt out of 
export-based access control, it's a bit like switching from driving on the left 
side of the road to the right: Unless the entire greater java community 
switches in the same instant, we're all going to have a bad time.
A way to opt out needs to exist, and the fact that the discussion is still 
going, and no plans have even been stated yet, means in my opinion that jigsaw 
is not fully baked yet.

 --Reinier Zwitserloot

Reply via email to