[External] : RE: JEP 411, removal of finalizers, a path forward.

[Ron Pressler]

Hi.

JEP 411 says that there is a feature whose value in fulfilling its purpose no
longer justifies its high cost, and so it should be removed. What you’re saying
is, that’s true, but you should keep it, anyway. Why? Because it can be put to
some other, more modest, accidental uses. 

Now, the "disaster" of removing any feature is directly felt by those who use
it, but the "disaster" of *not* removing it is less visible, even though it may
be the bigger disaster, as we believe is the case here. Sure, we must consider
those applications that use it and how they use it, but we must also consider
all those that do not. By not acknowledging those who lose from keeping that
mechanism, you're not appreciating the problem that the JEP tries to address.
For example, you say you care about non-security uses of SM, but maintaining it
comes at the cost of other security measures, and we believe that removing it
would improve Java's security overall.

While some of the features you say you want could well be addressed by cheaper
mechanisms that could reasonably be added, it's possible that some cannot
(or not fully). Thankfully, the JDK is flexible and hackable enough — through
things like Java Agents — that the cost of some capabilities could be borne by
those who need them.

It's perfectly reasonable to explain what functionality would be helpful to you.
It is not reasonable to demand keeping some functionality regardless of its
cost. The reality is that to adapt to changing circumstances, the JDK must both
add new capabilities as well as drop old ones, or its complexity, and, with it,
its maintenance cost would grow without bound. Of course, any help in finding
the right balance of cost and benefit in consideration of the needs of
the *entire* ecosystem would be appreciated.

P.S.

Loom has nothing to do with JEP 411. I might have mentioned it when pointing out
that virtually all relevant Java features developed in the past decade -- like
parallel streams, CompletableFuture, and Loom -- have chosen not to integrate
with SM.

— Ron

> On 1 Aug 2021, at 15:28, Uwe Schindler <uschindler at apache.org> wrote:
> 
> Hi Andrew,
> 
>>> I'm working on the assumption that OpenJDK will close any external holes
>>> currently defended by permission checks.  It would be good if the JDK
>>> was secure by default, with properties required to be set for allowing
>>> such things as agents, management, parsing xml and serialization.
>> 
>> You need to stop repeating this canard. There is no absolute need for
>> OpenJDK to retain a security mechanism to deal with problems that for
>> almost every use case are better solved by using non-OpenJDK
>> alternatives (such as OS security measures). Indeed, it's the other way
>> round: there is an imperative for the project to spend precious
>> resources on alternative capabilities (not necessarily security related).
> 
> Sorry, as another open source project affected by the stupid JEP 411 desaster I would like to fully confirm to EVERYTHING that Peter said. It is not a canard, it is the reality and I am really disappointed what happened.
> 
> What I figured out: You intend to remove SecurityManager because it does not fit your latest ideas how Java threads should behave. I know the main problem is not "SecurityManager is too complex / too slow / wrongly used /..." -- the main problem of some OpenJDK people around the Loom project is that it won't work correctly with those new type of threads. You are now always arguing against use cases of SecurityManager for the purpose of secuirty because you just want to hide that the new "light" threads (aka fibers) in project Loom are incompatible to the stack-based access control provided by AccessController and SecurityManager. So the only canard is Project Loom - sorry!
> 
> So I will do the same: repeat the same story like Peter's over an over. Two large projects affected by your changes are Apache Solr and Elasticsearch. Both use security manager not only for security purposes, but also to control access to resources and classloading! Speed is also no issue if you use security manager correctly. In Apache Lucene/Solr/Elasticsearch there is NO slowdown visible as the hooks into security manager are only called for uncritical places (like opening a file before mmapping it, open a listening socket, loading a class...).
> 
> The problem is: you deprecate for removal without offering any API to replace the main pain points:
> - preventing exit of JDK
> - an API to control class loading and prevent code from calling Method/Field/Constructor#setAccessible(true) for specific cases (e.g., you want a scripting language like Groovy to not allow caling sun.misc.Unsafe,...). Those things can never be done with code outside of the JVM!
> - Allow to hook into the I/O system. Unfortunately the java.nio FileSystem API is not enough: it does not cover java.io.File (why is this the case?) nor does the FileSystem API allows to hook in everywhere. We figured out that for example the new Panama interface to get a MemorySegment from a file path is not calling any API in the Filesystem abstraction!
> - Disable damn java serialization completely
> 
>> The fact that your software can no longer profit from this specific
>> mechanism is a /special case/ which means any loss incurred is a
>> /special loss/ not a general one. Users who rely on your software for
>> the security guarantees you claim it provides may well no longer be able
>> to do so once this mechanism is removed. However, claiming that this
>> implies Java is no longer secure by default is a /gross/
>> misrepresentation of what is at stake.
> 
> The name "SecurityManager" is a legacy name. In fact "AccessController" and "Policy" is much better and exactly suits our needs and what we expect from it. We don't want security, we want access control and corresponding policies. That 2 different things!
> 
>> Java can be used perfectly well to implement secure applications without
>> the security manager. That's evidenced by two facts: on the one hand
>> experience has shown that most programs that rely on the security
>> manager are not actually more secure because of using it; on the other
>> hand there are many highly secure Java programs out there in the field.
> 
> That might be true, but the current state does not allow this for all use cases. Most projects use Security Manager not for security. Look at the code out there!
> 
>> The fact that your software will no longer provide a specific route to
>> implementing a certain type of security capability may be a great loss
>> to you but it is not a significant loss, never mind some absolute loss
>> in kind, to Java and Java application developers. I recommend you stop
>> repeating this distorted opinion. It's only effect will be squander the
>> goodwill of those currently trying to help you, people whose driving
>> interest is nothing other than to make OpenJDK a better product.
> 
> It is a great loss for many people, not only Peter. In Apache Lucene, Solr and Elastisearch, usage of SecurityManager will stay alive as long as possible (possible till Java version 27 or later). If it won't work anymore without a replacement to address the above painpoints
> 
> Please revert the deprecation of SecurityManager and possibly delay the release of Java 17. In Java 18 work on new APIs like proposed in the JEP and then in Java 19 you can do a second try to deprecate/remove SecurityManager. Deprecating something without a proper replacement for the pain point is a bad idea. We have seen this in Java 9 already: Suddenly the module system was weakened shortly before release: because there was no replacement for sun.misc.Unsafe.
> 
> Kind regards,
> Uwe
>