On 16/05/2017 19:11, Gregg Wonderly wrote:
At some level, this is the problem that is paramount on the release of JDK-9.
Earlier Mark asked if the Eclipse foundation had to approve or be ready to
support all of what JDK-9/Jigsaw supports before it could be released.
The statement below seems to stipulate that “all Java software must be
convertible to what JDK-9 is demanding” or it’s no longer going to be usable
with JDK-9 and later. That is not a backward compatible premise for evolution
of Java. So ultimately, what is being demanded, is that the entire world of
Java should be continuously reading this group, responding to releases, and
making sure that their software systems are compatible so that all users of all
exist Java applications will be ready to be replaced by working version once
JDK-9 is released. The question of is JDK-9 compatible software also able to
run on JDK-8 as well as the fact that JDK-8 compatible software may largely be
unable to run on JDK-9 is still something that seems to get shrugs of
indifference from the Jigsaw team.
Evolving Java to have better modularity is a great idea. But somehow we still have
statements about “Jigsaw modularity includes isolationist based security, deal with
it" is still the primary concept around most replies to questions on the list
about how moving forward with existing applications/libraries and standard
development practices.
It seems strange, that with such a wide sweeping change to how Java works, that
the JigSaw team still seems amazingly confused/frustrated that people are
troubled by all the extra work that they will have to do, to somehow untangle
their software systems from other software systems which Jigsaw has seem to put
on the hook for using the features of Java prior to JDK-8.
If we really cannot actually keep from breaking 90% of existing Java in the
market place when this new JDK release goes out, how valuable is JigSaw really?
How much community focus does this suggest there is in the design and
implementation? How many people/teams/companies are going to look at this as
some form of decline of what Java, write once, run anywhere, actually means to
them and their development team?
I still come back around to the SecurityManager being a much better focus point
for denial of access. It is just really odd that because you want to do this
at the JRE implementation level, and want to do control access for all software
which has the same declarative exposure, that we all have no choice at all, for
how we will be exposed to the problems that will be created when auto updates
install JDK-9 over the top of JDK-8.
This thread is not about strong encapsulation. It's also not a thread
about a JDK 9 compatibility issue. It is instead about optional
migration to modules where you address technical debt and refactor to
use services as part of making your code modular.
-Alan.
