JEP411: Missing use-case: Monitoring / restricting libraries

[Peter Firmstone]

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.firmstone at 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.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210508/f33ccffd/attachment.htm>