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.
