Re: Impact of Java SecurityManager being deprecated for removal post Java 17
On 2021-08-23, Jaikiran Pai wrote: > On 19/08/21 3:23 pm, Stefan Bodewig wrote: >> On 2021-08-19, Jaikiran Pai wrote: >>> Hello Stefan, >>> On 19/08/21 1:15 pm, Stefan Bodewig wrote: At a cursory glance I only see JUnitTask and ExecuteJava deal with the SecurityManager if permissions have been defined. Where else do we use one? >>> From what I see in the Java task code[1], the "execute()" method of >>> that task calls, "checkConfiguration()"[2] method, which in a >>> non-forked mode, creates a Permissions instance if no explicit >>> permissions has been configured[3]. >> I only searched for SecurityManager :-) Thanks. >> So we are using Ant's permissions system internally to preven >> System.exit, I see. This is the stuff we will need to replace with >> whatever is going to be the new API that prevents System.exit. Let's >> hope all this is not going to become an ugly hack. > Work has already started to "disallow" SecurityManager as early as > some upcoming JDK 18 EA release[1]. What that means is any calls to > System.setSecurityManager(...) would start throwing exceptions. I > haven't seen much discussion around any proposed API for the > System.exit(...) usecase. So I decided to explain Ant's use case and > request for the new API to be included in Java 18 > hopefully. Discussion is here[2]. Thanks. I'm not sure I understand Alan's answer, but if I do then it might happen that setSecurityManager throws exceptions before a different API is in place - and the only thing we can do is to tell our users to fork new VMs rather then run in process. This is not exactly the user experience I'd be hoping for, but so be it. > I hope I included the correct details and didn't miss anything. I > don't have historical knowledge around this code in Ant and it's all > based on what I read in the Ant code. If I missed something or mispoke > about the usage, please feel free to join that discussion and reply. My recollection is vague at best. I don't see any mistake in what you have described. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Impact of Java SecurityManager being deprecated for removal post Java 17
On 2021-08-19, Gintautas Grigelionis wrote: > On Thu, 19 Aug 2021 at 12:01, Stefan Bodewig wrote: >> I didn't mean the Antlib to be backwards compatible, but rather to offer >> it and tell people to switch over to it. It would be the first time we'd >> remove a core feature of Ant completely, though, so we may need to >> discuss whether there is a better migration path. We have moved some >> source code management tool specific tasks to antlibs in the past, but >> never a core part. > Would it make sense to create a "legacy" antlib for, say, JEE (EJB, JSP, > etc) and VCS tasks + anything that has been deprecated in JDK? I'd only do that if it reduces maintenance burden for anybody. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Impact of Java SecurityManager being deprecated for removal post Java 17
On 19/08/21 3:23 pm, Stefan Bodewig wrote: On 2021-08-19, Jaikiran Pai wrote: Hello Stefan, On 19/08/21 1:15 pm, Stefan Bodewig wrote: At a cursory glance I only see JUnitTask and ExecuteJava deal with the SecurityManager if permissions have been defined. Where else do we use one? From what I see in the Java task code[1], the "execute()" method of that task calls, "checkConfiguration()"[2] method, which in a non-forked mode, creates a Permissions instance if no explicit permissions has been configured[3]. I only searched for SecurityManager :-) Thanks. So we are using Ant's permissions system internally to preven System.exit, I see. This is the stuff we will need to replace with whatever is going to be the new API that prevents System.exit. Let's hope all this is not going to become an ugly hack. Work has already started to "disallow" SecurityManager as early as some upcoming JDK 18 EA release[1]. What that means is any calls to System.setSecurityManager(...) would start throwing exceptions. I haven't seen much discussion around any proposed API for the System.exit(...) usecase. So I decided to explain Ant's use case and request for the new API to be included in Java 18 hopefully. Discussion is here[2]. I hope I included the correct details and didn't miss anything. I don't have historical knowledge around this code in Ant and it's all based on what I read in the Ant code. If I missed something or mispoke about the usage, please feel free to join that discussion and reply. [1] https://github.com/openjdk/jdk/pull/5204 [2] https://mail.openjdk.java.net/pipermail/security-dev/2021-August/027172.html -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
