Feature complete?

Wed Dec 9 08:24:32 UTC 2015

Alan Bateman wrote:
> 
> 
> On 04/12/2015 13:50, Reinier Zwitserloot wrote:
>> :
>>
>> 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.
> The context for this discussion, as least my understanding, is that we 
> were talking existing code where you are trying to run it in the same 
> way as you did in JDK 8. If that code is using JDK-internal APIs then 
> the command-line option is the only workaround proposed to keep that 
> code working.
> 
> I agree that setting the command-line is a challenge in many 
> environments, esp. when it is buried in XML files or scripts. You may be 
> right that it is beyond some developers too.  We've tried to make error 
> and exceptions as clear as possible so that it's not too difficult to 
> figure out what is going on.
> 
Setting addExports via the command line is very problematical for my
application.  This application needs to run on 7 different platforms
with both graphical and console interfaces.  Each platform has different
packaging requirements and launch arrangements.  In at least one case,
(launching via the .jar file association on Windows), it isn't possible
to add command-line JVM options.  For each platform, the same installable
application package needs to run on Java 7, Java 8 and Java 9 with no
impact to the user when he/she upgrades to Java 9 from Java 7 or Java 8.
Adding the necessary -XaddExports options to the command line for Java 9
for all platforms while satisfying the above constraints is very
challenging and would be a large amount of work.  If some other way of
setting these options could be provided (for example, via the manifest
in the main JAR file or by an API call from the application), this would
greatly simplify the migration of my application to Java 9.
  Simon
>>
>> 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.
> The current design and prototype provides support for migration to 
> modules without waiting for the rest of the world to migrate. We're 
> going to need more experience, help, feedback to make sure that this is 
> useful.
> 
> The main challenge is of course is the tension between frameworks and 
> strong encapsulation. Existing frameworks don't know about modules and 
> so it will be important for willing maintainers of at least some 
> important frameworks to work with us to get to the right solution. Maybe 
> then we can start switching to the other side of the road, a gradual 
> migrating, starting with the big trucks :-)
> 
> -Alan
>