What would help in future:
1. 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.
2. 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.
3. An annotation will let us know that we can write programs, without
risk of incurring potentially significant technical debt.
4. 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.
If OpenJDK does that, then I personally would continue use of Java for
new projects.
OpenJDK is not doing anything to ease the pain of migration, when you
could do better.
I'm curious, what are other developers using instead of Subject.doAs,
JAAS and AccessController.doPrivileged to authenticate TLS connections?
In JGDMS I found:
916 matches of AccessController in 264 files, and that's excluding tests.
515 matches of AccessControlContext in 121 files, again excluding tests.
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.
This isn't like other API's that are being removed, so far we have only
been impacted in parts of our codebase.
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?
Just can't see it happening.
--
Regards,
Peter
On 8/05/2021 8:42 am, Ron Pressler wrote:
Many of the people who worked at Sun still work at Oracle on Java today, and
that group includes all the people who
signed their names on this JEP, but Java today has ten more years of baggage to
maintain than it did back then. The
speed at which things are removed after deprecation is meant to be
proportionate to their level of use.
I believe that, despite the fact that some less used things are, indeed, being
removed now while they weren’t before,
Java still compares favourable with many other languages/platforms as far as
stability and compatibility is concerned.
I think that saying that “move fast and break things” is the new philosophy is
not only unfair, but very, very far
from the truth.
— Ron
On 7 May 2021, at 23:20, Peter Firmstone <peter.firmst...@zeus.net.au> wrote:
On 8/05/2021 4:21 am, Ron Pressler wrote:
Deprecation/removal JEPs, and this one is no exception, make the following
claim: that the total good a certain JDK capability
currently contributes to the Java ecosystem at large does not justify the cost
of its maintenance, and it should, therefore, be
removed — gradually, of course, and with enough time for users to find
alternatives. An argument against such a JEP would take
the form of, no, the total good the feature contributes to the ecosystem does
justify its cost.
Sun Microsystems would deprecate, but were very slow to remove API that caused
breakages, they were also very considerate about how they would modify api in a
backward compatible manner. OpenJDK has already demonstrated it removes api
very quickly after deprecation. OpenJDK has adopted the move quickly and break
things philosophy.
I really like the new language features under development, but the continual
breakages are causing me to rethink.
I still haven't worked out how to replace some of the more recently removed
features, we are still building on Java 8, because of missing components in
Java 11, although we use features from and test on later versions. We haven't
been testing on Java 8, because our default ciphers target the most recent
versions and we disable anything less by default.
Other breaking changes that have been removed can be replaced by library code,
but cause breakages since we are unable to use the java.* package namespace.
It would be friendlier, if OpenJDK allowed libraries to be developed
separately, using the java.* namespace, perhaps as part of the project.
This core platform feature that will be removed, probably after Java 17, but
before the following long term support version cannot be replaced by a library.
The maintenance debt is building up too fast to keep up with.
I can't justify writing new projects in Java until the API has stabilized, it's
fair to say the new API is Java like, but C# is also Java like, as is Android.
It's clear OpenJDK wants Java to be like younger languages, and since that's
where it's headed, I might as well select one of those instead, what kept me
developing on Java was its stability and performance, when newer languages
could do the same with less. Performance of newer languages will improve with
time, just like Java did and their API's will become more stable.
--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.
