On 05/04/2017 21:23, Gregg Wonderly wrote:
Desktop applications started from a double clicked jar file, have no explicit
access to the command line. It just doesn’t exist for that application. It
only exists for “all” applications (launched for mime-type mapped application
mappings) in most cases (linux/unix shortcuts can be constructed to specify
arguments more readily, but still require expertise to do that).
The Add-Exports and Add-Opens attributes are the executable JAR
equivalent of the --add-exports and --add-opens command line options. So
if an application is hacking into say sun.awt then the maintainer of the
application can shield the users of the application until those issues
are fixed. These JAR file attributes are ignored when running on JDK 8.
There are equivalents for JNLP applications that have been discussed on
other threads here. So more support keeping bad code working until the
owners of that code fix the issues.
I think part of your mail is concerned with the scenario of users using
the JRE and getting automatic updates. If they are updated to JRE 9 but
are using a much older version of an application with bad code then they
will have problems. The responsibility has to lie with the maintainers
of the application (and whoever else is in the middle) to make sure that
the users get a new version of the application in advance. This is no
different to an upgrade from JRE 7 to JRE 8. That is, if there is code
hacking into sun.awt (and I'm just using that as an example as there
weren't any specific example in your mail) then it's going to be fragile
anyway. Maybe the AWT code has been refactored so the private field that
is being hacked no longer exists or has been renamed.
FWIW, I see that users using Oracle's JRE with auto update enabled had
the option to upgrade to JRE 8 from Jan 2015. JDK 8 shipped in March
2014 so there was a 9 month lag. I have no knowledge on when JRE 9 might
be offered to end users using auto update.
:
People have multiple Java applications in use, and probably a sizable number of
those are not going to be broken. But, the Spring libraries seem to have
become quite prevalent in lots of places and that, for me, is going to be the
stick in the mud that just keeps on getting stuck.
The Spring maintainers come across as smart cookies, I'm sure they will
release versions in a timely manner that address the technical debt and
work on JDK 9 without needing command line options.
-Alan
