Hello Jan,
On 08/02/22 12:04 pm, Jan Lahoda wrote:
On Tue, Feb 8, 2022 at 5:53 AM Jaikiran Pai <jaiki...@apache.org> wrote:
Hello Earl,
On 08/02/22 12:59 am, Earl Hood wrote:
How exactly does setting the sysprop for only 18 and 19 allow folks to
test
their stuff? If Ant currently depends on the security manager to
operate,
why not set the sysprop regardless, then remove in future when a
replacement API exists?
Java 18 and 19 now throw a runtime exception by default when
System.setSecurityManager is called at runtime. This behaviour can be
changed to prevent the exception being thrown and let it behave like
older versions, by setting the Java system property
java.security.manager=allow. We (Ant) cannot set it by default to all
versions of Java because this "allow" value was only introduced in Java
12
https://www.oracle.com/java/technologies/javase/12-relnote-issues.html#JDK-8191053.
Ant 1.10.x supports using earlier versions than Java 12 (like Java 8),
so we (Ant) cannot blindly set that value without these Java version
checks.
FWIW, NetBeans added a SecurityManager called "allow", that uninstalls
itself as soon as possible:
https://github.com/apache/netbeans/blob/master/platform/o.n.bootstrap/src/allow.java
Then -Djava.security.manager=allow works on the platforms supported by
NetBeans - before JDK 12, "allow" is installed and quickly uninstalled, but
setting another SecurityManager is allowed.
That's an interesting trick. So it relies on the fact that this system
property considers the value as a fully qualified class name if the
value isn't some well known set of strings. So in older versions where
"allow" isn't recognized as a well known string it then gets considered
a fully qualified class name which extends the SecurityManager class. In
versions where "allow" is known, it then allows us to set the security
manager at runtime. Interesting trick - this whole security manager
workarounds to have it functional for a few more releases reminds me of
tricky coding challenges/puzzles that are typically thrown at us in our
college days :)
The one thing I need to check about this trick is - when we launch Ant
through our launch scripts, which all jars form the classpath and
whether there's any chance of any rogue/duplicate "allow.class" to be
part of this classpath which then gets picked up instead of the one in
Ant jars.
I will give this a bit more thought along with some of the other
suggestions in this thread and experiment a bit to see which path to
follow. Thank you for pointing to that commit.
-Jaikiran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
