There are two separate issues, here: 1) Access to internal APIs. Yes, we have been warned of these for two decades; it shouldn’t actually be a shock that they have been banned. It shouldn’t, but in some cases, people didn’t really believe that they would go away. Still, it seems reasonable to say that anything marked with a deprecation warning for some time can vanish without further notice. That is the point of them, after all.
2) Reflective access to internals. This one isn’t so easy. Obviously, when you are using reflection to hack into somebody else’s code, you should expect that it could change without warning; however, this has always seemed to work, and people have come to rely on it. In many cases, it has allowed Java developers to do things that were not possible in other languages. Because it is runtime functionality, there were no equivalents of the deprecation warnings. This new proposal creates them, giving notice that we need to find alternatives. As I see it, the ideal default is compilation failures against internal APIs by default, but access with warnings of to-be-removed reflective access to internals. Command-line switches for runtime is challenging, since many Java programs are run from user-written shell scripts (the executable jar case is handled by manifest entries). Command-line switches for compilation shouldn’t be that much of a burden. Some of us have been working to remove all of our internal accesses, but twenty-years of technical debt isn’t easily cleaned up in a short time - especially when some it relies on third-party code. This proposal allows us to move forward. It makes it abundantly clear that things are changing: deprecated and internal APIs are really going away, and reflective access is going to be limited. At the same time, it allows the vast amount of legacy code out there to migrate to the new world sooner rather than later. > On May 19, 2017, at 9:39 AM, Nicolai Parlog <n...@codefx.org> wrote: > > Hi, > > I don't want to pick on Andrew in particular but his paragraph is a > great summary of the sad state of this discussion: > >> I don't think that's practical > > Interesting, waiting for a real, practical, technical reason not to do that. > >> many worried expressions > > Err, what? So something is impractical because people are worried? I'm > sure they're worried because they think it's impractical. > >> code that works on JDK 8 today will not work on JDK 9 tomorrow, >> yet no advance warning of this change was given in JDK 8 > > So twenty years of claiming internal APIs are internal and subject to > change[1] was not enough? Two years of this change being announced was > no enough? One more year of Java 8 is not enough? A simple flag to make > it work is not enough? > > so long ... Nicolai > > > [1] > http://web.archive.org/web/19980215011039/http://java.sun.com/products/jdk/faq/faq-sun-packages.html > > > > On 19.05.2017 14:54, Andrew Haley wrote: >> On 19/05/17 11:11, Peter Levart wrote: >>> On 05/19/2017 01:17 AM, Nicolai Parlog wrote: >>>> With illegal access being permitted by default much fewer developers >>>> will be aware of the problem and much less pressure will be put on >>>> library and framework maintainers as well as on project management to >>>> invest into paying back this particular form of technical debt. So we >>>> get much less momentum to make the necessary changes in exchange for... >>>> not having to add a flag? That's ridiculous, an Armutszeugnis[2] for the >>>> Java community! >>> >>> +1 >>> >>> I think that --illegal-access=permit-silently or equivalent is a >>> reasonable request (in addition to other modes), but please make the >>> --illegal-access=deny the default! >> >> I don't think that's practical because, as Mark Reinhold put it, "the >> strong encapsulation of JDK-internal APIs has, in particular, >> triggered many worried expressions of concern that code that works on >> JDK 8 today will not work on JDK 9 tomorrow, yet no advance warning of >> this change was given in JDK 8." >> >> Andrew. >> > > -- > > PGP Key: > http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 > > Web: > http://codefx.org > a blog about software development > https://www.sitepoint.com/java > high-quality Java/JVM content > http://do-foss.de > Free and Open Source Software for the City of Dortmund > > Twitter: > https://twitter.com/nipafx
