SecurityManager environments

[Alan Bateman]

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