You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2022/02/07 06:56:08 UTC
Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19
On 2022-02-07, <ja...@apache.org> wrote:
> - if [ "$JAVA_SPEC_VERSION" = "java.specification.version=18" ]; then
> + if [ "$JAVA_SPEC_VERSION" = "java.specification.version=18" ] || [ "$JAVA_SPEC_VERSION" = "java.specification.version=19" ]; then
Bourne shell's case may make this more
readable (not sure whether there is a Windows batch file equivalent)
case $JAVA_SPEC_VERSION in
java.specification.version=18 | \
java.specification.version=19 )
...
;;
esac
But I'm afraid this is not going to scale :-)
In the long run we probably are better off by enumerating the JDKs where
we don't want to set the property (ten from 8 to 17, but this is a fixed
list that doesn't need to change with every release).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19
Posted by Jaikiran Pai <ja...@apache.org>.
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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19
Posted by Stefan Bodewig <bo...@apache.org>.
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.
> Now coming to the actual implementation of this, it took me multiple
> weekends to get the .bat version to correctly work. Mainly due to lack
> of easy access to a Windows setup plus my general lack of knowledge of
> bat scripting and some gotchas when it comes to .bat parsing and the
> "errorlevel" values.
I'm sorry to hear that. And I must admit my .bat programming skills are
no more exhaustive than yours, most probably even less so.
> 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.
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.
> 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.
Stefan
[1] https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/findstr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19
Posted by Stefan Bodewig <bo...@apache.org>.
On 2022-02-08, 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.
I couldn't find what the property does prior to Java 12, so let me add
this for completeness. This is what happens when you set it on Java 8:
Error occurred during initialization of VM
java.lang.InternalError: Could not create SecurityManager: allow
at sun.misc.Launcher.<init>(Launcher.java:106)
at sun.misc.Launcher.<clinit>(Launcher.java:54)
at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1444)
at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1429)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19
Posted by Jaikiran Pai <ja...@apache.org>.
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 <la...@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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19
Posted by Earl Hood <ea...@gmail.com>.
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 <la...@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
>
Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19
Posted by Jaikiran Pai <ja...@apache.org>.
Hello Jan,
On 08/02/22 12:04 pm, Jan Lahoda wrote:
> On Tue, Feb 8, 2022 at 5:53 AM Jaikiran Pai <ja...@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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19
Posted by Jan Lahoda <la...@gmail.com>.
On Tue, Feb 8, 2022 at 5:53 AM Jaikiran Pai <ja...@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.
Jan
> > Since I work on a project that embeds Ant and uses it API, I am trying
> > assess what I need to do on my end to mitigate the problem. I do not use
> > the launcher scripts, but invoke Ant directly as an embedded service
> (same
> > JVM) or via an external JVM process (most common usage).
>
> The way the JDK implements the security manager removal, setting of
> java.security.manager=allow is only allowed (and expected to work) when
> launching Java. What that means is one cannot use System.setProperty()
> API at runtime to set this property (it won't work). So users of Java
> will have to set this value at launch time. Right now, users who use Ant
> to build their project with Java 18 or 19, can workaround this issue by
> setting the very broad ANT_OPTS environment variable to include
> "-Djava.security.manager=allow". However, given the number of projects
> out there that use Ant and various ways it gets used, I did not want
> users to go fiddle with their build scripts to set up this value in
> ANT_OPTS (that too conditionally based on Java versions). Instead, it's
> much more useful if Ant itself did this in its own launch script, thus
> allowing users to just download this newer version of Ant and continue
> building their projects like they currently do.
>
> Now coming to your embedded case, whoever/whatever launches the original
> JVM within which you launch Ant, will have to be responsible for setting
> this system property while launching the JVM. There's no other way past
> this if you want to use it against Java 18 or 19.
>
>
> -Jaikiran
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19
Posted by Jaikiran Pai <ja...@apache.org>.
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.
> Since I work on a project that embeds Ant and uses it API, I am trying
> assess what I need to do on my end to mitigate the problem. I do not use
> the launcher scripts, but invoke Ant directly as an embedded service (same
> JVM) or via an external JVM process (most common usage).
The way the JDK implements the security manager removal, setting of
java.security.manager=allow is only allowed (and expected to work) when
launching Java. What that means is one cannot use System.setProperty()
API at runtime to set this property (it won't work). So users of Java
will have to set this value at launch time. Right now, users who use Ant
to build their project with Java 18 or 19, can workaround this issue by
setting the very broad ANT_OPTS environment variable to include
"-Djava.security.manager=allow". However, given the number of projects
out there that use Ant and various ways it gets used, I did not want
users to go fiddle with their build scripts to set up this value in
ANT_OPTS (that too conditionally based on Java versions). Instead, it's
much more useful if Ant itself did this in its own launch script, thus
allowing users to just download this newer version of Ant and continue
building their projects like they currently do.
Now coming to your embedded case, whoever/whatever launches the original
JVM within which you launch Ant, will have to be responsible for setting
this system property while launching the JVM. There's no other way past
this if you want to use it against Java 18 or 19.
-Jaikiran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19
Posted by Earl Hood <ea...@gmail.com>.
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?
Since I work on a project that embeds Ant and uses it API, I am trying
assess what I need to do on my end to mitigate the problem. I do not use
the launcher scripts, but invoke Ant directly as an embedded service (same
JVM) or via an external JVM process (most common usage).
Regards,
--ewh
On Mon, Feb 7, 2022, 4:18 AM Jaikiran Pai <ja...@apache.org> wrote:
> Hello Stefan,
>
> I was planning to send out a mail about this change later tonight. But
> good you brought this up. To give some background, the security manager
> changes starting Java 18 make it such that setting of the security
> manager at runtime now throws an exception, which effectively fails all
> builds since Ant by default sets up a security manager. After various
> experimentations and checking over with the JDK team, it appears that we
> (Ant) can't get rid of setting the security manager till the JDK team
> provides an API to prevent System.exit(...) calls. So in the meantime to
> allow users of Ant to build their projects and test for any issues
> against Java 18 (and now Java 19 EA), I decided to specifically set this
> system property only for these specific versions. Initially I had only
> done it for Java 18, hoping that a new API for System.exit(...)
> prevention would be availbale in 19, but it isn't ready so far. 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).
>
> Now coming to the actual implementation of this, it took me multiple
> weekends to get the .bat version to correctly work. Mainly due to lack
> of easy access to a Windows setup plus my general lack of knowledge of
> bat scripting and some gotchas when it comes to .bat parsing and the
> "errorlevel" values. 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. So
> essentially, launching Ant (on Windows) now additionally triggers
> lauching of two Java process (they do exit) just to check the version.
> It's not the best way, but I couldn't find any other way to do this.
>
> As for the Linux version of the ant launch script it does a similar
> thing but in its case it just launches the Java program once and figures
> out if the version is 18 or 19.
>
> 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 :)
>
> -Jaikiran
>
> On 07/02/22 12:26 pm, Stefan Bodewig wrote:
> > On 2022-02-07, <ja...@apache.org> wrote:
> >
> >> - if [ "$JAVA_SPEC_VERSION" = "java.specification.version=18" ]; then
> >> + if [ "$JAVA_SPEC_VERSION" = "java.specification.version=18" ] || [
> "$JAVA_SPEC_VERSION" = "java.specification.version=19" ]; then
> > Bourne shell's case may make this more
> > readable (not sure whether there is a Windows batch file equivalent)
> >
> > case $JAVA_SPEC_VERSION in
> > java.specification.version=18 | \
> > java.specification.version=19 )
> > ...
> > ;;
> > esac
> >
> > But I'm afraid this is not going to scale :-)
> >
> > In the long run we probably are better off by enumerating the JDKs where
> > we don't want to set the property (ten from 8 to 17, but this is a fixed
> > list that doesn't need to change with every release).
> >
> > Stefan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19
Posted by Jaikiran Pai <ja...@apache.org>.
Hello Stefan,
I was planning to send out a mail about this change later tonight. But
good you brought this up. To give some background, the security manager
changes starting Java 18 make it such that setting of the security
manager at runtime now throws an exception, which effectively fails all
builds since Ant by default sets up a security manager. After various
experimentations and checking over with the JDK team, it appears that we
(Ant) can't get rid of setting the security manager till the JDK team
provides an API to prevent System.exit(...) calls. So in the meantime to
allow users of Ant to build their projects and test for any issues
against Java 18 (and now Java 19 EA), I decided to specifically set this
system property only for these specific versions. Initially I had only
done it for Java 18, hoping that a new API for System.exit(...)
prevention would be availbale in 19, but it isn't ready so far. 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).
Now coming to the actual implementation of this, it took me multiple
weekends to get the .bat version to correctly work. Mainly due to lack
of easy access to a Windows setup plus my general lack of knowledge of
bat scripting and some gotchas when it comes to .bat parsing and the
"errorlevel" values. 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. So
essentially, launching Ant (on Windows) now additionally triggers
lauching of two Java process (they do exit) just to check the version.
It's not the best way, but I couldn't find any other way to do this.
As for the Linux version of the ant launch script it does a similar
thing but in its case it just launches the Java program once and figures
out if the version is 18 or 19.
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 :)
-Jaikiran
On 07/02/22 12:26 pm, Stefan Bodewig wrote:
> On 2022-02-07, <ja...@apache.org> wrote:
>
>> - if [ "$JAVA_SPEC_VERSION" = "java.specification.version=18" ]; then
>> + if [ "$JAVA_SPEC_VERSION" = "java.specification.version=18" ] || [ "$JAVA_SPEC_VERSION" = "java.specification.version=19" ]; then
> Bourne shell's case may make this more
> readable (not sure whether there is a Windows batch file equivalent)
>
> case $JAVA_SPEC_VERSION in
> java.specification.version=18 | \
> java.specification.version=19 )
> ...
> ;;
> esac
>
> But I'm afraid this is not going to scale :-)
>
> In the long run we probably are better off by enumerating the JDKs where
> we don't want to set the property (ten from 8 to 17, but this is a fixed
> list that doesn't need to change with every release).
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org