stephen.felts at oracle.com
Fri Dec 4 16:07:40 UTC 2015
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.
From: Reinier Zwitserloot [mailto:reinier at zwitserloot.com]
Sent: Friday, December 04, 2015 8:50 AM
Subject: Re: Feature complete?
On Tue, Dec 1, 2015 at 2:24 PM, Alan Bateman <Alan.Bateman at oracle.com>
> 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.
> *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.
More information about the jigsaw-dev