ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gintautas Grigelionis <>
Subject Re: Impact of Java SecurityManager being deprecated for removal post Java 17
Date Thu, 05 Aug 2021 14:29:55 GMT

The most acute problem is this: SecurityManager seems to be involved in
handling of return code from forked processes.
How does JDK 17+ solve that?

Regarding the permissions type: if the sandbox is gone in JDK, then
permissions should go, too.
For the reference, a summary of permissions classes is provided by Oracle
A summary of guidance re JEP 411 is available here [2].
Some ideas on the way forward are presented here [3].



On Thu, 5 Aug 2021 at 15:54, Jaikiran Pai <> wrote:

> Hello everyone,
> Some of you might have been following the recent discussions in JDK
> where the SecurityManager and related APIs will be deprecated (for
> removal) starting the upcoming Java 17 release. To be clear, this change
> in Java will have no impact in terms of API usage in Java 17 (except for
> warnings being logged). However, after Java 17, these APIs may not
> exist. The whole JEP is available at
> Ant project will be impacted by this. Ant provides a "permissions"
> type[1] whose whole goal is to integrate with the Java SecurityManager
> to allow users to configure the necessary security permissions. With the
> SecurityManager and the APIs potentially gone after Java 17, we can no
> longer support this. One additional point to note here is that, Ant also
> uses the SecurityManager APIs even when "permissions" type is not
> involved, at least in the "java" task and the "junit" task, where we
> setup a SecurityManager with very minimal permissions.
> When a EA release of Java 17 was tested against the Ant project, it
> exposed issues around the amount of warning messages that were being
> logged by the new Java release for basic Ant builds. The JDK team took
> that input and fixed that part. Discussion about that can be seen in
> this thread[2].
> At this stage, the dust seems to have settled about the plans around
> SecurityManager in the JDK and it's clear that it will be gone post Java
> 17. We (the Ant project) will have to decide and come up with a way
> where we (the Ant project) will no longer support "permissions" or use
> SecurityManager APIs post Java 17. I personally haven't been involved in
> the original SecurityManager integration in Ant and don't have enough
> background knowledge about this part in Ant nor do I know how many of
> our users use the "permissions" type or rely on SecurityManager (I was
> in fact unaware we even had a "permissions" type, until I decided to dig
> around our code recently to see if/how we will be impacted by
> SecurityManager API changes). Given this, I would like to have some
> discussion on how we should proceed with this.
> [1]
> [2]
> -Jaikiran
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message