JEP411: Missing use-case: Monitoring / restricting libraries

[Ron Pressler]

> On 8 May 2021, at 05:55, Peter Firmstone <peter.firmstone at 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