Do you know if there is an issue with the "allow" class approach if multiple projects adopt that technique? E.g. if Netbeans or Groovy also have an allow class, will that cause a split package violation or since it isn't really referenced except for those early JDKs, that we should be okay? I will eventually try this out myself if searching doesn't help, but just wondering if someone has already checked this.
On Sun, Dec 11, 2022 at 11:38 PM Jaikiran Pai <jaiki...@apache.org> wrote: > > Hello Stefan, > > On 18/11/22 2:40 pm, Stefan Bodewig wrote: > > On 2022-11-16, Jaikiran Pai wrote: > > > >> Users can still use the current released Ant version against these > >> recent Java versions, but they additionally have to set a system > >> property while launching Ant to allow setting the security > >> manager. Ant's mainline code has changes where it does the necessary > >> work (to the extent possible) to set this property internally without > >> forcing the users to do that. So releasing this version of Ant should > >> help projects building against these recent versions. > > I guess you've seen Earl Hood's response, I haven't looked into it > > myself, yet. > > Yes, that response helped me decide which way to go. Before that, I was > still inclined to try and get this working by doing necessary changes to > the launcher scripts - but that was going nowhere and it introduced the > unnecessary dual launch of Java (once to identify the version and then > the real launch). ewh's response gave me the confidence that using > "allow" as a class (on Java versions where it isn't recognized as a > predefined value) would be the better of the 2 approaches. > > I found some time this weekend to get this implemented in Ant and have > now committed > https://github.com/apache/ant/commit/82c70f3202d5aec4d99fa3b6314ba4a6c338cd94. > Tests against JDK 8, 11, 17, 19 and latest 20 EA all came back fine > against Linux and Windows. > > -Jaikiran > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
