JEP411: Missing use-case: Monitoring / restricting libraries

[Ron Pressler]

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.

But that is not the argument you are making. Instead, you are proposing a rethinking of the Security Manager. This is similar,
and, I would say, identical, to proposing a new Project, which is judged by its *expected* merit vs. its expected cost. But
that is a very different discussion. Obviously, arguing in favour of a new Project to redesign and re-market a feature that
has been tried for over two decades and has failed to yield the expected good in recent years (possibly due to changing 
circumstances) would require a very compelling argument, and might be a tough sell, but in any event, this is not what is being 
discussed in this particular context. I could agree with some, most, or even all of your points, and yet I don’t think they
are relevant to the central claim made by JEP 411.

I also sense, from things you’ve said and also from reading between the lines, that you might be interpreting certain legal
limitations in a manner that might be stricter than required. I am not qualified to give any legal advice and I would not
attempt to do so, but I would like to point out that the JDK classes are distributed under a well-known open-source
license with well-known terms, and the question of their use is separate from the question of introducing *new* classes that
make use of certain trademarked names. I don't know where you can obtain advice on such matters.

— Ron

> On 7 May 2021, at 11:17, Peter Firmstone <peter.firmstone at zeus.net.au> wrote:
> 
> 
> On 6/05/2021 9:46 pm, Ron Pressler wrote:
>> 
>> Trying to convince people, at this point, after twenty five years that the Security Manager isn’t complicated after all might
>> be too little too late.
> 
> 
> Static policy, terrible performance, no scalability at all, and the fact that you continually have to edit policy files manually, and there's no auditing tools?
> 
> Ha ha ha. :)  It's complicated, ha ha ha, it hardly works!  Why would a developer spend time writing concurrent code, then turn on security and slow their hard work to a crawl?  That's why they simplify it and bypass the policy.
> 
> No, complexity is not the problem.
> 
> It was a good design for 1997, but the java code it's written in is also from 1997 with little maintenance since.
> 
> For shame.
> 
> From my observations, the native code in AccessController is scalable and performant and has little overhead, someone has done some very good work there, that has to be more recent.   This is a very good piece of work, very good indeed.
> 
> Sorry, I had to point out some truths.
> 
> My static policy (as stated previously there is a dynamic policy also) is a direct drop in replacement, you could ship with that, it would be a start.  You could even remove the Java policy implementation and I can make my policy implementation available on Maven.  It's AL2.0 licensed, I did look at donating it some time ago.   The code has provenance, I'm not the sole author, I can only donate parts of it under GPL2.0
> 
> I can also donate the profiling tool.
> 
> The thing is, if it was performant, people would stop switching it off, and if there were tools to handle policy complexity, then they will start using it, they have to use it for Principal permissions.
> 
> Here's what OSGi does, they associate permissions with modules, to reduce complexity:
> 
> https://urldefense.com/v3/__https://docs.osgi.org/specification/osgi.core/8.0.0/service.condpermadmin.html__;!!GqivPVa7Brio!MA0LQDajtSBzAF17g-T_xjcu0qI1jv040zIzdYPlJ2ZRrM9RxvFl4ZxZc8leWZNQYw$ 
> -- 
> Regards,
> Peter Firmstone
> Zeus Project Services Pty Ltd.
>