Whatever version JEP 411 targets, it will *not* remove the Security Manager. Even if 411 targets 17, the Security Manager will still be in 17, precisely because of the deprecation policy intended to give people time to adjust.
— Ron > On 13 May 2021, at 01:44, Peter Firmstone <peter.firmst...@zeus.net.au> wrote: > > Ron, > > Can JEP 411 be targeted against Java 18 please? > > I realize long term support is not OpenJDK's concern, however other's are > planning Java 17 to be a long term support release and that will impact us. > > Thank you, > > Peter Firmstone > Zeus Project Services Pty Ltd. > > On 13/05/2021 7:43 am, Ron Pressler wrote: >> >>> On 8 May 2021, at 05:55, Peter Firmstone <peter.firmst...@zeus.net.au> >>> wrote: >>> >>> What would help in future: >>> >>> • Define a core Java api, a javadoc annotation? If parts of it are >>> deprecated, they will not be removed for eg 3 LTS releases, pick a number, >>> it provides certainty. Developers writing new software then know if they >>> use this api, they will not be harmed by breaking changes for x years. >>> • Removal of api from java.* or javax.* are breaking changes. This is >>> worse than a library breakage, as we can write a compatibility layer for a >>> library. In my own software I provide a compatibility library for older >>> versions of software written for Jini, it just decorates old api over new >>> as a compatibility layer. For example we could write a compatibility >>> layer for AccessController and doPrivileged methods, so they still work, >>> without shotgun surgery. but we can't do that because it's in Java package >>> namespace. >>> • An annotation will let us know that we can write programs, without >>> risk of incurring potentially significant technical debt. >> OpenJDK does not have the concept of LTS, and certainly not of "LTS >> releases.” >> Long-term support is a general term for services that anyone is free to >> offer for any OpenJDK version for >> any length of time, and even retroactively. You can choose to provide LTS to >> JDK 10 tomorrow if you like. >> >> OpenJDK does have a removal policy: https://openjdk.java.net/jeps/277. Its >> goal is to do exactly what >> you describe, and that policy is in effect for this JEP as it is for all >> other similar ones. >> >> But please read JEP 411 carefully. It does give you time; it does talk of a >> gradual process. >> >> >> >>> • Sun always gave us plenty of time to remove usages of deprecated >>> methods, it always took years to clean these up, but there are compiler >>> warnings etc. My point is, we always got them removed eventually, >>> meanwhile we were also able to take advantage of new features. >> This is the second time you’ve brought up Sun, as if it’s some disjoint >> group of people. People might >> have decided to change their policies due to changing circumstances, and the >> circumstances 15 years >> ago were certainly no identical to today. >> >> >>> It appears to me that stack walking, which you singled out as a performance >>> problem (it isn't), is likely causing difficulties for another project >>> you're working on, which is why you are strongly motivated to see it >>> removed. >> We would like to see it removed because we believe that the total good the >> Security Manager does the >> Java community as a whole does not appear to justify its high cost. In other >> words, we’d like to see it >> removed because we believe doing so would do more good for more people than >> not removing it. >> >>> This will inflict pain on many projects, I just can't see people upgrading >>> their software. Who's going to pay for all the hours of programming to >>> convert perfectly good running code to a new api, just to upgrade to a >>> newer version of Java? >> Removing stuff absolutely causes pain. We know that, we sympathise, and >> we’re trying to minimise it. >> But you have to understand that *not* removing stuff also causes pain, and >> not diverting resources >> elsewhere might dissuade other people from using Java because *their* needs >> aren’t addressed. We would >> have loved to please everyone but it’s impossible, so we have to make >> decisions, and whatever decision >> we make, someone will experience pain in the form of more work they have to >> do. We have to consider the >> total pain vs. total good over the entire Java ecosystem. Please also >> understand our perspective: you’re >> asking us to pay for hours of work to maintain something that few use, hours >> that could go into work more >> people could enjoy. >> >> — Ron >
