Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19
Hello Jan, On 08/02/22 12:04 pm, Jan Lahoda wrote: On Tue, Feb 8, 2022 at 5:53 AM Jaikiran Pai 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
Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19
Hello Stefan,
On 08/02/22 1:15 am, Stefan Bodewig wrote:
On 2022-02-07, Jaikiran Pai wrote:
So the launch scripts (the Linux one and the .bat for Windows one)
have both been updated to set this system property only for Java 18
and 19. I expect this to be a temporary thing till the new API is
available. Once the new API is available, I think we should just get
rid of this setting of system property even for Java 18 and 19 (since
I don't expect many to be using these releases once the newer versions
are available).
You are more optimistic than me WRT a replacement API. :-)
If you believe this is just going to be an issue for two or three
releases then I can live with a lenghty if. I want to avoid that we need
to cut a new release with every new Java EA just because the replacement
API still hasn't been added.
You have a valid point. In fact, if I had completed these changes a few
weeks back and proposed a release of Ant, it would have had changes only
for Java 18 (and nothing for Java 19). That would have meant another
round of changes plus a release once we saw the Java 19 EA available. So
although I think the new API might be available in some release soon, I
haven't seen any discussion or plans about it yet. So I think it's
better and safer to go with the approach that you suggest in one of the
mails, to enumerate the exact set of Java versions where we don't want
to set this system property.
Ultimately the one I committed ant.bat now launches the Java command
twice and expects it to dump certain property values, which are then
used by "find" to see if the version is 18 or 19.
Ouch
Would
jrunscript -e
"print(java.lang.System.getProperty('java.specification.version'))"
work? TBH I'm not sure jrunscript is available in a JRE rather than a
JDK for versions where there actually is a difference.
Hadn't heard of jrunscript before. I'll experiment a bit.
Also findstr[1] looks as if you could use it to bring the number of
extra jvm executions down to one as it should allow regexes so
find "java.specification.version = 1[89]"
may work - unless Java 20 still comes without the replacement API as it
looks as if the regex subset supported by findstr doesn't include
alternatives.
I had thought of findstr at one point, but wasn't sure if I should use
it. More than a decade back, findstr was used in one of the launch
scripts of JBoss application server. (During those days) it turned out
that the findstr command wasn't available in all versions of Windows and
there ended up being a question on the JBoss forums almost every other
day on the launch script failure. To an extent that it had a FAQ page of
its own. I don't know if findstr not being available in all Windows
versions should be a concern in 2022, but I'll read up and investigate a
bit.
With these changes the CI builds which run Ant tests against Java 18,
19 and previous version like Java 17 now work fine. However, like I
said my scripting skills are minimal, so if any of these changes in
these scripts can be done in a better way, please feel free to do
so. I would do it myself, but it's going to take me trial and error
methods to get it right :)
It would be completely unfair to place the burden on you. I can live
with the current solution even though I'm not happy with it. I might
find a bit of time to experiment this week, but I can't promise
anything.
I too will experiment with some of the suggestions you and others have
provided in this discussion and see how better we can improve this.
-Jaikiran
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: Java 8 for Apache Ivy
+1. No objections. A while back I had thought of proposing this. The worry I had/have was that doing some of these refactoring might introduce hard to catch regressions in the core of Ivy itself (which I personally haven't fully had a grasp of yet). Having said that, targetting Ivy against Java 7 at this point isn't worth it. I think as long as we do the changes/modernizations in controlled manner it's a good idea and I'm in favour of. -Jaikiran On 08/02/22 11:18 pm, Matt Benson wrote: Java 7 public updates have ended nearly 7 years ago. Looking over the Ivy codebase, there appear to be many opportunities for modernization using Java 8 features (new APIs, interface default methods, etc.). Does anyone object to, or have other thoughts on this upgrade? Matt - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Java 8 for AntUnit
Similarly to the question on Ivy, is there any compelling reason we should continue to constrain this antlib to its current level of Java (1.)5? Matt
Java 8 for Apache Ivy
Java 7 public updates have ended nearly 7 years ago. Looking over the Ivy codebase, there appear to be many opportunities for modernization using Java 8 features (new APIs, interface default methods, etc.). Does anyone object to, or have other thoughts on this upgrade? Matt
