JEP411: Missing use-case: Monitoring / restricting libraries

[Peter Firmstone]

So it targets 17.

Java 8 has planned support to 2030, longer than 17, it seems unlikely 
the SecurityManager will still be present in an LTS release later than 
17, given that 11 was the last, maybe 23 will be the next LTS version.  
Of course these aren't OpenJDK considerations, maybe someone will decide 
to support a version of Java that has it longer, or maybe they wont.

It would be nice to have certainty about which release it will be 
removed from, for planning purposes.   Again it would seem that this 
isn't a consideration of OpenJDK.

Is there an OpenJDK community project group that maintains older Java 
versions I can join?

Regards,

Peter.


On 13/05/2021 6:21 pm, Ron Pressler wrote:
> Whatever version JEP 411 targets, it will *not* remove the Security Manager. Even
> if 411 targets 17, the Security Manager will still be in 17, precisely because
> of the deprecation policy intended to give people time to adjust.
>
> — Ron
>
>
>> On 13 May 2021, at 01:44, Peter Firmstone <peter.firmstone at zeus.net.au> wrote:
>>
>> Ron,
>>
>> Can JEP 411 be targeted against Java 18 please?
>>
>> I realize long term support is not OpenJDK's concern, however other's are planning Java 17 to be a long term support release and that will impact us.
>>
>> Thank you,
>>
>> Peter Firmstone
>> Zeus Project Services Pty Ltd.
>>
>> On 13/05/2021 7:43 am, Ron Pressler wrote:
>>>> On 8 May 2021, at 05:55, Peter Firmstone <peter.firmstone at 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

-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.