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. Gregg > On May 16, 2017, at 5:39 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 12/05/2017 14:31, David M. Lloyd wrote: > >> : >> >>> #4 seems to be working around the outcome of issue #CyclicDependences in >>> the JSR. I also don't wish to comment on that except to say that >>> introducing system properties to skip specified checks is highly >>> problematic from a conformance perspective. >> >> Can you explain what you mean by that? I'm more than happy to convert these >> into -X type arguments to the runtime (or, of course, to simply make this >> the standard behavior), but I thought this would be a simpler and safer >> approach (at least for a first pass). >> > Disabling specified behavior creates a conformance issue. It doesn't matter > if it's a CLI option or a system property. > > In any case, proposing a patch here is not the right way to re-open JSR issue > #CyclicDependences. Instead, I think it would be better to work through a > number of migration scenarios and see what real-issues you run into. Do you > run into cycles that can't be addressed with clean-up and migrating to > services for examples? > > -Alan.
