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
