JEP411: Missing use-case: Monitoring / restricting libraries

[Peter Firmstone]

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.