Hello ewh,
Thank you for these experiments and reporting the results. This
certainly helped me decide which way to go about it. When I had
initially tried using "allow" as a Java class (as done in NetBeans), I
was unsure if that would be the right way to go. It didn't feel clean
and I thought maybe updating the launcher scripts would be easier and
cleaner. Having experimented with the scripts and having seen how
complex it got (and how it required different ways for different OS) and
now having heard the results of your experiment, I believe this is the
better approach to take. So I've reverted all the changes to our
launcher scripts that I had done to first detect Java runtime version
and then conditionally set the java.security.manager property and
instead introduced this "allow" class and unconditionally set
-Djava.security.manager=allow in the launcher scripts.
Jan, thank you for pointing me to the "allow" class used in NetBeans. I
copied over that code and have done some minor changes to it.
The entire commit of this change is available here
https://github.com/apache/ant/commit/82c70f3202d5aec4d99fa3b6314ba4a6c338cd94
My tests over the weekend with these changes have shown that it works
fine across the various JDK versions I tested (8, 11, 17, 19 and latest
20 EA). So this looks good.
My plan is to release Ant in this coming week, now that this work is
done. I will wait a day or two for others in the team to catch up with
this change and see if there are any additional suggestions or issues
they notice.
-Jaikiran
On 18/11/22 5:07 am, Earl Hood wrote:
Figured give an update wrt our project: The method used by Netbeans project
as cited by Jan appears to work.
I have not done full testing wrt to Ant as it appears the use of the
SecurityManager in Ant is limited in scope to invoking another Java class
in the same JVM, which we do not seem to do (nornally enable forking).
Regardless, since Ant is included with our product, I implemented the
Netbeans approach so we can set java.security.manager=allow unconditionally
regardless of JRE version.
Since I wanted to avoid creating a custom version of ant, for the one case
we invoke the 'ant' command and not org.apache.tools.ant.launch.Launcher
directly, I set the LOCALCLASSPATH env to point to a jar containing
allow.class, and set ANT_OPTS=-Djava.security.manager=allow
For the embedded scenarios, I updated our invocation scripts to set the
sysprop when JVM is invoked and ensure allow.class is in classpath.
For Ant itself, I think if the "allow" class is included in
ant-launcher.jar, the command scripts can be updated to always set the
system property, avoiding the need to invoke java twice: first time to get
version and second time to actually do the job.
--ewh
On Tue, Feb 8, 2022, 12:35 AM Jan Lahoda <lah...@gmail.com> wrote:
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.
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
