[RESULT] Release Apache Ant 1.10.15 based on RC2
With +1s from Martijn, Stefan, Maarten and me, this vote has now passed. I'll now go ahead and complete the rest of the release process. Thank you all for helping with this release. -Jaikiran On 27/08/24 11:33 am, Martijn Kruithof wrote: +1 Martijn Op 27/08/2024 om 03:42 schreef Jaikiran Pai: +1 -Jaikiran On 25/08/24 8:49 pm, Jaikiran Pai wrote: Hello everyone, I've created RC2 release candidate for Ant 1.10.15 release: git tag: ANT_1.10.15_RC2 on commit: 92fe5ca29625d30b98704806d6379fe9acb001e3 tarballs: https://dist.apache.org/repos/dist/dev/ant/ svn revision: 71094 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1063/ This 1.10.15 release of Ant is a regular bug fix release and contains changes that are noted in the release notes at https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.15.html. The previous release, 1.10.14, had crucial changes in Ant to stop using Java SecurityManager when Ant is used in Java runtime 18 or higher. Apart from a bug in a launcher script, we haven't heard any issues with those changes and that's a good sign. We also have heard that users have been using that version of Ant in Java 18 and higher, so it's a sign that the changes we did to stop setting SecurityManager at runtime in Ant hasn't impacted projects adversely. Please give this proposed release a try against your projects and let us know if there are any issues. This is a vote email and the voting will be open for at least 72 hours and close no earlier than 28th August 2024 21:00 UTC. -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 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Apache Ant 1.10.15 based on RC2
+1 -Jaikiran On 25/08/24 8:49 pm, Jaikiran Pai wrote: Hello everyone, I've created RC2 release candidate for Ant 1.10.15 release: git tag: ANT_1.10.15_RC2 on commit: 92fe5ca29625d30b98704806d6379fe9acb001e3 tarballs: https://dist.apache.org/repos/dist/dev/ant/ svn revision: 71094 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1063/ This 1.10.15 release of Ant is a regular bug fix release and contains changes that are noted in the release notes at https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.15.html. The previous release, 1.10.14, had crucial changes in Ant to stop using Java SecurityManager when Ant is used in Java runtime 18 or higher. Apart from a bug in a launcher script, we haven't heard any issues with those changes and that's a good sign. We also have heard that users have been using that version of Ant in Java 18 and higher, so it's a sign that the changes we did to stop setting SecurityManager at runtime in Ant hasn't impacted projects adversely. Please give this proposed release a try against your projects and let us know if there are any issues. This is a vote email and the voting will be open for at least 72 hours and close no earlier than 28th August 2024 21:00 UTC. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Issues noticed in RC1 of 1.10.15 have been addressed (was: [VOTE] ...)
On 21/08/24 4:23 am, Martijn Kruithof wrote: Checked the diff between rel 1.10.14 and 1.10.15 RC 1 in git: It seems the following changes are missing from the release notes / whatsnew: - ReplaceRegExp task has a new failOnError attribute (also it seems Andrew Quan seems to have contributed this change and has not been included in the Contributors) This turned out to be an issue in the WHATSNEW file. The entry about this was accidentally added in the older release section - 1.10.14 instead of 1.10.15. I've corrected this part. As for adding Andrew to the contributors list, it appears that the contributor did not want to be added to the list as noted in their PR https://github.com/apache/ant/pull/206#issuecomment-1815320520. So I haven't updated the contributors list. - FTP task now has an (experimental? / undocumented) option to use a secure data channel with FTPS. Fixed the ftp documentation/manual as well as included this change in the WHATSNEW file. With these changes, I've now initiated a vote mail of RC2 for Ant 1.10.15 release. Thank you again for spotting these issues. -Jaikiran Thanks a lot! Martijn Op 19/08/2024 om 16:53 schreef Stefan Bodewig: On 2024-08-18, Jaikiran Pai wrote: This is a vote email and the voting will be open for at least 72 hours and close no earlier than 21st August 2024 14:30 UTC. +1 compared tag and source tarball, checked hashes and signatures. Things look good to me. Thanks Stefan - 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 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[VOTE] Release Apache Ant 1.10.15 based on RC2
Hello everyone, I've created RC2 release candidate for Ant 1.10.15 release: git tag: ANT_1.10.15_RC2 on commit: 92fe5ca29625d30b98704806d6379fe9acb001e3 tarballs: https://dist.apache.org/repos/dist/dev/ant/ svn revision: 71094 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1063/ This 1.10.15 release of Ant is a regular bug fix release and contains changes that are noted in the release notes at https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.15.html. The previous release, 1.10.14, had crucial changes in Ant to stop using Java SecurityManager when Ant is used in Java runtime 18 or higher. Apart from a bug in a launcher script, we haven't heard any issues with those changes and that's a good sign. We also have heard that users have been using that version of Ant in Java 18 and higher, so it's a sign that the changes we did to stop setting SecurityManager at runtime in Ant hasn't impacted projects adversely. Please give this proposed release a try against your projects and let us know if there are any issues. This is a vote email and the voting will be open for at least 72 hours and close no earlier than 28th August 2024 21:00 UTC. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [CANCELLED] Release Apache Ant 1.10.15 based on RC1
Thank you Martijn for catching that. The missing entries in WHATSNEW and release notes, I think, would have been OK to fix separately but given the fact that the manual is missing a new attribute for the ftp task and we missed adding a new contributor the list of contributors, I'll go ahead and cancel this vote. I will create a new RC after addressing these issues and will intiate a new vote soon. -Jaikiran On 21/08/24 4:23 am, Martijn Kruithof wrote: Checked the diff between rel 1.10.14 and 1.10.15 RC 1 in git: It seems the following changes are missing from the release notes / whatsnew: - ReplaceRegExp task has a new failOnError attribute (also it seems Andrew Quan seems to have contributed this change and has not been included in the Contributors) - FTP task now has an (experimental? / undocumented) option to use a secure data channel with FTPS. Thanks a lot! Martijn Op 19/08/2024 om 16:53 schreef Stefan Bodewig: On 2024-08-18, Jaikiran Pai wrote: This is a vote email and the voting will be open for at least 72 hours and close no earlier than 21st August 2024 14:30 UTC. +1 compared tag and source tarball, checked hashes and signatures. Things look good to me. Thanks Stefan - 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 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Apache Ant 1.10.15 based on RC1
+1 - Downloaded the newer version and checked the NOTICE file - verified the checksum - Checked manual docs for some of the tasks - Built some projects using Java 8 and Java 22 and this released version of Ant. -Jaikiran On 18/08/24 7:46 pm, Jaikiran Pai wrote: Hello everyone, I've created RC1 release candidate for Ant 1.10.15 release: git tag: ANT_1.10.15_RC1 on commit: 2250895d174f5beee54e9e4ea9523500feb1f1f9 tarballs: https://dist.apache.org/repos/dist/dev/ant/ svn revision: 70964 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1062 This 1.10.15 release of Ant is a regular bug fix release and contains changes that are noted in the release notes at https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.15.html. The previous release, 1.10.14, had crucial changes in Ant to stop using Java SecurityManager when Ant is used in Java runtime 18 or higher. Apart from a bug in a launcher script, we haven't heard any issues with those changes and that's a good sign. We also have heard that users have been using that version of Ant in Java 18 and higher, so it's a sign that the changes we did to stop setting SecurityManager at runtime in Ant hasn't impacted projects adversely. Please give this proposed release a try against your projects and let us know if there are any issues. This is a vote email and the voting will be open for at least 72 hours and close no earlier than 21st August 2024 14:30 UTC. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[VOTE] Release Apache Ant 1.10.15 based on RC1
Hello everyone, I've created RC1 release candidate for Ant 1.10.15 release: git tag: ANT_1.10.15_RC1 on commit: 2250895d174f5beee54e9e4ea9523500feb1f1f9 tarballs: https://dist.apache.org/repos/dist/dev/ant/ svn revision: 70964 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1062 This 1.10.15 release of Ant is a regular bug fix release and contains changes that are noted in the release notes at https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.15.html. The previous release, 1.10.14, had crucial changes in Ant to stop using Java SecurityManager when Ant is used in Java runtime 18 or higher. Apart from a bug in a launcher script, we haven't heard any issues with those changes and that's a good sign. We also have heard that users have been using that version of Ant in Java 18 and higher, so it's a sign that the changes we did to stop setting SecurityManager at runtime in Ant hasn't impacted projects adversely. Please give this proposed release a try against your projects and let us know if there are any issues. This is a vote email and the voting will be open for at least 72 hours and close no earlier than 21st August 2024 14:30 UTC. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Release Ant 1.10.15?
Hello Florian, I have been meaning to release Ant 1.10.15 for a few weeks now, but haven't found the time to do it. I will prioritize this in the coming weeks. -Jaikiran On 31/07/24 5:05 pm, Florian Rosenauer wrote: Hi, the last ant release 1.10.14 is now almost one year old, do you plan a new release? I am asking especially because of https://bz.apache.org/bugzilla/show_bug.cgi?id=68773 because I would like to use a released ant version in production and not a nightly build :) Thank you very much Florian On 2024/02/23 10:24:21 Stefan Bodewig wrote: On 2024-02-21, Jaikiran Pai wrote: If it's OK then I plan to do the next 1.10.x release in a few weeks, unless someone is working on anything that needs to be part of this release. +1 I currently haven't got anything I'd be working on. Stefan - 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 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: JDK 23 RDP2 | Removal of the legacy COMPAT locale provider and more heads-up!
Hello David, I ran our Ant testsuite against JDK 23 build 23-ea+33-2358. The tests ran fine and no related issues were noticed https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Linux%20(latest%20EA%20JDK)/51/ -Jaikiran On 22/07/24 10:55 am, David Delabassee wrote: Welcome to the OpenJDK Quality Outreach summer update. JDK 23 is now in Rampdown Phase Two [1], its overall feature has been frozen a few weeks ago. Per the JDK Release Process, we have now turned our focus to P1 and P2 bugs, which can be fixed with approval [2]. Late enhancements are still possible, with approval, but the bar is now extraordinarily high. That also means that the JDK 23 Initial Release Candidates are fast approaching, i.e., August 8th [3]! So, and in addition to testing your projects with the latest JDK 23 early-access builds, it is now a good time to start testing with the JDK 24 early-access builds. Make sure to also check the heads-up below as some are related to JDK 23 and might have some impact, i.e., the first one being related to the eventual removal of the Security Manager and the second one discusses the removal of the legacy COMPAT locale provider. [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-July/009252.html [2] https://openjdk.org/jeps/3#rdp-2 [3] https://openjdk.org/projects/jdk/23/ ## Heads-up - JDK 23: Subject.getSubject API Requires Allowing the Security Manager In JDK 17 and as announced in JEP 411 [4], the Security Manager was deprecated for removal. As part of that change, several Security Manager APIs, such as `AccessControlContext`, were deprecated for removal. The `Subject::doAs` and `Subject::getSubject` APIs depend on Security Manager related APIs even though they do not require Security Manager to be installed to use them. As of JDK 23 [5], to help applications prepare for the eventual removal of the Security Manager, subject authorization and the Subject APIs' behavior depend on allowing the Security Manager: - If the system property `java.security.manager` is set on the command line to the empty string, a class name, or the value `allow` then there is no behavior change compared to previous releases. - If the system property `java.security.manager` is not set on the command line or has been set on the command line to the value `disallow`, invoking the `Subject.getSubject` method will throw `UnsupportedOperationException`. Yet, running an application with `-Djava.security.manager=allow` is a temporary workaround to keep older code working. Maintainers of code using `Subject.doAs` and `Subject.getSubject` are strongly encouraged to migrate it with utmost priority to the replacement APIs, `Subject.callAs` and `Subject.current`. Make sure to check [5] and [6] for additional details. The jdeprscan tool [7] scans a JAR file for usage of deprecated API elements and is helpful to find code using these methods. Additionally, consider migrating as soon as possible code that stores a `Subject` in an `AccessControlContext` and invokes `AccessController.doPrivileged` with that context. Such code will stop working when the Security Manager is removed. [4] https://openjdk.org/jeps/411 [5] https://jdk.java.net/23/release-notes#b15 [6] https://inside.java/2024/07/08/quality-heads-up/ [7] https://dev.java/learn/jvm/tools/core/jdeprscan/ ## Heads-up - JDK 23: Unicode / Removal of COMPAT Locale Provider ### A Quick History of Locale Data in the JDK Before the Unicode Consortium created the Common Locale Data Repository (CLDR) in 2003 to manage locale data, the JDK had to provide its own collection. It did so successfully and in JDK 8 supported about 160 locales. To reduce maintenance effort, allow better interoperability between platforms, and improve locale data quality, the JDK started to move towards CLDR in 2014: - JDK 8 comes with two locale data providers, which can be selected with the system property java.locale.providers: . JRE/COMPAT for the JDK’s legacy data collection (default) . CLDR for the CLDR data . a custom locale provider can be implemented - JDK 9 picks CLDR by default - JDK 21 issues a warning on JRE/COMPAT There are plenty of minor and a few notable differences between the legacy data and CLDR - the recently rewritten JEP 252 [8] lists a few of them. ### Locale Data in JDK 23 JDK 23 [9] removes legacy locale data. As a consequence, setting java.locale.providers to JRE or COMPAT has no effect. Projects that are still using legacy locale data are highly encouraged to switch to CLDR as soon as possible. Where that is infeasible, two alternatives remain: - Create custom formatters with patterns that mimic the legacy behavior and use them everywhere where locale-sensitive data is written or parsed. - Implement a custom locale data provider [10]. For more details on that as well as on CLDR in the JDK in general, please check JEP 252 [8] that has been recently rewritten to provide better information and gui
Re: [RESULT] EOL Apache Ant 1.9.x release series
In the coming days, I'll update relevant pages of our website to note this decision. -Jaikiran On 19/06/24 2:56 pm, Jaikiran Pai wrote: Hello everyone, With binding +1s from Ant PMC members: Dominique Devienne Nicolas Lalevée Martijn Kruithof Maarten Coene Jaikiran Pai and a non-binding +1 from Roger Whitcomb and no other votes, it is decided that Apache Ant 1.9.x series is now EOLed. There won't be any more Ant 1.9.x releases and Ant 1.9.16 which was released a few years back is the last release in this 1.9.x series. Thank you all for voting. -Jaikiran On 16/06/24 11:40 am, Jaikiran Pai wrote: Hello everyone, 4 years back in 2020, we initiated an vote to EOL 1.9.x release versions of Apache Ant. We didn't receive enough votes at that time to formalize it (which is OK). The last release of Ant 1.9.x release series was back in 2021 and that was a security fix. The Ant 1.9.x branch hasn't seen any recent commits in around 2 years. At the same time the Ant master branch from where we do the 1.10.x release has been active with bug fixes and relatively smaller enhancements. We have been releasing Ant 1.10.x regularly too. Ant 1.9.x allows Java 5 as a runtime whereas Ant 1.10.x requires Java 8 as the minimal runtime. The support for Java 5 has been the sole reason why the last few times we proposed EOLing 1.9.x, the vote didn't pass. Having said that, I (one of the release managers of Ant) haven't had access to Java 5 for several years now. Plus, Ant 1.9.x doesn't have several of the bug fixes that have gone into Ant 1.10.x since the past several years. The decision to not backport bug fixes from 1.10.x into 1.9.x has been intentional, it not easy to maintain Java 5 compatibility for code changes, plus the development time and testing time for such backports isn't something that we wanted to invest in. So effectively, Ant 1.9.x currently lacks features and fixes when compared to 1.10.x. Given all this, I would like to officially call for vote to EOL 1.9.x releases. What that would mean is that there won't be any more Ant 1.9.x releases. Ant 1.9.16, the last release in this 1.9.x series, 3 years back, would officially be the last one. If users do want to use that version, they can continue to do so by getting it from the usual Apache Ant download page. Having EOLed 1.9.x, the Ant team can then solely focus on 1.10.x and that makes it much more simpler to deal with managing the project infrastructure as well as code changes. As usual, please cast your vote by replying to the list. This vote will close in 72 hours, no earlier than 19 June 2024, 06:30 UTC. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[RESULT] EOL Apache Ant 1.9.x release series
Hello everyone, With binding +1s from Ant PMC members: Dominique Devienne Nicolas Lalevée Martijn Kruithof Maarten Coene Jaikiran Pai and a non-binding +1 from Roger Whitcomb and no other votes, it is decided that Apache Ant 1.9.x series is now EOLed. There won't be any more Ant 1.9.x releases and Ant 1.9.16 which was released a few years back is the last release in this 1.9.x series. Thank you all for voting. -Jaikiran On 16/06/24 11:40 am, Jaikiran Pai wrote: Hello everyone, 4 years back in 2020, we initiated an vote to EOL 1.9.x release versions of Apache Ant. We didn't receive enough votes at that time to formalize it (which is OK). The last release of Ant 1.9.x release series was back in 2021 and that was a security fix. The Ant 1.9.x branch hasn't seen any recent commits in around 2 years. At the same time the Ant master branch from where we do the 1.10.x release has been active with bug fixes and relatively smaller enhancements. We have been releasing Ant 1.10.x regularly too. Ant 1.9.x allows Java 5 as a runtime whereas Ant 1.10.x requires Java 8 as the minimal runtime. The support for Java 5 has been the sole reason why the last few times we proposed EOLing 1.9.x, the vote didn't pass. Having said that, I (one of the release managers of Ant) haven't had access to Java 5 for several years now. Plus, Ant 1.9.x doesn't have several of the bug fixes that have gone into Ant 1.10.x since the past several years. The decision to not backport bug fixes from 1.10.x into 1.9.x has been intentional, it not easy to maintain Java 5 compatibility for code changes, plus the development time and testing time for such backports isn't something that we wanted to invest in. So effectively, Ant 1.9.x currently lacks features and fixes when compared to 1.10.x. Given all this, I would like to officially call for vote to EOL 1.9.x releases. What that would mean is that there won't be any more Ant 1.9.x releases. Ant 1.9.16, the last release in this 1.9.x series, 3 years back, would officially be the last one. If users do want to use that version, they can continue to do so by getting it from the usual Apache Ant download page. Having EOLed 1.9.x, the Ant team can then solely focus on 1.10.x and that makes it much more simpler to deal with managing the project infrastructure as well as code changes. As usual, please cast your vote by replying to the list. This vote will close in 72 hours, no earlier than 19 June 2024, 06:30 UTC. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] EOL Apache Ant 1.9.x release series
Implicit +1 from me. -Jaikiran On 16/06/24 11:40 am, Jaikiran Pai wrote: Hello everyone, 4 years back in 2020, we initiated an vote to EOL 1.9.x release versions of Apache Ant. We didn't receive enough votes at that time to formalize it (which is OK). The last release of Ant 1.9.x release series was back in 2021 and that was a security fix. The Ant 1.9.x branch hasn't seen any recent commits in around 2 years. At the same time the Ant master branch from where we do the 1.10.x release has been active with bug fixes and relatively smaller enhancements. We have been releasing Ant 1.10.x regularly too. Ant 1.9.x allows Java 5 as a runtime whereas Ant 1.10.x requires Java 8 as the minimal runtime. The support for Java 5 has been the sole reason why the last few times we proposed EOLing 1.9.x, the vote didn't pass. Having said that, I (one of the release managers of Ant) haven't had access to Java 5 for several years now. Plus, Ant 1.9.x doesn't have several of the bug fixes that have gone into Ant 1.10.x since the past several years. The decision to not backport bug fixes from 1.10.x into 1.9.x has been intentional, it not easy to maintain Java 5 compatibility for code changes, plus the development time and testing time for such backports isn't something that we wanted to invest in. So effectively, Ant 1.9.x currently lacks features and fixes when compared to 1.10.x. Given all this, I would like to officially call for vote to EOL 1.9.x releases. What that would mean is that there won't be any more Ant 1.9.x releases. Ant 1.9.16, the last release in this 1.9.x series, 3 years back, would officially be the last one. If users do want to use that version, they can continue to do so by getting it from the usual Apache Ant download page. Having EOLed 1.9.x, the Ant team can then solely focus on 1.10.x and that makes it much more simpler to deal with managing the project infrastructure as well as code changes. As usual, please cast your vote by replying to the list. This vote will close in 72 hours, no earlier than 19 June 2024, 06:30 UTC. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: JDK 23 Feature Freeze / New Loom EA builds
Hello David, I ran our Ant testsuite against JDK 23 EA build 23-ea+26-2269 and no related issues were noticed https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Linux%20(latest%20EA%20JDK)/50/ -Jaikiran On 10/06/24 12:58 pm, David Delabassee wrote: Welcome to the latest OpenJDK Quality Outreach update! JDK 23, scheduled for General Availability on September 17, 2024, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 23 feature set is frozen (see the final list of JEPs integrated into JDK 23 below) and only low-risk enhancements might still be considered. The coming weeks should be leveraged to identify and resolve as many issues as possible, i.e. before JDK 23 enters the Release Candidates phase in early August [2]. We count on you to test your projects and help us make JDK 23 another solid release! This time, we are covering several heads-up related to JDK 23 : Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal and default annotation processing policy change. Also, make sure to check the new Loom early-access builds which have an improved Java monitors implementation to work better with virtual threads. [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009053.html [2] https://openjdk.org/projects/jdk/23/ ## Heads-Up - JDK 23: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal As mentioned in a previous communication [3], there’s a plan to ultimately remove the sun.misc.Unsafe memory-access methods as the platform offers safer alternatives. JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal) [4] outlines in more detail this plan including the initial step which is happening in JDK 23, i.e., all of the sun.misc unsafe memory-access methods are now marked as deprecated for removal. This will cause, in JDK 23, compile-time deprecation warnings for code that refers to these methods, alerting library developers to their forthcoming removal. A new command-line option also enables application developers and users to receive runtime warnings when those methods are used. Developers relying on those sun.misc.Unsafe APIs for access memory are strongly encouraged to start, if they haven't done so yet, the migration from the sun.misc.Unsafe APIs to supported replacements. For more details, make sure to read JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal). [3] https://mail.openjdk.org/pipermail/quality-discuss/2024-January/001132.html [4] https://openjdk.org/jeps/471 ## Heads-Up - JDK 23: Changes Default Annotation Processing Policy Annotation processing is a compile-time feature, where javac scans the to-be-compiled source files for annotations and then the class path for matching annotation processors, so they can generate source code. Up to JDK 22, this feature is enabled by default, which may have been reasonable when it was introduced in JDK 6 circa 2006, but from a current perspective, in the interest of making build output more robust against annotation processors being placed on the class path unintentionally, this is much less reasonable. Hence, starting with JDK 23, javac requires an additional command-line option to enable annotation processing. ### New `-proc` Value To that end, the pre-existing option `-proc:$policy` was extended, where `$policy` can now have the following values: - `none`: compilation _without_ annotation processing, this policy exists since JDK 6 - `only`: annotation processing _without_ compilation, this policy exists since JDK 6 - `full`: annotation processing followed by compilation, this policy is the default in JDK ≤22 but the value itself is new (see next section for versions that support it) Up to and including JDK 22, code bases that require annotation processing before compilation could rely on javac's default behavior to process annotations but that is no longer the case. Starting with JDK 23, at least one annotation-processing command line option needs to be present. If neither `-processor`, `--processor-path`, now `--processor-module-path` is used, `-proc:only` or `-proc:full` has to be provided. In other words, absent other command line options, `-proc:none` is the default on JDK 23. ### Migration to `-proc:full` Several measures were undertaken to help projects prepare for the switch to `-proc:full`: - As of the April 2024 JDK security updates, support for `-proc:full` has been backported to 17u (17.0.11) and 11u (11.0.23) for both Oracle JDK and OpenJDK distributions. Additionally, Oracle's 8u release (8u411) also supports `-proc:full`. - Starting in JDK 21, javac prints an informative message if implicit usage of annotation processing under the default policy is detected. With `-proc:full` backported, it is possible to configure a build that will work the same before and after the change in javac's default policy. Additional details can be found in the origin
Re: Ant jenkins jobs
The Apache infra team have addressed this issue and I am now able to trigger the job runs. -Jaikiran On 12/06/24 10:55 am, Jaikiran Pai wrote: It looks like something has changed with our Jenkins instance and I can no longer trigger Ant jobs - I don't see the "Build/Build with Parameters" link or any such link which allows you to trigger the job, even after I am successfully logged in. Could one of you who previously used to trigger some of these jobs, please see if you are able to trigger one? My question to the infra team hasn't seen any response so far. -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
Ant jenkins jobs
It looks like something has changed with our Jenkins instance and I can no longer trigger Ant jobs - I don't see the "Build/Build with Parameters" link or any such link which allows you to trigger the job, even after I am successfully logged in. Could one of you who previously used to trigger some of these jobs, please see if you are able to trigger one? My question to the infra team hasn't seen any response so far. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Java 22 is GA + Heads-up!
Hello David, I ran our Ant testsuite against Java 22 build 22+36-2370 and Java 23 EA build 23-ea+17-1368. The tests completed fine and no regressions or issues were found: https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Linux%20(latest%20EA%20JDK)/48/ https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Linux%20(latest%20EA%20JDK)/49/ -Jaikiran On 02/04/24 12:53 pm, David Delabassee wrote: Welcome to the latest OpenJDK Quality Outreach update! Java 22 was just released along with JavaFX 22 [1][2]. Thank you to all the projects who contributed to those releases by testing and providing feedback using their respective early-access builds. And to celebrate that, the Java DevRel Team hosted a +4h live-stream with guests such as Brian Goetz, Viktor Klang, Alan Bateman, etc. You can watch the launch stream replay here [3]. The JDK 23 schedule is now known [4] with rampdown starting early June and general availability sets for mid-September. So far, 2 JEPs have been targeted to JDK 23: - JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview) [5] - JEP 466: Class-File API (2nd Preview) [6] The focus should now be shifted to testing your project(s) on JDK 23. And don't forget that the Oracle setup-java github action [7] supports, amongst others, the latest OpenJDK 23 Early-Access builds. So, JDK 23 EA testing is literally one pipeline away. [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-March/008827.html [3] https://jdk.java.net/javafx22/ [3] https://www.youtube.com/live/AjjAZsnRXtE?feature=shared&t=278 [4] https://openjdk.org/projects/jdk/23/ [5] https://openjdk.org/jeps/455 [6] https://openjdk.org/jeps/466 [7] https://github.com/oracle-actions/setup-java ## Heads-up: JDK 20-23: Support for Unicode CLDR Version 42 The JDK update to CLDR version 42 included a change where regular spaces in date/time formats (and some other formatted values) were replaced with (narrow) non-breaking spaces. This lead to issues for existing code that relied on parsing such strings. To address that, JDK 23 allows loose matching of spaces when parsing date/time strings. Loose matching is performed in the lenient parsing style for both date/time parsers in `java.time.format` and `java.text` packages. In the default strict parsing style, those spaces are considered distinct as before. Please read this updated heads-up [9] for details on how to configure strict/lenient parsing in the `java.time.format` (strict by default) and `java.text` (lenient by default) packages. [9] https://inside.java/2024/03/29/quality-heads-up/ ## Heads-up: macOS 14 users running on Apple silicon systems should update directly to macOS 14.4.1 An issue introduced by macOS 14.4 caused some Java processes, regardless of the Java version, to terminate unexpectedly on Apple silicon (AArch64). On March 25 Apple released macOS 14.4.1 and indicated on their support site that it addresses this issue. Oracle can confirm that after applying macOS 14.4.1 we are unable to reproduce the problem. So, Java users on macOS 14 running on Apple silicon systems should skip macOS 14.4 and update directly to macOS 14.4.1. More details can be found on https://blogs.oracle.com/java/post/java-on-macos-14-4 ## JDK 23 Early-Access Builds The JDK 23 EA builds 16 are available [10], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes [11] are also available. ### Changes in recent JDK 23 builds that may be of interest: - JDK-8324774: Add DejaVu web fonts (reported by AssertJ) - JDK-8327385: Add JavaDoc option to exclude web fonts from generated documentation (reported by AssertJ) - JDK-8328638: Fallback option for POST-only OCSP requests - JDK-8320362: Load anchor certificates from Keychain keystore - JDK-8327875: ChoiceFormat should advise throwing UnsupportedOperationException for unused methods - JDK-8296244: Alternate implementation of user-based authorization Subject APIs that doesn’t depend on Security Manager APIs - JDK-8327818: Implement Kerberos debug with sun.security.util.Debug - JDK-7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream - JDK-8319251: Change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT - JDK-8327651: Rename DictionaryEntry members related to protection domain - JDK-8321408: Add Certainly roots R1 and E1 - JDK-8164094: javadoc allows to create a @link to a non-existent method - JDK-8325496: Make TrimNativeHeapInterval a product switch - JDK-8174269: Remove COMPAT locale data provider from JDK - JDK-8322750: Test "api/java_awt/interactive/SystemTrayTests.html" failed because … - JDK-8139457: Relax alignment of array elements - JDK-8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly - JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError when pattern is empty string - JDK-8247972: incorrect implementation of JVM TI GetObjectMonitorUsage -
Release Ant 1.10.15?
Hello everyone, It's been around 6 months since our last Ant 1.10.x release. We have some reasonable amount of changes and bug fixes done since then https://github.com/apache/ant/blob/master/WHATSNEW#L1. If it's OK then I plan to do the next 1.10.x release in a few weeks, unless someone is working on anything that needs to be part of this release. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Retire the IvyDE Subproject
+1 for retiring IvyDE. -Jaikiran On 23/11/23 12:49 pm, Stefan Bodewig wrote: I'm really sorry and embarrassed but I seem to have misunderstood the purpose of the Attic, it is not responsible for retiring subprojects, only for top level projects like Ant as a whole with all subprojects. The correct process to follow is https://ant.apache.org/processes.html#Retire%20a%20subproject%20or%20component This is a new vote as I do not want to assume I could transfer the votes of a different vote and repurpose them. The actual vote: Following our own rules I propose zo retire IvyDE. Vote will be open for at lease 72 hours, will not end before 2023-11-26T07:30 UTC Sorry Stefan - 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
Re: [VOTE] Send IvyDE to the Apache Attic
On 19/11/23 11:09 pm, Stefan Bodewig wrote: ... So here is the formal vote: I hereby propose to create a board resolution that will send IvyDE to the Apache Attic. +1 -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: JDK 21 Is Now GA, a New VS Code Extension, and an Annotation Processing Heads-up
Hello David, I ran the Ant testsuite against Java 21 (build 21.0.1+12-29) and the tests all ran fine https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Linux%20(latest%20EA%20JDK)/41/. > Needless to say, that Java 21 is an important release, so may I ask you to send me a brief email with the Java 21 support status of your project(s): Already supported - Plan to support short-term - Don't plan to support short-term ? Ant 1.10.14 was released a few weeks before Java 21 was released. This version of Ant supports building projects using Java 21. After the release of Ant 1.10.14, I have heard one confirmed report that the usage of this Ant version has helped them build their project on Java 21. There have been no reports of any usage issues with Java 21 and Ant 1.10.14 so far. -Jaikiran On 20/10/23 3:05 pm, David Delabassee wrote: Greetings! JDK 21 has been released (General Availability) on September 19th as planned. You can find "The Arrival of Java 21" announcement here [1], and some additional Java 21 materials in the "Topics of Interest" section below. On behalf of the entire Java team, let me send our thanks to all of you. Through your active participation in this program, you are helping shape the Java platform! Needless to say, that Java 21 is an important release, so may I ask you to send me a brief email with the Java 21 support status of your project(s): Already supported - Plan to support short-term - Don't plan to support short-term ? And now that JDK 21 is out, let's shift our attention to JDK 22 which will enter the Rampdown Phase in less than 50 days on December 7 [2]. I want to conclude this update by briefly mentioning three different initiatives to are relevant to this group as they are, in their own way and at various levels, contributing to adopt newer Java releases more rapidly: the Class-File API, Oracle's Java Platform extension for VS Code, and the Java Playground. ### The Class-File API The Class-File API is a new standard API for parsing, generating, and transforming Java class files. One of its unique aspects is that it will co-evolve with the class-file format, which overtime will greatly reduce the friction of implementing new class-file features. With the fast-paced evolution of the Java platform, this was much-needed. This API should soon be previewed and as it matures, we expect the JDK to switch from using various custom class-file libraries to this standard API. We also expect that overtime frameworks relying on bytecode manipulation will also benefit from using this new JDK class-file library. For more information, please check this recent Newscast [3] for an overview, Brian Goetz's JVMLS session [4] for more details and design considerations, and JEP 457: Class-File API (Preview) [5] for the technical details. ### Oracle's Java Platform extension for Visual Studio Code Oracle has just announced [6] a new Visual Studio Code extension for Java developers. Unlike other VS Code extensions, this new extension is using under the hood the `javac` compiler for code editing and compilation, and OpenJDK's debugger interface for debugging. This enables us to offer VS Code IDE support for new JDK features as soon as they are introduced, even during JDK Early Access phases. To this effect, this VS Code Extension will support the current JDK releases as well as the next upcoming JDK version. For more information, please check the announcement [6]. ### The Java Playground The Java Playground [7] is an online sandbox that helps testing and exploring new Java language features. No setup required, just type your Java snippet in your browser and run it! Right now, the Playground is using Java 21 with Preview Features enabled, and it will switch to a new Java version as soon as there is a new Java language features integrated in OpenJDK Early-Access builds. The Playground is focusing mostly on Project Amber and is certainly not mean to be some sort of a lightweight online-IDE, it is instead a learning tool to play with new Java language feature shortly after they have been integrated into the platform. [1] https://inside.java/2023/09/19/the-arrival-of-java-21/ [2] https://mail.openjdk.org/pipermail/jdk-dev/2023-September/008269.html [3] https://www.youtube.com/watch?v=bQ2Rwpyj_Ks [4] https://www.youtube.com/watch?v=pcg-E_qyMOI [5] https://openjdk.org/jeps/457 [6] https://inside.java/2023/10/18/announcing-vscode-extension/ [7] https://dev.java/playground ## Heads-Up - JDK 22: Implicit Annotation Processing Behavior Change As discussed in the July 2023 Quality Outreach update [8], starting in JDK 21 javac emits a note if _implicit_ annotation processing is being used, that is, if one or more annotation processors are found and run from the class path when no explicit annotation processing configuration options are used. The note is reported since, quoting f
Re: [ANNOUNCE] Apache Ant 1.10.14 released
Hello ewh, no that wasn't intentional and was an oversight. It was reported recently and has been fixed in the master branch as part of https://bz.apache.org/bugzilla/show_bug.cgi?id=67417. -Jaikiran On 29/09/23 2:46 am, Earl Hood wrote: Ant Developers, Was it intended to keep code in ant.bat that does an initial execution of java.exe to check specification level regarding the setting of java.security.manager? I see the bourne shell script has no equivalent code. --ewh On Mon, Aug 21, 2023, 12:51 AM Jaikiran Pai wrote: The Apache Ant Team is pleased to announce the release of Apache Ant 1.10.14. ... - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Need help with release versions in bugzilla
Thank you Stefan. I probably didn't look correctly when trying to close a recent bug that got fixed. I see that the bug is now correctly fixed for 1.10.15. Thank you. -Jaikiran On 08/09/23 12:13 pm, Stefan Bodewig wrote: On 2023-09-08, Jaikiran Pai wrote: Can someone with admin permissions please mark 1.10.14 as a released version in Ant bugzilla and create a new 1.10.15 release in it? I think I've already done so when the release was published, let me check. Yes, I see them in the admin interface. Cheers Stefan - 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
Need help with release versions in bugzilla
Can someone with admin permissions please mark 1.10.14 as a released version in Ant bugzilla and create a new 1.10.15 release in it? I forgot to ask for help when I released 1.10.14. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Future of Ivy and IvyDE
I agree with what Stefan notes in his mail. Some years back when I started contributing to Ivy, I realized that the documentation (formal or informal) related to the internal implementation details of Ivy is non-existent. Sometimes I had to select a file, go over its commit history then go read all JIRAs that were part of those commit logs and even then, a lot of the information was either missing or outdated. At that time, I used to use Ivy in some of our projects, so I could keep refreshing with the code base and relate to it, so that whenever I had to fix a bug or add something, I had the previous collected knowledge of the Ivy code already fresh (to some extent) in my mind. It's now been some years since I have used Ivy and I no longer have the Ivy codebase knowledge in my mind. Like Stefan noted, these recent vulnerability fixes took the Ant team a lot of time and energy to fix because of these issues. Personally, I don't expect myself to have the ability to continue contributing to Ivy. As for IvyDE, on the development front, it has seen no movement. I am not even sure if it builds with the current Eclipse versions. I hadn't contributed to it, but I remember that when releasing Ivy 2.5.0, it was struggle to update the IvyDE update site. -Jaikiran On 22/08/23 9:32 pm, Stefan Bodewig wrote: Hi all before I get to the actual content of this mail: * I'm cross-posting to three lists but I ask you to keep responses to dev@ant only (and join the list if necessary) if you want to respond. * what I write is my personal opinion and not shared by the PMC as a whole. The people on the PMC know I'd be writing a mail like this sooner or later, though. * this is a discussion, not a vote. phew I'm not quite sure what I hope to achieve with this email, but I'd like to share my thoughts - and raise the awareness of an elephant being in the room. Over the past year we've had three security vulnerabilities discovered in Ivy and it took us much too long to get them fixed. The reason for this is there are no people left around who are familiar with the Ivy code base. Most of the remaining developers around Ant are not even users of Ivy - I know I am not and have never been. When it comes to IvyDE things are probably even worse as nobody of us uses Eclipse, either. But then again I've not managed to create an Eclipse update site for the last two Ivy releases so maybe nobody is using IvyDE anymore anyway. At least *I* don't see myself digging deeper into the Ivy code base in order to fix non-critical bugs. And even for the critical ones I feel we are not doing an adequate job. To me it looks as if Ivy and in particilar IvyDE are no longer really supported by the Ant project. TBH I'm not quite sure what to do about this. Even if people stepped up to maintain Ivy, the rest of the Ant devs would probably be unable to verify the changes they want to make. At least I certainly am not willing to review bigger PRs/patches to a code base I don't understand well. Personally I believe we should send IvyDE to the Apache Attic immediately, and this likely should be the destination for Ivy sooner or later as well. In the case of Ivy we know there are people who depend on it (hi, Groovy folks) so maybe we should give a date in the future until which we are providing security bug fixes to give people time to move off. There may be the need for a dependency management system inside of Ant, I'm not sure. If so, then this should be driven by people who feel the actual need IMO. There may already be alternatives to Ivy I am not aware of. Stefan - 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
[RESULT] Release Apache Ant 1.10.14 based on RC1
With (binding) +1s for Stefan, Maarten, me and Paul (non-binding), this vote has now passed. I'll now go ahead with the rest of the release process. Thank you all for the help in moving this release forward. -Jaikiran On 16/08/23 6:05 pm, Jaikiran Pai wrote: Hello everyone, I've created RC1 release candidate for Ant 1.10.14 release: git tag: ANT_1.10.14_RC1 on commit: 53f19eccf49acf526415997046dca5a5135b0e8f tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 63474 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1057 Apart from regular bug fixes, this 1.10.14 release has crucial changes around Ant's usage of Java SecurityManager. Many of you will be aware that Java 17 deprecated (for removal) the use of SecurityManager. Java 18 then disallowed setting SecurityManager at runtime, by default. Ant internally sets a SecurityManager at runtime to prevent System.exit() calls from within tasks, from killing the JVM in which Ant process is running. In Ant 1.10.13, we tried to keep using the SecurityManager internally for a few more releases in Ant, to facilitate projects to use Ant without requiring (major) changes to their build. The workarounds we put in place in Ant 1.10.13 were brittle and complex and although we had hoped they won't break user builds, they did end up breaking several builds. Ultimately, these workarounds for usage of SecurityManager are no longer feasible or adding value. As such, this 1.10.14 release of Ant will no longer use (or set) Java SecurityManager when running on Java versions 18 and higher. This has implications for projects using Ant. Specifically, if any of the build tasks (for example the "", "" or "" tasks) or libraries used in those tasks are calling System.exit() or Runtime.exit() and aren't forking a new JVM, then when running on Java 18 and higher, they may notice that the Ant JVM process gets killed. Such builds are recommended to either not call System.exit()/Runtime.exit() or use the "fork=true" option in relevant tasks (wherever appropriate). Furthermore, the usage of "" type when running on Java 18 and higher is no longer supported. More details are available in the manual of that type https://dist.apache.org/repos/dist/dev/ant/manual/. The complete set of changes in this release are noted in https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.14.html. Please do give this proposed release version a try against whichever Java runtime versions you plan to use it against (this version requires a minimum of Java 8 runtime, like any other Ant 1.10.x versions). Even if you don't vote, if you do run into issues, please report back - it takes time to create Ant releases, so catching any blocker issues (like some of which we saw after Ant 1.10.13 was released) early will help fix them sooner. This vote will be open for at least 72 hours and close no earlier than 19th August 2023 12 PM. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Ivy 2.5.2 Based on RC2
+1 Downloaded the RC2 of 2.5.2 and built some projects, checked some manuals and docs and the checksum. -Jaikiran On 17/08/23 10:22 pm, Stefan Bodewig wrote: Hi all I've cancelled the previous vote as the NOTICE file didn't contain 2023. sorry about this. Now I've built a new release candidate for Ivy 2.5.2 Changelog: - FIX: ivy:retrieve could fail because of a `NullPointerException` (IVY-1641) - FIX: reading POMs may loose dependencies when multiple Maven dependencies only differ in `classifier` (IVY-1642) - IMPROVEMENT: Upgrade Apache HttpClient to 4.5.13 (IVY-1644) The release artifacts can be found at https://dist.apache.org/repos/dist/dev/ant/ivy/ (svn revision 63486) Maven Repo is https://repository.apache.org/content/repositories/orgapacheant-1061/org/apache/ivy/ivy/2.5.2/ Again I have not built the update site, but we never did for 2.5.1 either and it never bothered anybody. Do you vote for the release of these binaries? [ ] Yes [ ] No This vote will be open for 72 hours as usual, I'll close it on 2023-08-20 17:00 UTC. Thanks Stefan - To unsubscribe, e-mail: user-unsubscr...@ant.apache.org For additional commands, e-mail: user-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Apache Ant 1.10.14 based on RC1
+1 - Downloaded the newer version and checked the NOTICE file - verified the checksum - Built some projects using this newer version, on Java 8, 17 and 20 - Checked manual docs for some of the tasks -Jaikiran On 16/08/23 6:05 pm, Jaikiran Pai wrote: Hello everyone, I've created RC1 release candidate for Ant 1.10.14 release: git tag: ANT_1.10.14_RC1 on commit: 53f19eccf49acf526415997046dca5a5135b0e8f tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 63474 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1057 Apart from regular bug fixes, this 1.10.14 release has crucial changes around Ant's usage of Java SecurityManager. Many of you will be aware that Java 17 deprecated (for removal) the use of SecurityManager. Java 18 then disallowed setting SecurityManager at runtime, by default. Ant internally sets a SecurityManager at runtime to prevent System.exit() calls from within tasks, from killing the JVM in which Ant process is running. In Ant 1.10.13, we tried to keep using the SecurityManager internally for a few more releases in Ant, to facilitate projects to use Ant without requiring (major) changes to their build. The workarounds we put in place in Ant 1.10.13 were brittle and complex and although we had hoped they won't break user builds, they did end up breaking several builds. Ultimately, these workarounds for usage of SecurityManager are no longer feasible or adding value. As such, this 1.10.14 release of Ant will no longer use (or set) Java SecurityManager when running on Java versions 18 and higher. This has implications for projects using Ant. Specifically, if any of the build tasks (for example the "", "" or "" tasks) or libraries used in those tasks are calling System.exit() or Runtime.exit() and aren't forking a new JVM, then when running on Java 18 and higher, they may notice that the Ant JVM process gets killed. Such builds are recommended to either not call System.exit()/Runtime.exit() or use the "fork=true" option in relevant tasks (wherever appropriate). Furthermore, the usage of "" type when running on Java 18 and higher is no longer supported. More details are available in the manual of that type https://dist.apache.org/repos/dist/dev/ant/manual/. The complete set of changes in this release are noted in https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.14.html. Please do give this proposed release version a try against whichever Java runtime versions you plan to use it against (this version requires a minimum of Java 8 runtime, like any other Ant 1.10.x versions). Even if you don't vote, if you do run into issues, please report back - it takes time to create Ant releases, so catching any blocker issues (like some of which we saw after Ant 1.10.13 was released) early will help fix them sooner. This vote will be open for at least 72 hours and close no earlier than 19th August 2023 12 PM. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Ivy 2.5.2 Based on RC1
On 17/08/23 10:02 am, Stefan Bodewig wrote: I have not built the update site because I couldn't get the build process to work, so if anybody with the proper build environment wants to create one, thank you. I'm sure we can create it after the release if we want to. Is this the Eclipse update site? From what I remember that requires an Eclipse installation locally, that too a very specific version. Unfortunately, it's been an extremely long time since I ever used Eclipse and I don't even have the setup I used many years back when releasing Ivy. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Ivy 2.5.2 Based on RC1
Hello Stefan, +1. The NOTICE file however will need an update to the year (it's currently having 2022). - Downloaded from https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.2/ - Verified the checksum - Checked the NOTICE file (needs an update to the year) - Checked some random manuals - Checked the ivy jar usage with Java 8 and Java 20 - Ran some trivial projects using this new version of Ivy -Jaikiran On 17/08/23 10:02 am, Stefan Bodewig wrote: Hi all I've built a release candidate for Ivy 2.5.2 Changelog: - FIX: ivy:retrieve could fail because of a `NullPointerException` (IVY-1641) - FIX: reading POMs may loose dependencies when multiple Maven dependencies only differ in `classifier` (IVY-1642) - IMPROVEMENT: Upgrade Apache HttpClient to 4.5.13 (IVY-1644) The release artifacts can be found at https://dist.apache.org/repos/dist/dev/ant/ivy/ (svn revision 63477) Maven Repo is https://repository.apache.org/content/repositories/orgapacheant-1060/org/apache/ivy/ivy/2.5.2/ I have not built the update site because I couldn't get the build process to work, so if anybody with the proper build environment wants to create one, thank you. I'm sure we can create it after the release if we want to. Do you vote for the release of these binaries? [ ] Yes [ ] No This vote will be open for 72 hours as usual, I'll close it on 2023-08-20 4:30 UTC. Thanks Stefan - 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
Re: [VOTE] Release Apache Ant 1.10.14 based on RC1
Hello Gary, Yes, that allow.class which was introduced in 1.10.13 is no longer part of Ant 1.10.14. I think, as you note, adding it to the release notes sounds like the right thing, since a couple of projects had specifically run into issue with that class. I'll update the release note after the voting completes (won't create a new RC for that). -Jaikiran On 16/08/23 6:42 pm, Gary Gregory wrote: (AFK) Does this remove the class file in the root of the ant-launcher jar which caused JPMS issues? If so, it might be worth mentioning in the release noyes. Gary ____ From: Jaikiran Pai Sent: Wednesday, August 16, 2023 8:35:22 AM To: u...@ant.apache.org ; dev@ant.apache.org Subject: [VOTE] Release Apache Ant 1.10.14 based on RC1 EXTERNAL EMAIL Hello everyone, I've created RC1 release candidate for Ant 1.10.14 release: git tag: ANT_1.10.14_RC1 on commit: 53f19eccf49acf526415997046dca5a5135b0e8f tarballs: https://dist.apache.org/repos/dist/dev/ant/<https://dist.apache.org/repos/dist/dev/ant> revision: 63474 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1057<https://repository.apache.org/content/repositories/orgapacheant-1057> Apart from regular bug fixes, this 1.10.14 release has crucial changes around Ant's usage of Java SecurityManager. Many of you will be aware that Java 17 deprecated (for removal) the use of SecurityManager. Java 18 then disallowed setting SecurityManager at runtime, by default. Ant internally sets a SecurityManager at runtime to prevent System.exit() calls from within tasks, from killing the JVM in which Ant process is running. In Ant 1.10.13, we tried to keep using the SecurityManager internally for a few more releases in Ant, to facilitate projects to use Ant without requiring (major) changes to their build. The workarounds we put in place in Ant 1.10.13 were brittle and complex and although we had hoped they won't break user builds, they did end up breaking several builds. Ultimately, these workarounds for usage of SecurityManager are no longer feasible or adding value. As such, this 1.10.14 release of Ant will no longer use (or set) Java SecurityManager when running on Java versions 18 and higher. This has implications for projects using Ant. Specifically, if any of the build tasks (for example the "", "" or "" tasks) or libraries used in those tasks are calling System.exit() or Runtime.exit() and aren't forking a new JVM, then when running on Java 18 and higher, they may notice that the Ant JVM process gets killed. Such builds are recommended to either not call System.exit()/Runtime.exit() or use the "fork=true" option in relevant tasks (wherever appropriate). Furthermore, the usage of "" type when running on Java 18 and higher is no longer supported. More details are available in the manual of that type https://dist.apache.org/repos/dist/dev/ant/manual/<https://dist.apache.org/repos/dist/dev/ant/manual>. The complete set of changes in this release are noted in https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.14.html<https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.14.html>. Please do give this proposed release version a try against whichever Java runtime versions you plan to use it against (this version requires a minimum of Java 8 runtime, like any other Ant 1.10.x versions). Even if you don't vote, if you do run into issues, please report back - it takes time to create Ant releases, so catching any blocker issues (like some of which we saw after Ant 1.10.13 was released) early will help fix them sooner. This vote will be open for at least 72 hours and close no earlier than 19th August 2023 12 PM. -Jaikiran - To unsubscribe, e-mail: user-unsubscr...@ant.apache.org For additional commands, e-mail: user-h...@ant.apache.org Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[VOTE] Release Apache Ant 1.10.14 based on RC1
Hello everyone, I've created RC1 release candidate for Ant 1.10.14 release: git tag: ANT_1.10.14_RC1 on commit: 53f19eccf49acf526415997046dca5a5135b0e8f tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 63474 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1057 Apart from regular bug fixes, this 1.10.14 release has crucial changes around Ant's usage of Java SecurityManager. Many of you will be aware that Java 17 deprecated (for removal) the use of SecurityManager. Java 18 then disallowed setting SecurityManager at runtime, by default. Ant internally sets a SecurityManager at runtime to prevent System.exit() calls from within tasks, from killing the JVM in which Ant process is running. In Ant 1.10.13, we tried to keep using the SecurityManager internally for a few more releases in Ant, to facilitate projects to use Ant without requiring (major) changes to their build. The workarounds we put in place in Ant 1.10.13 were brittle and complex and although we had hoped they won't break user builds, they did end up breaking several builds. Ultimately, these workarounds for usage of SecurityManager are no longer feasible or adding value. As such, this 1.10.14 release of Ant will no longer use (or set) Java SecurityManager when running on Java versions 18 and higher. This has implications for projects using Ant. Specifically, if any of the build tasks (for example the "", "" or "" tasks) or libraries used in those tasks are calling System.exit() or Runtime.exit() and aren't forking a new JVM, then when running on Java 18 and higher, they may notice that the Ant JVM process gets killed. Such builds are recommended to either not call System.exit()/Runtime.exit() or use the "fork=true" option in relevant tasks (wherever appropriate). Furthermore, the usage of "" type when running on Java 18 and higher is no longer supported. More details are available in the manual of that type https://dist.apache.org/repos/dist/dev/ant/manual/. The complete set of changes in this release are noted in https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.14.html. Please do give this proposed release version a try against whichever Java runtime versions you plan to use it against (this version requires a minimum of Java 8 runtime, like any other Ant 1.10.x versions). Even if you don't vote, if you do run into issues, please report back - it takes time to create Ant releases, so catching any blocker issues (like some of which we saw after Ant 1.10.13 was released) early will help fix them sooner. This vote will be open for at least 72 hours and close no earlier than 19th August 2023 12 PM. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Release Ivy 2.5.2
Sounds good to me. -Jaikiran On 13/08/23 4:45 pm, Stefan Bodewig wrote: Hi all while Jaikiran talks about release Ant, I intend to cut a new Ivy release soonish. We've seen two bug fixes to Ivy <https://issues.apache.org/jira/projects/IVY/versions/12353013> and I believe IVY-1642 shows a serious incompatibility with Ivy. Cheers Stefan - 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
Release Ant 1.10.14?
We have a decent amount of fixes and changes since we released Ant 1.10.13 https://github.com/apache/ant/blob/master/WHATSNEW. Plus, Ant 1.10.13 broke some setups due to our changes to SecurityManager related usage. I recently reverted those SecurityManager related changes and have now pushed some commits which will no longer use SecurityManager when Ant is running in Java 18+ runtime environments. I would like to have these changes released so that there will be some amount of testing by actual projects, in context of our SecurityManager changes. If there are no objections then I'll send out a formal vote mail for the 1.10.14 release, this coming week. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: JDK 22 is in Rampdown Phase 2 | Annotation Processing Change Heads-up
Hello David, I ran the Ant testsuite against JDK 21 EA build 21-ea+34-2500 and the tests ran fine https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Linux%20(latest%20EA%20JDK)/37/. The 22 EA build 22-ea+9-633 tests too ran fine https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Linux%20(latest%20EA%20JDK)/38/ -Jaikiran On 28/07/23 2:53 pm, David Delabassee wrote: Welcome to the OpenJDK Quality Outreach summer update. JDK 21 is now in Rampdown Phase Two [1], its overall feature has been frozen a few weeks ago. Per the JDK Release Process [2] we have now turned our focus to P1 and P2 bugs, which can be fixed with approval [3]. Late enhancements are still possible, with approval, but the bar is now extraordinarily high [4]. That also means that the JDK 21 Initial Release Candidates are fast approaching, i.e., August 10 [5]. So, and in addition to testing your projects with the latest JDK 21 early-access builds, it is now also a good time to start testing with the JDK 22 early-access builds. [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-July/008034.html [2] https://openjdk.org/jeps/3 [3] https://openjdk.org/jeps/3#Fix-Request-Process [4] https://openjdk.org/jeps/3#Late-Enhancement-Request-Process [5] https://openjdk.org/projects/jdk/21/ ## Heads-up - JDK 21 & JDK 22: Note if implicit annotation processing is being used Annotation processing by javac is enabled by default, including when no annotation processing configuration options are present. We are considering disabling implicit annotation processing by default in a future release, possibly as early as JDK 22 [6]. To alert javac users of this possibility, as of JDK 21 b29 and JDK 22 b04, javac prints a note if implicit annotation processing is being used [7]. The reported note is: Annotation processing is enabled because one or more processors were found on the class path. A future release of javac may disable annotation processing unless at least one processor is specified by name (-processor), or a search path is specified (--processor-path, --processor-module-path), or annotation processing is enabled explicitly (-proc:only, -proc:full). Use -Xlint:-options to suppress this message. Use -proc:none to disable annotation processing. Good build hygiene includes explicitly configuring annotation processing. To ease the transition to a different default policy in the future, the new-in-JDK-21 `-proc:full` javac option requests the current default behavior of looking for annotation processors on the class path. [6] https://bugs.openjdk.org/browse/JDK-8306819 [7] https://bugs.openjdk.org/browse/JDK-8310061 ## Heads-up - JDK 22: JLine is now the Default Console Provider In JDK 22, `System.console()` has been changed [8] to return a `Console` with enhanced editing features that improve the experience of programs that use the `Console` API. In addition, `System.console()` now returns a `Console` object when the standard streams are redirected or connected to a virtual terminal. Prior to JDK 22, `System.console()` instead returned `null` for these cases. This change may impact code that checks the return from `System.console()` to test if the JVM is connected to a terminal. If required, the `-Djdk.console=java.base` flag will restore the old behavior where the console is only returned when it is connected to a terminal. Starting JDK 22, one could also use the new `Console.isTerminal()` method to test if the console is connected to a terminal. [8] https://bugs.openjdk.org/browse/JDK-8308591 ## JDK 21 Early-Access Builds The JDK 21 early-access builds 33 are available [9], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [10] and the Javadoc here [11]. [9] https://jdk.java.net/21/ [10] https://jdk.java.net/21/release-notes [11] https://download.java.net/java/early_access/jdk21/docs/api/ ## JDK 22 Early-Access Builds The JDK 22 early-access builds 8 are available [12], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [13]. [12] https://openjdk.org/projects/jdk/22 [13] https://jdk.java.net/22/release-notes ### Changes in recent JDK 22 builds (b2-b8) that may be of interest: Note that this is only a curated list of changes, make sure to check [14] for additional changes. - JDK-8309882: LinkedHashMap adds an errant serializable field [Reported by Eclipse Collections] - JDK-8312366: [arm32] Build crashes after JDK-8310233 [Reported by JaCoCo] - JDK-8167252: Some of Charset.availableCharsets() does not contain itself [Reported by IntelliJ] - JDK-8310061: Note if implicit annotation processing is being used - JDK-8308591: JLine as the default Console provider - JDK-8312019: Simplify and modernize java.util.BitSet.equals - JDK-8308593: Add KEEPALIVE Extended Socket Options Support for Windows -
Re: How to use custom .ivy2 directory
Hello Yuri, There's a section in https://ant.apache.org/ivy/history/2.5.1/tutorial/defaultconf.html called "Setting up the repositories" which explains the use of the ivy.default.ivy.user.dir property which controls this location. -Jaikiran On 07/08/23 1:42 pm, Yuri wrote: One project (lightzone) fails to build in a VM with this error: > java.io.FileNotFoundException: /nonexistent/.ivy2/cache/resolved-lightcrafts-lightcrafts-work...@localhost.xml (No such file or directory) This is because the user in the VM doesn't have a home directory. How to use another directory? Setting the HOME environment variable doesn't help. Thanks, Yuri - 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
Re: JDK 21 EA builds 22 & Sequenced Collections Heads-up
Hello David, I ran the Ant testsuite against Java 21 EA build 21-ea+22-1890 and all tests went fine without any failures https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Linux%20(latest%20EA%20JDK)/35/ -Jaikiran On 15/05/23 8:08 pm, David Delabassee wrote: Welcome to the latest OpenJDK Quality Outreach update! The proposed schedule for JDK 21 is now known [1] with Rampdown Phase One (RDP1) phase set for June 8th and General Availability (GA) set for September 19th. As we are getting closer to RDP1, we are gradually getting a better view on the JDK 21 content. At the time of writing, 5 JEPs are already integrated in the JDK 21 mainline - Virtual Threads, Generational ZGC, etc. – see below for more details. This newsletter heads-up is focused on one of those JEPs; i.e., JEP 431 Sequenced Collections, as it might induce some incompatibilities on existing codebases. Please do tell us if your project works or fails on the latest JDK 21 Early-Access builds. We still have some time to fix issues before JDK 21 reaches General Availability. [1] https://openjdk.org/projects/jdk/21/ ## Heads-Up - JDK 21: Potential Sequenced Collections Incompatibilities The Sequenced Collection JEP [2] has been integrated into JDK 21, build 20. This JEP introduces several new interfaces into the collections framework’s interface hierarchy, and these interfaces introduce new default methods. When such changes are made, they can cause conflicts that result in source or binary incompatibilities. Any conflicts that occur will be in code that implements new collections or that subclasses existing collection classes. Code that simply uses collections implementations will be largely unaffected. There are several kinds of conflicts that might arise. The first is a simple method naming conflict, if a method already exists with the same name but with a different return type or access modifier. Another is a clash between different inherited default method implementations arising from covariant overrides. A class might inherit multiple default methods if it implements multiple interfaces from different parts of the collections framework. A third example occurs with type inference. With type inference (e.g., the use of `var`) the compiler will infer a type for that local variable. It’s possible for other code to use explicitly declared types that must match the inferred type. The change to the interface hierarchy might result in a different inferred type, causing an incompatibility. Make sure to check the following article [3] that provides additional details and strategies to mitigate potential incompatibilities. [2] https://openjdk.org/jeps/431 [3] https://inside.java/2023/05/12/quality-heads-up/ Additional Sequenced Collections resources are also listed in the 'Topics of Interest' section below. ## JDK 21 Early-Access builds The latest Early-Access builds 22 are available [4], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes [5] and the Javadocs [6] are also available. [4] https://jdk.java.net/21/ [5] https://jdk.java.net/21/release-notes [6] https://download.java.net/java/early_access/jdk21/docs/api/ ### JEPs integrated to JDK 21, so far: - 430: String Templates (Preview) - 431: Sequenced Collections - 439: Generational ZGC - 442: Foreign Function & Memory API (3rd Preview) - 444: Virtual Threads ### JEPs targeted to JDK 21, so far: - 440: Record Patterns - 441: Pattern Matching for switch - 448: Vector API (6th Incubator) JEPs proposed to target JDK 21: - 404: Generational Shenandoah (Experimental) - 443: Unnamed Patterns and Variables (Preview) - 445: Unnamed Classes and Instance Main Methods (Preview) - 449: Deprecate the Windows 32-bit x86 Port for Removal ### Changes in recent builds that may be of interest: Note that this is only a curated list of changes, make sure to check https://github.com/openjdk/jdk/compare/jdk-21+0...jdk-21+22 for additional changes. JDK 21 Build 22: - JDK-8307466: java.time.Instant calculation bug in until and between methods - JDK-8307399: get rid of compatibility ThreadStart/ThreadEnd events for virtual threads - JDK-8306461: ObjectInputStream::readObject() should handle negative array sizes without throwing NegativeArraySizeExceptions - JDK-8280031: Deprecate GTK2 for removal - JDK-8307629: FunctionDescriptor::toMethodType should allow sequence layouts (mainline) - JDK-8302845: Replace finalizer usage in JNDI DNS provider with Cleaner - JDK-8306461: ObjectInputStream::readObject() should handle negative array sizes without throwing NegativeArraySizeExceptions - JDK-8306881: Update FreeType to 2.13.0 - JDK-8285932: Implementation of JEP 430 String Templates (Preview) - JDK-8307301: Update HarfBuzz to 7.2.0 - JDK-8159337: Introduce a method in Locale class to return the language tags as per RFC 5646 convention - JDK-8291555: Implement alternative fast-locking scheme - JD
Re: Release Ant 1.10.13?
Hello Paul, On 12/12/22 5:30 am, Paul King wrote: 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. The use of a "allow" class as a workaround to older versions of JDK considering this value as a classname for -Djava.security.manager system property, was always a brittle one. As such, Oracle JDK in its upcoming October CPU release is going to introduce a change which will treat the values "allow" and "disallow" specially (by ignoring them and not considering them as a classname) for the java.security.manager system property. This will be available in Oracle's 11, 8 and 7 releases and is being tracked in https://bugs.openjdk.org/browse/JDK-8301118. Hopefully other vendors too will bring in this change in their releases. What that will then mean is that, applications/users will no longer have to first detect the version of Java before deciding whether or not they can set the value "allow" for the java.security.manager system property (if at all they want to set that value). As a related note, after Ant 1.10.13 was released we have received reports that the "allow" workaround we introduced, has its own set of issues. It was always a temporary change in Ant to allow for this version of Ant to work against recent releases of Java. I'm in the process of undoing this "allow" workaround and then completing skipping setting of SecurityManager against recent versions of Java, in Ant. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Issues running tests on Gump after switching to Java 21
Hello Stefan, I had a brief look. Do you happen to know how these builds are launched in Gump? I have never used gump before, so I'm not familiar with it. Most of these failures in Ant build seem to be happening due to: [java] java.lang.UnsupportedOperationException: The Security Manager is deprecated and will be removed in a future release [java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:194) which can happen if java wasn't launched using -Dsecurity.manager=allow -Jaikiran On 14/05/23 4:28 pm, Stefan Bodewig wrote: Hi all Mark has upgraded Gump to Java21 and it seems running tests with Ant is somehow broken.http://vmgump.apache.org/project_todos.html I haven't looked into the details myself, yet, just wanted to point out the issues. Stefan - To unsubscribe, e-mail:dev-unsubscr...@ant.apache.org For additional commands, e-mail:dev-h...@ant.apache.org
Re: JDK 20 Release Candidate and Deprecation
Hello David, I ran the Ant testsuite against Java 20 build 20+36-2344 and Java 21 EA build 21-ea+11-905. No regressions were found: https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Linux%20(latest%20EA%20JDK)/33/ https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Linux%20(latest%20EA%20JDK)/34/ -Jaikiran On 15/02/23 10:54 am, David Delabassee wrote: Welcome to the latest OpenJDK Quality Outreach update! The first Release Candidates of JDK 20 have been released [1] as per the schedule [2]. At this stage, only P1 issues will be evaluated. And with the JDK 20 General Availability sets for March 21st, it is now time to fully focus on JDK 21. I'd like to thank those of you who have already provided feedback on the Early Builds of JDK 21. Feedback is always extremely useful, even more, when it comes early in the development cycle. We are always thinking about the future but the future is not limited to new features (pun intended). Properly removing legacy features from the platform is also critical. Deprecation has always been an important, phased, and ongoing effort. To name just two recent examples, `Thread.stop()` is removed in JDK 20 [3], and the URL Public Constructors are deprecated in JDK 20 (see the related heads-up below). It is important to prepare your codebase for such upcoming evolutions sooner rather than later. To conclude on deprecation, I'll mention my colleague Nicolai who recently did a full video on this exact topic, i.e. "Prepare your Codebase for the Future Now!" [4]. [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-February/007364.html [2] https://openjdk.org/projects/jdk/20/ [3] https://inside.java/2022/11/09/quality-heads-up/ [4] https://inside.java/2023/02/02/newscast-41/ ## Heads-Up - JDK 20 - Deprecate URL Public Constructors The `java.net.URL` class, dating from Java SE 1.0, does not encode or decode any URL components according to the RFC2396 escaping mechanism. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields that are returned from URL. This has led to many usability issues, including some potential vulnerabilities when the calling code did not take this into consideration. In Java SE 1.4, the `java.net.URI` class has been added to mitigate some of the `java.net.URL` shortcomings. It also offers methods to create an URL from an URI. JDK 20 will deprecate all public constructors of `java.net.URL`. This will provide a strong warning and discourage developers from using them. To construct a URL, the `URI::toURL` alternative should instead be preferred. To construct a `file:` based URL, `Path::toURI` should be used prior to `URI::toURL`. For more details, see https://bugs.openjdk.org/browse/JDK-8294241 ## Heads-Up - JDK 20 - JMX Connections Use an ObjectInputFilter by Default The default JMX agent now sets an ObjectInputFilter on the RMI connection to restrict the types that the server will deserialize. This should not affect normal usage of the MBeans in the JDK. Applications which register their own MBeans in the platform MBeanServer may need to extend the serialization filter to support any additional types that their custom MBeans accept as parameters. The default filter already covers any type that OpenMBeans and MXBeans might use. The serialization filter pattern is set in `JDK/conf/management/management.properties` using the property `com.sun.management.jmxremote.serial.filter.pattern`. If additional Java types need to be passed, the default can be overridden by running with `-Dcom.sun.management.jmxremote.serial.filter.pattern=.` Serialization Filtering and the filter pattern format are described in detail in the Core Libraries Guide [5]. [5] https://docs.oracle.com/en/java/javase/19/core/serialization-filtering1.html#GUID-55BABE96-3048-4A9F-A7E6-781790FF3480 ## Heads-Up - Testing Loom: Scoped Values and Structured Concurrency With one JEP in Preview (Virtual Threads - 2nd Preview) and two JEPs incubating (Scoped Values - Incubator & Structured Concurrency - 2nd Incubator) Loom made considerable progress in JDK 20. The Loom team is always eager to hear from developers experimenting with those APIs, especially given that both Scoped Values and Structured Concurrency might become Preview in JDK 21. Feedback should be reported to the loom-dev [6] mailing list. [6] https://mail.openjdk.org/pipermail/loom-dev/ ## JDK 20 Release Candidate builds The Release Candidate builds (builds 36) are available [7] and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [8]. [7] https://jdk.java.net/20/ [8] https://jdk.java.net/20/release-notes ### Changes in recent JDK 20 builds that may be of interest: - JDK-8300623: Lambda deserialization regression involving Enum method reference - JDK
Re: Need help with Ant versions in bugzilla
Thank you Stefan. I didn't check before sending this mail :) -Jaikiran On 10/01/23 7:16 pm, Stefan Bodewig wrote: On 2023-01-10, Jaikiran Pai wrote: Now that we have released 1.10.13 of Ant, could someone with bugzilla access please create a new 1.10.13 product version and a new 1.10.14 milestone version, for Ant? I have already done so when you closed the vote :-) Stefan - 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
Need help with Ant versions in bugzilla
Now that we have released 1.10.13 of Ant, could someone with bugzilla access please create a new 1.10.13 product version and a new 1.10.14 milestone version, for Ant? -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[ANNOUNCE] Apache Ant 1.10.13 released
The Apache Ant Team is pleased to announce the release of Apache Ant 1.10.13. Apache Ant is a Java library and command-line tool that helps building software. The Apache Ant team currently maintains two lines of development. The 1.9.x releases require Java 5 at runtime and 1.10.x requires Java 8 at runtime. Both lines are based off of Ant 1.9.7 and the 1.9.x releases are mostly bug fix releases while additional new features are developed for 1.10.x. We recommend using 1.10.13 unless you are required to use versions of Java prior to Java 8 during the build process. Ant 1.10.13 is mostly a bug fix release, but does contain one important change - Java versions starting Java 18, by default, no longer allow SecurityManager to be set at runtime. Ant (internally) does set SecurityManager at runtime. This caused problems for projects that wanted to build their projects using Ant against Java 18 or higher. This newly released Ant 1.10.13 version fixes that issue (internally) and thus should allow projects to use this version of Ant to build against Java 18 or higher. Binary and source distributions are available for download from the Apache Ant download site: https://ant.apache.org/bindownload.cgi https://ant.apache.org/srcdownload.cgi When downloading, please verify signatures using the KEYS file available at the above location. Changes in 1.10.13 are as follows: Changes that could break older environments: --- * has a new attribute authenticateOnRedirect that can be used to prevent Ant from sending the configured credentials when following a redirect. It is false by default, which means builds that rely on credentials being used on the redirected URI may break. Github Pull Request #173 Fixed bugs: --- * the PropertyEnumerator change introduced in 1.10.9 proved to be not fully backwards compatible when combined with certain custom PropertyHelper implementations - for example when using AntXtras. Bugzilla Report 65799 * legacy-xml reporter of the junitlauncher task now escapes ]]> when writing CDATA. Bugzilla Report 65833 * may leak connections when trying to preserve the last modified timestamps of files transferred recursively from a server. Bugzilla Report 66001 * tstamp task would in certain cases parse the SOURCE_DATE_EPOCH environment variable value to an incorrect date. This has now been fixed. Github Pull Request #186 * fetch.xml didn't set up non-default repositories propery and thus failed to download JAI. Github Pull Request #191 * When building and installing Ant distribution from source, the build script would change permissions on unrelated files in the destination directory. This is now fixed and such unrelated files in the destination directory will be left untouched. Bugzilla Report 66164 * parsing tar entries with multiple NUL bytes in their name would include garbage bytes as the name included all bytes up to the last NUL rather than the first. Github Pull Request #194 * loadresource might log warnings even though quiet was set to true Bugzilla Report 65647 * javac task would add paths constructs containing wildcards to the internally created argument file where wildcards are not allowed Bugzilla Report 65621 Other changes: -- * added an implementation of the MIME Mail sender based on the repackaged Jakarta Mail package rather than javax Mail. Github Pull Request #161 * The "listener" element in the junitlauncher task now supports an "extension" attribute to control the filename extension of the generated output file from the listener. Github Pull Request #168 * now supports FTPs. Github Pull Request #170 * DirectoryScanner avoids listing directory contents when it known it will never use the information retrieved. This may improve performance in some special cases. Bugzilla Report 66048 * will now create the parent directory of the manifestFile attribute if it doesn't exist. Bugzilla Report 66231 * org.apache.tools.ant.BuildLogger now has a new method getMessageOutputLevel() which returns the currently set message output level. As usual, for asking help or reporting any issues, please continue to communicate with us on our user mailing list https://ant.apache.org/mail.html. -Jaikiran (on behalf of Apache Ant team) - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Apache Ant 1.10.13 based on RC1
Thank you everyone for testing this release and voting on it. With +1s from Stefan, me and Martijn, this release voting has now passed. I'll now move ahead with the rest of the release process. -Jaikiran On 10/01/23 12:47 am, Martijn Kruithof wrote: +1 checked diff to of indicated commit to rel/1.10.12 Martijn Op 09/01/2023 om 02:30 schreef Jaikiran Pai: +1 Tried the new version to build some existing projects - worked fine Checked NOTICE file and some random manual docs - looks fine -Jaikiran On 06/01/23 4:57 pm, Stefan Bodewig wrote: On 2023-01-04, Jaikiran Pai wrote: Happy new year, everyone :) to you as well I've created RC1 release candidate for Ant 1.10.13 release: git tag: ANT_1.10.13_RC1 on commit: 6996b80b5fb59cc2769f7098d837de32680a tarballs: https://dist.apache.org/repos/dist/dev/ant/ +1 Stefan - 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 - 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
Re: [VOTE] Release Apache Ant 1.10.13 based on RC1
+1 Tried the new version to build some existing projects - worked fine Checked NOTICE file and some random manual docs - looks fine -Jaikiran On 06/01/23 4:57 pm, Stefan Bodewig wrote: On 2023-01-04, Jaikiran Pai wrote: Happy new year, everyone :) to you as well I've created RC1 release candidate for Ant 1.10.13 release: git tag: ANT_1.10.13_RC1 on commit: 6996b80b5fb59cc2769f7098d837de32680a tarballs: https://dist.apache.org/repos/dist/dev/ant/ +1 Stefan - 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
[VOTE] Release Apache Ant 1.10.13 based on RC1
Happy new year, everyone :) I've created RC1 release candidate for Ant 1.10.13 release: git tag: ANT_1.10.13_RC1 on commit: 6996b80b5fb59cc2769f7098d837de32680a tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 59117 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1056/ Apart from the regular bug fixes, this release includes better support for Java 18+ version. Starting Java 18, setting the SecurityManager at runtime (which Ant does by default) throws an exception. This relates to SecurityManager being deprecated for removal in future Java versions https://openjdk.org/jeps/411. This current proposed Ant release does certain necessary (internal) changes to prevent these exceptions from happening and thus allowing project builds to continue using Ant without any workarounds. Please give this release a try against various Java versions of your choice (starting Java 8) on the operating systems that you usually use to build your projects. The complete release notes is available at https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.13.html. This vote will be open for at least 72 hours and close no earlier than 7th January 2023 12 PM. -Jaikiran (on behalf of Apache Ant team) - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Release Ant 1.10.13?
Hello Stefan, On 26/11/22 11:33 pm, Stefan Bodewig wrote: On 2022-11-19, Stefan Bodewig wrote: while running all tests locally I realized https://github.com/apache/ant/pull/194 introduces a bug when tars have an encoding set. You can see this with UntarTest failing. A multibyte encoding like UTF16 may contain NUL bytes inside of the "normal" part of the name. I'll have to think about a way to solve this, but we should not release Ant with this regression. https://github.com/apache/ant/commit/e04fbe7ffa4f549bdc00bdfce688fb587120eedd fixes tthe problem, at least for our test. It makes parsing tar archives a bit slower, but that likely won't matter much for single-byte encodings (tar isn't meant to be used with multi-byte encodings). Also I don't think reading tars is what a normal build does for the majority of its time. Anyway, I'd appreciate a review of the code I've written there. What I wanted to do is to ask the encoding how it would represent a NUL and look search for that when finding the string terminator - as opposed to looking for a single NUL byte. Our testcase used UTF-16 BE with a BOM, so encoding "\0" ends up with two bytes BOM + 0x00 0x00 - while I really only wanted to 0x00 0x00. Next attempt was to encode an empty string to see whether there is a common prefix, but an empty string is encoded as 0 bytes, no BOM. :-) So finally I compared "X" to "X\0" and stripped what seems to be "X". I'm pretty sure this breaks for certain encodings, but not worse than it has worked before. And then I sprinkled some memoization on top. TBM I could also live with reverting the whole commit, saying "don't use multi-byte encodings in tars" and be done. The original test we had worked by accident, if the old test had used UTF16-LE instead and a 49 character file name it would have failed as we'd try to decode a byte array with an odd number of bytes. Finding A solution was a nice puzzle, but that doesn't mean we have to use it. I had a look at that commit and the PR discussion where the initial fix was made. I don't have enough knowledge of this area to provide relevant inputs, but from what you have explained here and in the PR and looking at the code it looks fine to me. You (and the original contributor) note that there are still issues that this change won't solve, but I think that is OK for now. I say that because the current state/fix addresses an actual issue that was reported[1]. I've verified that the current code in master with your changes does indeed allow extracting that .tar.gz fine (unlike Ant 1.10.12). Plus our testsuite continues to pass. So that's a good thing. [1] https://github.com/ibmruntimes/Semeru-Runtimes/issues/15 -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Release Ant 1.10.13?
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
Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19
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 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
Re: JDK 20 EAb22, ZenGC EA builds, JavaFX 20 EAb5 and several heads-ups!
Hello David, We have been a bit slow recently in running the Ant testsuite and responding to the EA releases. I found some time today and triggered a run against the latest JDK 20 EA available at https://jdk.java.net/20/ which is (build 20-ea+27-2213). That has exposed a new failure in the javadoc generation against the Ant project. I've filed https://bugs.openjdk.org/browse/JDK-8298525 with the details. -Jaikiran On 07/11/22 1:47 pm, David Delabassee wrote: Greetings, With JavaOne in Las Vegas, last month was epically busy! It was great to finally have the ability to meet and discuss the Quality Outreach program with some of you... face-to-face! This installment of the newsletter is packed as we have several heads-ups, including new Early-Access builds being made available. The JDK 20 schedule has been proposed [1]. The next major milestone is Rampdown Phase One which should happen in just a month on December 8! The next few weeks will be particularly interesting as we will see which from the candidate JEPs recently announced (see 'Topics of Interest' section below) will be proposed to target JDK 20 [2]. And given that JDK 20 is getting closer, we are eagerly waiting for your test feedback on your projects running with the latest JDK 20 EA builds. [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-October/007108.html [2] https://openjdk.org/projects/jdk/20/ ### Heads-up - JDK 20: `java.net.URL` parsing fix & behavior change Before JDK 20, some of the parsing/validation performed by the JDK built-in `URLStreamHander` implementations were delayed until `URL::openConnection` or `URLConnection::connect` was called. Starting JDK 20, some of these parsing/validations are now performed early, i.e. within URL constructors. An exception caused by a malformed URL that would have been delayed until the connection was opened or connected may starting JDK 20, throw a `MalformedURLException` at URL construction time. We suggest testing your project(s) against this change. And for those who want to rely on the old behavior, a new system property has been introduced to revert, on the command line, to the previous behavior. For more details, please see JBS-8293590 [3] and the release notes [4]. [3] https://bugs.openjdk.org/browse/JDK-8293590 [4] https://bugs.openjdk.org/browse/JDK-8295750 ### Heads-up - JDK 20: Thread.stop(), Thread.suspend() and Thread.resume() degradation The ability to stop, suspend, or resume a thread with the corresponding Thread.stop(), Thread.suspend() or Thread.resume() methods have been removed in JDK 20. Those methods have been degraded to throw a UOE exception (UnsupportedOperationException). Using those methods was inherently unsafe. That is also why they were deprecated since JDK 1.2 (1998!) and were flagged 'forRemoval' in previous features release. We do not expect this behavior change to cause any issues on well-maintained codebase. For more details please check JDK-8289610 [5], JDK-8249627 [6], and the Java Thread Primitive Deprecation FAQ [7]. [5] https://bugs.openjdk.org/browse/JDK-8289610 [6] https://bugs.openjdk.org/browse/JDK-8249627 [7] https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html ### Heads-up - JDK 20: Deprecate and disable the legacy parallel class loading workaround for non-parallel-capable class loaders. Prior to JDK 7, custom class loaders using non-hierarchical class delegation model were prone to deadlock. A workaround was added in the HotSpot VM (JDK 6) to allow parallel class loading for non-parallel-capable class loaders to avoid deadlocks. Parallel-capable class loaders were introduced in Java SE 7 [8] to support parallel class loading to implement a deadlock-free class loader using a non-hierarchical class delegation model. [8] and [9] describe how to migrate those class loaders depending on this workaround to be multi-threaded parallel-capable class loaders. This workaround was intended to allow those developers to migrate to the new mechanism. JDK 7 was released 11 years ago so it is now expected that those deadlock-prone custom class loaders have been migrated to the parallel-capable class loaders. As a consequence, this workaround is removed in JDK 20 as it impedes eliminating the object monitors from pinning for virtual threads. We suggest confirming that your codebase is not relying on this legacy workaround. If it still is, you should migrate away from it ASAP. Please note that the legacy behavior can be temporary re-enabled using a special flag. For additional details, please check [10] and [11]. [8] https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html [9] https://openjdk.org/groups/core-libs/ClassLoaderProposal.html [10] https://bugs.openjdk.org/browse/JDK-8295848 [11] https://bugs.openjdk.org/browse/JDK-8296446 ### Heads-up - JavaFX builds Oracle is
Re: Release Ant 1.10.13?
Hello Stefan, On 19/11/22 10:41 pm, Stefan Bodewig wrote: On 2022-11-18, Stefan Bodewig wrote: On my personal TODO list there are a few minor things like Java 20 removing another target option that we may want to tell users about. Nothing of this is critical AFAIR and shouldn't hold up a release if I don't get to them soon enough. I'm through with this BUT while running all tests locally I realized https://github.com/apache/ant/pull/194 introduces a bug when tars have an encoding set. You can see this with UntarTest failing. A multibyte encoding like UTF16 may contain NUL bytes inside of the "normal" part of the name. I'll have to think about a way to solve this, but we should not release Ant with this regression. Please take your time, I won't rush the release. I'm still experimenting with the security manager changes. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Release Ant 1.10.13?
Hello everyone, We last released Ant more than a year back. During that period we have had some good amount of bug fixes and changes that have gone in. Plus, Java 18 and beyond was released in the meantime where setting the security manager isn't allowed by default (Ant sets it). 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. The way we detect Java versions within Ant's startup script isn't straightforward, especially for Windows. We had a brief discussion[1] about it in the past and I'll be focusing on this area to see if I can improve that situation in this coming week before the release. [1] https://lists.apache.org/thread/53jo1sy8ly2645j68m7s2g2mb4f10dy5 -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Message output level not public for Project class
A new method has been introduced on BuildLogger interface called getMessageOutputLevel() which will return the currently set level. This will be available in the next Ant release. -Jaikiran On 11/10/22 10:38 am, Jaikiran Pai wrote: With Ant 1.10.x version requiring Java 8, I think it should now be possible for us to add a new (default) method to the org.apache.tools.ant.BuildLogger interface to return the current set (or some default) log level. I will add something along these lines shortly. -Jaikiran On 11/10/22 10:26 am, Gilles Querret wrote: Hello Earl, So far I've used this workaround to retrieve the log level: https://github.com/Riverside-Software/pct/blob/d8446a002aaf2efb255d2016a16e9a71f7ad269f/src/java/com/phenix/pct/PCT.java#L593 Usage in the Ant task: https://github.com/Riverside-Software/pct/blob/master/src/java/com/phenix/pct/PCTRun.java#L475 Code was written years ago, there might be a better solution now. Gilles On Wed, Sep 7, 2022 at 8:24 PM Earl Hood wrote: Ant Devs, Working on a custom task that will exec an external program. One thing I would like to do is if ant is invoked with debugging output level, set the debugging flag to the external program. Unfortunately, it seems to get the current logging level is not easy, as the level set when Ant is invoked is private with no getter method to retrieve it. I see the level is passed into build listeners, but those APIs also do not expose the level. Is there any way to retrieve the current logging level, and if not, is reasonable to make the current level accessible via a public method in the Project class? Best regards, --ewh - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Iyv 2.5.1 Based on RC1
+1 - Downloaded the apache-ivy-2.5.1-bin.tar.gz. - Installed locally. - Ran java -jar $IVY_HOME/ivy-2.5.1.jar -version (correct version reported) - Then built a few existing projects with this version and they passed - Checked some docs in the "doc" folder and they looked fine. -Jaikiran On 01/11/22 3:40 pm, Stefan Bodewig wrote: Hi all I've built a release candidate for Ivy 2.5.1 Changelog: - BREAKING: Removed old fr\jayasoft\ivy\ant\antlib.xml AntLib definition file (jira:IVY-1612[]) - FIX: ResolveEngine resets dictator resolver to null in the global configuration (jira:IVY-1618[]) - FIX: ConcurrentModificationException in MessageLoggerHelper.sumupProblems (jira:IVY-1628[]) - FIX: useOrigin="true" fails with file-based ibiblio (jira:IVY-1616[]) - FIX: ivy:retrieve Ant task didn't create an empty fileset when no files were retrieved to a non-empty directory (jira:IVY-1631[]) - FIX: ivy:retrieve Ant task relied on the default HTTP header "Accept" which caused problems with servers that interpret it strictly (e.g. AWS CodeArtifact) (jira:IVY-1632[]) - IMPROVEMENT: Ivy command now accepts a URL for the -settings option (jira:IVY-1615[]) The release artifacts can be found at https://dist.apache.org/repos/dist/dev/ant/ivy/ (svn revision 57703) Maven Repo is https://repository.apache.org/content/repositories/orgapacheant-1055/org/apache/ivy/ivy/2.5.1/ I have not built the update site because I couldn't get the build process to work, so if anybody with the proper build environment wants to create one, thank you. I'm sure we can create it after the release if we want to. Do you vote for the release of these binaries? [ ] Yes [ ] No This vote will be open for 72 hours as usual, I'll close it on 2022-11-04 10 UTC. Thanks Stefan - 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
Re: Message output level not public for Project class
With Ant 1.10.x version requiring Java 8, I think it should now be possible for us to add a new (default) method to the org.apache.tools.ant.BuildLogger interface to return the current set (or some default) log level. I will add something along these lines shortly. -Jaikiran On 11/10/22 10:26 am, Gilles Querret wrote: Hello Earl, So far I've used this workaround to retrieve the log level: https://github.com/Riverside-Software/pct/blob/d8446a002aaf2efb255d2016a16e9a71f7ad269f/src/java/com/phenix/pct/PCT.java#L593 Usage in the Ant task: https://github.com/Riverside-Software/pct/blob/master/src/java/com/phenix/pct/PCTRun.java#L475 Code was written years ago, there might be a better solution now. Gilles On Wed, Sep 7, 2022 at 8:24 PM Earl Hood wrote: Ant Devs, Working on a custom task that will exec an external program. One thing I would like to do is if ant is invoked with debugging output level, set the debugging flag to the external program. Unfortunately, it seems to get the current logging level is not easy, as the level set when Ant is invoked is private with no getter method to retrieve it. I see the level is passed into build listeners, but those APIs also do not expose the level. Is there any way to retrieve the current logging level, and if not, is reasonable to make the current level accessible via a public method in the Project class? Best regards, --ewh - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Migrate from Bugzilla to GitHub Issues
I agree with Stefan. GitHub has its own set of pleasant features but I don't think moving Ant's issue tracker to GitHub is necessary. I haven't been around in the Ant community since the beginning but for the past few years that I've been around, I don't think reporting issues in Bugzilla has been a friction in the Ant project. Keeping Ant's infrastructure within Apache I believe is the right thing - that would mean hosting the issue tracker within the Apache infrastructure. That doesn't necessarily mean using bugzilla. Apache hosts JIRA instance too at https://issues.apache.org/. Moving to Apache's JIRA instance _might_ be an option but I don't know what kind of efforts would be involved and if those are worth it. -Jaikiran On 18/08/22 5:02 pm, Stefan Bodewig wrote: Hi Vladimir I guess we have to agree that we disagree - and this is fine. Our perception of how development of Ant happens are quite different. The issue you are trying to solve is a non-issue for me. And the reasons I do not want to move to github issues are likely irrelevant to you. No need to drag the discussion further as we are not going to convince each other. Personally I'd prefer to have less github in ASF projects rather than more, but that may just be me. This has more to do with the ASF being in control of its own fate than with technical reasons. Fortunately I'm not the only voice around here :-) Cheers Stefan - 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
Re: JDK 19: Rampdown Phase 1 + EA builds 26 & JDK 20: EA builds 1
Additionally, I ran the Ant testsuite on a macos setup locally with JDK 19 EA build 19-ea+26-2060 by using --enable-preview. No issues were encountered in the testsuite. -Jaikiran On 16/06/22 7:11 pm, Jaikiran Pai wrote: Hello David, We ran the Ant testsuite against JDK 19 EA build 19-ea+26-2060 on a Linux system. No issues were found in this run https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Linux%20(latest%20EA%20JDK)/26/. -Jaikiran On 13/06/22 6:47 pm, David Delabassee wrote: Greetings! JDK 19 has now entered Rampdown Phase One (RDP1) [1], which means that the main-line has been forked into a dedicated JDK 19 stabilization repository. At this point, the overall JDK 19 feature set is frozen and no additional JEPs will be targeted to JDK 19. The stabilization repository is open for select bug fixes and, with approval, late low-risk enhancements per the JDK Release Process [2]. Any change pushed to the main line is now bound for JDK 20, unless it is explicitly back-ported to JDK 19. The next few weeks should be leveraged to try to identify and resolve as many issues as possible, i.e. before JDK 19 enters the Release Candidates phase. Moreover, we encourage you to test your project with the `enable-preview` flag as described in this Quality Outreach Heads-up [3], and even if you don't intend to use Virtual Threads in the near future. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-June/006735.html [2] https://openjdk.java.net/jeps/3 [3] https://inside.java/2022/05/16/quality-heads-up/ ## Heads-up - openjdk.java.net ➜ openjdk.org DNS transition The OpenJDK infrastructure is moving from the old openjdk.java.net subdomain to the openjdk.org top-level domain. This will affect all active subdomains (i.e., bugs, cr, db, git, hg, mail, and wiki) and the old hostnames (*.openjdk.java.net) will now act as aliases for the new names. No actions are required as this transition should be transparent and is mostly done. It should be mentioned that https://jdk.java.net/ is not changing. More infirmation can be found in the original proposal https://mail.openjdk.java.net/pipermail/discuss/2022-May/006089.html ## JDK 19 Early-Access builds JDK 19 Early-Access builds 26 are now available [4], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [5]. Given that JDK 19 is now in RDP1, the initial JDK 20 Early-Access builds are now also available [6]. [4] https://jdk.java.net/19/ [5] https://jdk.java.net/19/release-notes [6] https://jdk.java.net/20/ ### JEPs integrated to JDK 19: - JEP 405: Record Patterns (Preview) - JEP 422: Linux/RISC-V Port - JEP 424: Foreign Function & Memory API (Preview) - JEP 425: Virtual Threads (Preview) - JEP 426: Vector API (Fourth Incubator) - JEP 427: Pattern Matching for switch (Third Preview) - JEP 428: Structured Concurrency (Incubator) ### Recent changes that may be of interest: Build 26: - JDK-8284199: Implementation of Structured Concurrency (Incubator) - JDK-8282662: Use List.of() factory method to reduce memory consumption - JDK-8284780: Need methods to create pre-sized HashSet and LinkedHashSet - JDK-8250950: Allow per-user and system wide configuration of a jpackaged app - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS - JDK-4511638: Double.toString(double) sometimes produces incorrect results - JDK-8287714: Improve handling of JAVA_ARGS - JDK-8286850: [macos] Add support for signing user provided app image - JDK-8287425: Remove unnecessary register push for MacroAssembler::check_k… - JDK-8283694: Improve bit manipulation and boolean to integer conversion o… - JDK-8287522: StringConcatFactory: Add in prependers and mixers in batches Build 25: - JDK-8284960: Integration of JEP 426: Vector API (Fourth Incubator) - JDK-8287244: Add bound check in indexed memory access var handle - JDK-8287292: Improve TransformKey to pack more kinds of transforms effici… - JDK-8287003: InputStreamReader::read() can return zero despite writing a … - JDK-8287064: Modernize ProxyGenerator.PrimitiveTypeInfo Build 24: - JDK-8286908: ECDSA signature should not return parameters - JDK-8261768: SelfDestructTimer should accept seconds - JDK-8286304: Removal of diagnostic flag GCParallelVerificationEnabled - JDK-8267038: Update IANA Language Subtag Registry to Version 2022-03-02 - JDK-8285517: System.getenv() returns unexpected value if environment vari… - JDK-8285513: JFR: Add more static support for event classes - JDK-8287024: G1: Improve the API boundary between HeapRegionRemSet and G1… - JDK-8287139: aarch64 intrinsic for unsignedMultiplyHigh Build 23: - JDK-8282191: Implementation of Foreign Function & Memory API (Preview) - JDK-8286090: Add RC2/RC4 to jdk.security.legacyAlgorithms - JDK-8282080: Lambda deserialization fails for Object method references on interfaces - JDK-6782021: It is not pos
Re: JDK 19: Rampdown Phase 1 + EA builds 26 & JDK 20: EA builds 1
Hello David, We ran the Ant testsuite against JDK 19 EA build 19-ea+26-2060 on a Linux system. No issues were found in this run https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Linux%20(latest%20EA%20JDK)/26/. -Jaikiran On 13/06/22 6:47 pm, David Delabassee wrote: Greetings! JDK 19 has now entered Rampdown Phase One (RDP1) [1], which means that the main-line has been forked into a dedicated JDK 19 stabilization repository. At this point, the overall JDK 19 feature set is frozen and no additional JEPs will be targeted to JDK 19. The stabilization repository is open for select bug fixes and, with approval, late low-risk enhancements per the JDK Release Process [2]. Any change pushed to the main line is now bound for JDK 20, unless it is explicitly back-ported to JDK 19. The next few weeks should be leveraged to try to identify and resolve as many issues as possible, i.e. before JDK 19 enters the Release Candidates phase. Moreover, we encourage you to test your project with the `enable-preview` flag as described in this Quality Outreach Heads-up [3], and even if you don't intend to use Virtual Threads in the near future. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-June/006735.html [2] https://openjdk.java.net/jeps/3 [3] https://inside.java/2022/05/16/quality-heads-up/ ## Heads-up - openjdk.java.net ➜ openjdk.org DNS transition The OpenJDK infrastructure is moving from the old openjdk.java.net subdomain to the openjdk.org top-level domain. This will affect all active subdomains (i.e., bugs, cr, db, git, hg, mail, and wiki) and the old hostnames (*.openjdk.java.net) will now act as aliases for the new names. No actions are required as this transition should be transparent and is mostly done. It should be mentioned that https://jdk.java.net/ is not changing. More infirmation can be found in the original proposal https://mail.openjdk.java.net/pipermail/discuss/2022-May/006089.html ## JDK 19 Early-Access builds JDK 19 Early-Access builds 26 are now available [4], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [5]. Given that JDK 19 is now in RDP1, the initial JDK 20 Early-Access builds are now also available [6]. [4] https://jdk.java.net/19/ [5] https://jdk.java.net/19/release-notes [6] https://jdk.java.net/20/ ### JEPs integrated to JDK 19: - JEP 405: Record Patterns (Preview) - JEP 422: Linux/RISC-V Port - JEP 424: Foreign Function & Memory API (Preview) - JEP 425: Virtual Threads (Preview) - JEP 426: Vector API (Fourth Incubator) - JEP 427: Pattern Matching for switch (Third Preview) - JEP 428: Structured Concurrency (Incubator) ### Recent changes that may be of interest: Build 26: - JDK-8284199: Implementation of Structured Concurrency (Incubator) - JDK-8282662: Use List.of() factory method to reduce memory consumption - JDK-8284780: Need methods to create pre-sized HashSet and LinkedHashSet - JDK-8250950: Allow per-user and system wide configuration of a jpackaged app - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS - JDK-4511638: Double.toString(double) sometimes produces incorrect results - JDK-8287714: Improve handling of JAVA_ARGS - JDK-8286850: [macos] Add support for signing user provided app image - JDK-8287425: Remove unnecessary register push for MacroAssembler::check_k… - JDK-8283694: Improve bit manipulation and boolean to integer conversion o… - JDK-8287522: StringConcatFactory: Add in prependers and mixers in batches Build 25: - JDK-8284960: Integration of JEP 426: Vector API (Fourth Incubator) - JDK-8287244: Add bound check in indexed memory access var handle - JDK-8287292: Improve TransformKey to pack more kinds of transforms effici… - JDK-8287003: InputStreamReader::read() can return zero despite writing a … - JDK-8287064: Modernize ProxyGenerator.PrimitiveTypeInfo Build 24: - JDK-8286908: ECDSA signature should not return parameters - JDK-8261768: SelfDestructTimer should accept seconds - JDK-8286304: Removal of diagnostic flag GCParallelVerificationEnabled - JDK-8267038: Update IANA Language Subtag Registry to Version 2022-03-02 - JDK-8285517: System.getenv() returns unexpected value if environment vari… - JDK-8285513: JFR: Add more static support for event classes - JDK-8287024: G1: Improve the API boundary between HeapRegionRemSet and G1… - JDK-8287139: aarch64 intrinsic for unsignedMultiplyHigh Build 23: - JDK-8282191: Implementation of Foreign Function & Memory API (Preview) - JDK-8286090: Add RC2/RC4 to jdk.security.legacyAlgorithms - JDK-8282080: Lambda deserialization fails for Object method references on interfaces - JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider - JDK-8282191: Implementation of Foreign Function & Memory API (Preview) - JDK-8284194: Allow empty subject fields in keytool - JDK-8209137: Add ability to
Re: synchronized and Loom
Hello Stefan, My personal opinion is that we continue with our release plans (whenever we do it) instead of waiting for completing these changes. The virtual threads feature is a preview feature in JDK 19, so I think as long as our tests pass and Ant is usable in Java 19 with --enable-preview, I think that's a good enough for an Ant release. As for doing the actual changes, I think we will have to review these call paths in core and individual tasks. Specifically, I think we need to understand when/where a virtual thread might get used during a build in a regular use case. The other thing I am hoping with our Ant release is that we get actual users to start using the version with their own builds/projects and tell us if/how the current release doesn't play well (in terms of performance etc...) when it comes to virtual threads. Given that this all boils down to "pinning" of the thread and since the JEP 425 states: "Pinning does not make an application incorrect, but it might hinder its scalability. If a virtual thread performs a blocking operation such as I/O or BlockingQueue.take() while it is pinned, then its carrier and the underlying OS thread are blocked for the duration of the operation. Frequent pinning for long durations can harm the scalability of an application by capturing carriers. The scheduler does not compensate for pinning by expanding its parallelism. Instead, avoid frequent and long-lived pinning by revising synchronized blocks or methods that run frequently and guard potentially long I/O operations to use java.util.concurrent.locks.ReentrantLock instead. There is no need to replace synchronized blocks and methods that are used infrequently (e.g., only performed at startup) or that guard in-memory operations. As always, strive to keep locking policies simple and clear." I think we should take our time to review these usages on a per use basis (I realize 500 odd is too big to do on a per use basis, but I think once we do the first few necessary changes, there should be more clarity on which ones to focus on next). -Jaikiran On 06/06/22 4:19 pm, Stefan Bodewig wrote: Hi right now the Loom prototype doesn't play well with synchronized and the recommended approach is to use ReentrantLock instead. A quick grep over Ant's codebase turns up more than 500 hits for synchronized - many of which in method declarations. So updating it will be a bigger task, in particular if we wanted to take the time to think through the reasons for synchronization and whether splitting read/write locks may be useful. Do you feel we should do this before the next release or should we defer it? Another option might be to mechanically replace synchronized with reentrantlock now and do the "read/write lock separation would be good" assessment later. Stefan - 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
Re: Please consider releasing Apache Ant 1.10.13?
Hello Simon, I do have it on my task list to do a release in the coming weeks. I don't have an exact date yet. One change that we did recently was to make Ant work out of the box (without setting any additional environment variable values or system properties) to make it work against Java 18 and 19 EA (which have changes in the security manager area). The way we did it isn't the most optimal way (but works). So I just want to find some time to review that once again before deciding on how we want to go about it. -Jaikiran On 03/06/22 9:40 pm, Simon Law wrote: Hello! I was wondering if there is a release planned for Ant 1.10.13? We’ve encountered a bug that would be fixed by https://github.com/apache/ant/pull/173. Thanks in advance! Simon - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: JDK 19 - Virtual Threads Testing!
Hello David, I did a quick run of our Ant project testsuite against the Java 19 EA version (build 19-ea+23-1706). This round of testing did _not_ enable preview features and thus it didn't test virtual threads yet. I just wanted to make sure this EA version works fine without virtual threads feature enabled. Our test results show that things work fine except for a change in behaviour in an unrelated area (javax.imageio) for which I've opened a JBS issue https://bugs.openjdk.java.net/browse/JDK-8287120. In the next few days I'll runs tests against the Ant testsuite by enabling virtual threads preview feature and see how it goes. -Jaikiran On 16/05/22 1:13 pm, David Delabassee wrote: Welcome to a new Quality Outreach update! This time, we have one update but a major one: JEP 425 (Virtual Threads preview) has been integrated into the OpenJDK mainline! JDK 19 Early-Access builds 22 are the first mainline builds with Virtual Threads (preview) support. So, Project Loom is now getting closer and closer! Please make sure to check the Heads-up below even if you don’t intend to use virtual threads in the short future. ## Heads-up - JEP 425 Virtual Threads (preview) testing The goal of Project Loom is to introduce in the Java platform an easy-to-use, high-throughput lightweight concurrency model, and a related new concurrent programming model. Developed in Project Loom, JEP 425 introduces virtual threads to the Java Platform. Virtual threads are lightweight threads that dramatically reduce the effort of writing, maintaining, and observing high-throughput concurrent applications. Note that virtual threads are a preview API in JDK 19. Please make sure to read 'JEP 425: Virtual Threads (Preview)' for a detailed explanation. A lot of testing has already been done but we are asking, once again, your help to test your project(s) with the latest JDK 19 Early-Access builds, even if you don’t intend to use virtual threads any time soon. There are two approaches to test your project: 1. Update your code to use virtual threads …or 2. Simply test your existing unchanged code with the preview feature enabled. Both approaches should yield valuable feedback. If you choose to adapt your application to use virtual threads (cf. JavaDoc [2]), be aware that in some cases it’s not just about updating your code to use virtual threads instead of platform threads; there are some additional considerations. For example, virtual threads shouldn’t be pooled [3], code that relies heavily on thread locals [4] will require some work to move to a world where there is a new thread for each task, etc. Given that are some minor behavior changes and that `ThreadGroup` has been degraded, testing your code as-is, i.e., without using virtual threads but with the preview feature enabled at runtime, will also be useful. For more details, please check 'JEP 425 - Risks and Assumptions' [5]. One difference between to the EA builds published by Project Loom and the latest JDK 19 EA builds is that the `--enable-preview` flag is required at run-time to use the new APIs. It’s not possible to use the APIs with core reflection to avoid the need for `--enable-preview`. Finally, some tools especially tools relying on JVM TI agents might not be fully ready for virtual threads. Your help testing this important update is greatly appreciated, all feedback should be sent to the 'loom-dev' mailing list [6]. [1] https://openjdk.java.net/jeps/425 [2] https://download.java.net/java/early_access/jdk19/docs/api/java.base/java/lang/Thread.html [3] https://openjdk.java.net/jeps/425#Do-not-pool-virtual-threads [4] https://openjdk.java.net/jeps/425#Thread-local-variables [5] https://openjdk.java.net/jeps/425#Risks-and-Assumptions [6] https://mail.openjdk.java.net/pipermail/loom-dev/ ## JDK 19 Early-Access builds JDK 19 Early-Access builds 22 are now available [7], and are provided under the GNU General Public License v2, with the Classpath Exception. Make sure to check the Release Notes [8] and the JavaDoc [9]. [7] https://jdk.java.net/19/ [8] https://jdk.java.net/19/release-notes [9] https://download.java.net/java/early_access/jdk19/docs/ ### Current JDK 19 JEPs - 405: Record Patterns (Preview) - Proposed to target - 422: Linux/RISC-V Port - Integrated - 424: Foreign Function & Memory API (Preview) - Integrated - 425: Virtual Threads (Preview) - Integrated - 426: Vector API (4th Incubator) - Targeted - 427: Pattern Matching for switch (3rd Preview) - Targeted ### Recent changes that may be of interest: Build 22: - JDK-8284161: Implementation of Virtual Threads (Preview) - JDK-8285947: Avoid redundant HashMap.containsKey calls in ZoneName - JDK-8212136: Remove finalizer implementation in SSLSocketImpl - JDK-8285872: JFR: Remove finalize() methods - JDK-8285914: AppCDS crash when using shared archive with old class file - JDK-8286163: micro-optimize Ins
Re: Build failed in Jenkins: Ant » Ant-Build-from-POMs #120
Hello Matt, That job keeps failing every other time. I haven't had a chance to understand why it fails nor do I know what that job is for. I think you can ignore that specific job failure since it's not your commits which is causing it. The only failure that looks related to the recent commits is in a different job (on Windows) - https://ci-builds.apache.org/job/Ant/job/Ant-Build-Matrix-master-Windows/OS=Windows,jdk=jdk_1.8_latest/120/testReport/src.tests.antunit.taskdefs/pathconvert-test_xml/testDirsep/ -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 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
Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19
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-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, 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, 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-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
Re: JDK 18 Rampdown Phase 2 & JDK 19 Early-Access Builds
Hello David, I ran the Java 18 build 18-ea+34-2083 and Java 19 build 19-ea+8-441 against our Ant testsuite on a Linux setup and we observed no regressions, except security manager exceptions. We had to do changes to our Ant launch command to get past the security manager runtime exceptions that are now thrown in Java 18 and 19, if security manager gets set at runtime (Ant does set it at runtime). I'll be proposing these changes to the Ant launch scripts to be part of a release soon, so that projects using Ant to build against Java 18+ can get past these issues. The test run results are available at: Java 18 - https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Linux%20(latest%20EA%20JDK)/16/ Java 19 - https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20Linux%20(latest%20EA%20JDK)/17/ -Jaikiran On 31/01/22 2:47 pm, David Delabassee wrote: Greetings! First off, on behalf of Oracle’s Java Team, I’d like to wish you a happy and prosperous new year! In 2022, two Java releases will be made available: - JDK 18 (March 2022) - JDK 19 (September 2022) JDK 18[1] has entered Rampdown Phase Two (RDP2)[2]. Given that and to be better prepared for the future, it makes sense to begin testing your project(s) using early access (EA) builds of JDK 19[3]. Your feedback allows us to evaluate and address issues you find while testing EA builds. This time, we have two heads-up to share: ## Heads-Up: JDK 18 - JEP 421 Deprecate Finalization for Removal Finalization is an outdated and brittle resource cleaning mechanism present in the platform since, well, forever. Its use has been discouraged for quite some time in favor of better alternatives (i.e., 'try with resources' and Cleaners). JEP 421 is another step towards the removal of finalizers as it offers tools to investigate if a codebase is still using finalization. To learn more, you should read JEP 421[4]. You should also listen to the latest episode of the Inside Java Podcast[5] dedicated to this topic. We encourage you to check if your project is still using finalizers. If so, you should start to think about removing them and rely instead on either 'try with resources' or Cleaners. ## Heads-Up: JVM does not flag constant class entries ending in '/' Prior to JDK 19, the JVM is loading classes (1) whose class file major version is <49, i.e., before JDK 1.5, and (2) the class's name ends with a '/'. This violates section 4.2.1 of the JVM specification [6] and is addressed in JDK 19. In JDK 19, the JVM is throwing, for such classes, a ClassFormatError exception as it already does with newer classes (JDK 1.5+). Given that this issue affects only pre-JDK 1.5 classes, we expect the compatibility risk to be very low. For more details, see JDK-8278448[7]. [1] https://jdk.java.net/18/ [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2022-January/006361.html [3] https://jdk.java.net/19/ [4] https://openjdk.java.net/jeps/421 [5] https://inside.java/podcast/21 [6] https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.2.1 [7] https://bugs.openjdk.java.net/browse/JDK-8278448 ## JDK 18 JDK 18 is now in RDP2 (Rampdown Phase Two) with its feature set frozen a few weeks back when it entered RDP1. ### JEPs integrated to JDK 18: - JEP 400: UTF-8 by Default - JEP 408: Simple Web Server - JEP 413: Code Snippets in Java API Documentation - JEP 416: Reimplement Core Reflection with Method Handles - JEP 417: Vector API (Third Incubator) - JEP 418: Internet-Address Resolution SPI - JEP 419: Foreign Function & Memory API (Second Incubator) - JEP 420: Pattern Matching for switch (Second Preview) - JEP 421: Deprecate Finalization for Removal JDK 18 Early-Access builds 33 are now available[8], and are provided under the GNU General Public License v2, with the Classpath Exception. Also available are the Release Notes[9]. [8] https://jdk.java.net/18/ [9] https://jdk.java.net/18/release-notes ### Changes in JDK 18 since Rampdown Phase One that are of interest: - JDK-8278373: Correcting References to Overloaded Methods in Javadoc Documentation - JDK-8279065: Deserialization filter and filter factory property error reporting under specified - JDK-8255409: SunPKCS11 Provider Now Supports Some PKCS#11 v3.0 APIs - JDK-8275610: C2: Object field load floats above its null check resulting in a segfault [Reported by Apache POI] ## JDK 19 JDK 19 Early-Access builds 7 are now available[10], and are provided under the GNU General Public License v2, with the Classpath Exception. Also available are the Release Notes[11]. [10] https://jdk.java.net/19/ [11] https://jdk.java.net/19/release-notes ### Changes in recent JDK 19 EA builds that maybe of interest: - JDK-8279258: Auto-vectorization enhancement for two-dimensional array operations - JDK-8273914: Indy string concat changes order of operations - JDK-8268081: Upgrade Unicode Data Files to 14.0.0
Re: [DISCUSS] JUnit 5 Customization
Hello Aleksei, On 22/12/21 7:59 pm, Aleksei Zotov wrote: Hi Ant Developers, I'm working on the migration of Apache Cassandra project from JUnit 4 to JUnit 5 (CASSANDRA-16630 <https://issues.apache.org/jira/browse/CASSANDRA-16630>) which turned out to be larger than I originally expected. At the moment, three PRs got merged: - https://github.com/apache/ant/pull/147 - https://github.com/apache/ant/pull/168 - https://github.com/apache/ant/pull/172 And there are a few more I'd like to discuss with you. Sorry, I remember seeing a PR from you where you asked for some inputs in this area, but I haven't been able to get to it due to some other priorities. Formatters Extensibility Apache Cassandra extended the existing JUnit 4 formatters in order to integrate them with a custom logic required for a better CI process. It was easily achievable for JUnit 4 since the formatters are marked public. On the contrary, for JUnit 5 all formatters are package private. Even *AbstractJUnitResultFormatter* is package private. Of course, we can copy-paste all these classes to our project and customize them based on our needs, but that seems to be a bit of an overhead. Currently, we'd like to make *AbstractJUnitResultFormatter *extensible. Here is the corresponding PR: https://github.com/apache/ant/pull/169/ The reason why these formatters are package private and not extensible is intentional. When I added these formatters, one of the goals of these formatters was to only make them generate output to an extent that it matches the JUnit4 style formatters of the "junit" task (hence the name "legacy-" to those formatters). All these pre-shipped "legacy-" listeners that you see in Ant are only there for minimal support and their implementation is considered to be internal to the Ant distribution. The new JUnit5 framework itself is extensible and also comes with some pre-shipped "listeners" (implementations of TestExecutionListener). That's one of the reasons why the junitlauncher task's "listener" element provides a direct way to use any implementation of the JUnit5 framework's "org.junit.platform.launcher.TestExecutionListener". i.e. for any code that seeks extensibility, the org.junit.platform.launcher.TestExecutionListener is expected to be the extension point/interface and not Ant's internal AbstractJUnitResultFormatter. This allows the junitlauncher task to be minimal and allows it to achieve its goal of just being something that will launch the JUnit5 framework. I can understand that some of the code in the AbstractJUnitResultFormatter might appear reusable and would be tempting to reuse/extend, but I wouldn't want anything outside of Ant to start using these classes and instead just code against the JUnit5 classes/interfaces. Having said all this, if any of other maintainers of the Ant project feel that we should allow these internal classes to be extensible, I won't mind having this work reviewed and merged. Fork Mode Support Apache Cassandra is a large and complex product and in order to guarantee its quality we run many tests independently. It lets us ensure different test suites do not affect each other. For isolated testing we spin up a new JVM per tests suite via *forkMode* property. Unfortunately, *junitlauncher* task does not provide such a functionality. Currently, we'd like *mode* attribute to *fork* element. Here is the corresponding PR: https://github.com/apache/ant/pull/174 I remember there was some bugzilla discussion of a similar question (or maybe on some other forum). I'll take a look at this PR soon. I'd be glad if you could provide some feedback on that. Also I need some guidance here - I have a suspicion that *JUnitLauncherTaskTest* is not being run during "./build clean test" (I cannot grep it in logs). Could you please help me to run this particular test from CLI. Have you fetched the optional JUnit5 libraries before running these tests? A lot of Ant's tasks are optional and their tests are only run if the corresponding libraries are available in the classpath. To fetch these dependencies you can do: ant -f fetch.xml -Ddest=optional and then run the tests using the command you currently use. Use File Support Apache Cassandra does not always need to write testing output to a file. Even though it is possible to achieve writing into standard output (by overriding *TestResultFormatter.setDestination *method) instead of a file, it is impossible to prevent empty files from being created on the file system. Of course, we can delete these files, however, it would be nice to have the functionality similar to *junit* task. I've already started a related discussion on the PR (please, chime in): https://github.com/apache/ant/pull/171 I'll take a look at this one. -Jaikiran ---
Re: JDK 18 Early-Access builds 23 are available
Hello David, Given the security manager changes in this JDK 18 EA build, a lot of our Ant tests have failed against this version. This was expected and we had anticipated this when the work on these changes had started in JDK. This will need changes in the Ant project to make it work starting this version. We (Ant project) will be working on this to get it in working shape, in the coming weeks. -Jaikiran On 16/11/21 4:22 pm, david.delabas...@oracle.com wrote: Hi Jaikiran/Stefan, I’m happy to announce that moving forward Oracle’s Java DevRel Team will manage the Quality Outreach Program. I would like to thank Rory for all the efforts he's put into this program and wish him all the joy and happiness that retirement can bring! We have big shoes to fill but we’re excited to continue building off the amazing structure Rory has put in place. The JDK 18 schedule is now known [1] with a feature freeze date (Rampdown Phase One) less than 4 weeks away! This time, we have 2 important heads-ups, one related to JEP 411 (Deprecate the Security Manager for Removal), and one related to JEP 416 (Reimplement Core Reflection with Method Handles). We're asking your help to test and confirm that your project works seamlessly now that those 2 JEPs are integrated in the JDK 18 Early-Access builds. [1] https://openjdk.java.net/projects/jdk/18/ # JEP 411 - Deprecate the Security Manager for Removal Starting JDK 18 b21 [2], the default value of the 'java.security.manager' system property is set to "disallow". This means that any application or library that enables the Security Manager by calling `System.setSecurityManager` will now have to specify `-Djava.security.manager=allow` on the command-line in order for that code to continue working as expected. This change was originally targeted for JDK 17, but after some discussion/feedback from the community, the change was delayed until JDK 18 [3]. [2] https://bugs.openjdk.java.net/browse/JDK-8270380 [3] https://openjdk.java.net/jeps/411#Description # JEP 416 - Reimplement Core Reflection with Method Handles JEP 416 [4] reimplements `java.lang.reflect.Method`, `java.lang.reflect.Constructor`, and `java.lang.reflect.Field` on top of `java.lang.invoke` method handles. Making method handles the underlying mechanism for reflection will reduce the maintenance and development cost of both the `java.lang.reflect` and `java.lang.invoke` APIs. This is solely an implementation change but we encourage you to test your project to identify any behavior or performance regressions. [4] https://openjdk.java.net/jeps/416 OpenJDK 18 Early-Access builds 23 are now available [5], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available [6]. [5] https://jdk.java.net/18/ [6] https://jdk.java.net/18/release-notes # JEPs integrated to JDK 18, so far: - JEP 400: UTF-8 by Default https://openjdk.java.net/jeps/400 - JEP 408: Simple Web Server https://openjdk.java.net/jeps/408 - JEP 413: Code Snippets in Java API Documentation https://openjdk.java.net/jeps/413 - JEP 416: Reimplement Core Reflection with Method Handles https://openjdk.java.net/jeps/416 - JEP 418: Internet-Address Resolution SPI https://openjdk.java.net/jeps/418 # JEPs targeted to JDK 18, so far: - JEP 417: Vector API (Third Incubator) https://openjdk.java.net/jeps/417 # JEPs proposed to target JDK 18, so far: - JEP 419: Foreign Function & Memory API (Second Incubator) https://openjdk.java.net/jeps/419 - JEP 420: Pattern Matching for switch (Second Preview) https://openjdk.java.net/jeps/420 # Changes in recent builds that maybe of interest: ## Build 23: - JDK-8275509: ModuleDescriptor.hashCode isn't reproducible across builds - JDK-8276220: Reduce excessive allocations in DateTimeFormatter - JDK-8276298: G1: Remove unused G1SegmentedArrayBufferList::add - JDK-8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) ## Build 22: - JDK-8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle - JDK-8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations - JDK-8251468: X509Certificate.get{Subject,Issuer}AlternativeNames and getExtendedKeyUsage do not throw CertificateParsingException if extension is unparseable ## Build 21: - JDK-8270380: Change the default value of the java.security.manager system property to disallow - JDK-8275319: java.net.NetworkInterface throws java.lang.Error instead of SocketException - JDK-8270490: Charset.forName() taking fallback default value - JDK-8269336: Malformed jdk.serialFilter incorrectly handled # Project Loom update New Project Loom 18-loom+4-273 (2021/11/10) Early-Access builds are available [7] with related Javadocs [8]. [7] https://jdk.java.net/loom/ [8] https://download.java.net/java/early_access/loom/docs/api/
Re: Thank you! JDK 18 Early Access build 20 is now available
Hello Rory, I ran the JDK 18 EA (build 18-ea+20-1248) against our Ant testsuite on Linux and no issues were encountered: https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20(latest%20EA%20JDK)/82/jdk_axis=jdk18_ea,label_exp=ubuntu/ -Jaikiran On 26/10/21 5:37 pm, Rory O'Donnell wrote: Hi Stefan/Jaikiran, *Thank you.* I'm retiring at the end of November 2021, it's time to spend more time with the family. We started the Quality Outreach back in October 2014. We now have 170+ projects participating. Thank you for taking the time to provide Testing feedback , excellent bugs and support throughout the last seven years. It's been a pleasure working with you. I am delighted to say that the program will continue with the support of the Java DevRel Team, with David Delabassee as your contact. David has been assisting with on-boarding new projects for the last couple of years. All the best, Rory *OpenJDK 18Early Access build 20is now available at**https://jdk.java.net/18/ <https://jdk.java.net/18/>** * * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <https://openjdk.java.net/legal/gplv2+ce.html>. * Release Notes are available athttps://jdk.java.net/18/release-notes <https://jdk.java.net/18/release-notes> * Features: o JEPs integrated to JDK 18, so far: + JEP 400: UTF-8 by Default <https://openjdk.java.net/jeps/400> + JEP 408: Simple Web Server <https://openjdk.java.net/jeps/408> + JEP 413: Code Snippets in Java API Documentation <https://openjdk.java.net/jeps/413> o JEPs targeted to JDK 18, so far + JEP 417: Vector API (Third Incubator) <https://openjdk.java.net/jeps/417> o JEPs proposed to target JDK 18: + JEP 416: Reimplement Core Reflection with Method Handles <https://openjdk.java.net/jeps/416> * Significant changes since the last availability email: o Build 20: + JDK-8275252: Migrate cacerts from JKS to password-less PKCS12 + JDK-8275149: (ch) ReadableByteChannel returned by Channels.newChannel(InputStream) throws ReadOnlyBufferException + JDK-8266936: Add a finalization JFR event + JDK-8264849: Add KW and KWP support to PKCS11 provider o Build 19: + JDK-8274840: Update OS detection code to recognize Windows 11 + JDK-8274407: (tz) Update Timezone Data to 2021c + JDK-8273102: Delete deprecated for removal the empty finalize() in java.desktop module o Build 18: + JDK-8274656: Remove default_checksum and safe_checksum_type from krb5.conf + JDK-8274471: Add support for RSASSA-PSS in OCSP Response + JDK-8274227: Remove "impl.prefix" jdk system property usage from InetAddress + JDK-8274002: [win11 and winserver2022] JDK executable installer from network drive starts with huge delay + JDK-8273670: Remove weak etypes from default krb5 etype list o Build 17: + JDK-8273401: Disable JarIndex Support In URLClassPath + JDK-8231640: (prop) Canonical property storage + Build 16: + JDK-8269039: Disable SHA-1 Signed JARs *Topics of Interest:*_ _ _JDK 17:_** ** * *Inside Java Podcast “Java 17 is Here!”* o *Part 1: https://inside.java/2021/09/14/podcast-019/ <https://inside.java/2021/09/14/podcast-019/>* o *Part 2: https://inside.java/2021/09/27/podcast-020/ <https://inside.java/2021/09/27/podcast-020/>* * *G1 GC & Parallel GC Improvements in JDK 17* o *https://inside.java/2021/09/17/jdk-17-gc-updates/ <https://inside.java/2021/09/17/jdk-17-gc-updates/>* * ZGC - What's new in JDK 17** o *https://inside.java/2021/10/05/zgc-in-jdk17/ <https://inside.java/2021/10/05/zgc-in-jdk17/>* * JDK 17 Security Enhancements** o *https://inside.java/2021/09/15/jdk-17-security-enhancements/ <https://inside.java/2021/09/15/jdk-17-security-enhancements/>* * The Vector API in JDK 17 (video)** o *https://inside.java/2021/09/23/devlive-vector-api/ <https://inside.java/2021/09/23/devlive-vector-api/>* * Faster Charset Encoding** o *https://inside.java/2021/10/17/faster-charset-encoding/ <https://inside.java/2021/10/17/faster-charset-encoding/>* _JDK 18:_ * JEP 400 and the Default Charset o https://inside.java/2021/10/04/the-default-charset-jep400/ <https://inside.java/2021/10/04/the-default-charset-jep400/> * JDK 18 augmented `javac -Xlint:serial` checks o https://inside.java/2021/10/20/augmented-serial-checks <https://inside.java/2021/10/20/augmented-serial-checks/> _Project Panama - Foreign Function & Memory API:_ * Finalizing the Foreign APIs o https://inside.java/
Re: Need help with new versions in bugzilla for Ant
On 19/10/21 9:37 pm, Stefan Bodewig wrote: On 2021-10-19, Jaikiran Pai wrote: Can someone with access to Bugzilla please create a new 1.10.12 product version and a new 1.10.13 milestone version, for Ant? Done. Thank you Stefan. I don't think anybody else of the project team has enough karma. We may want to change that. Is that a request we send to infra team? Or is it something that you can do in Bugzilla? Either way, I am willing to take up this role since it will help me whenever I do releases. The only other time I think I might use/need this karma is to delete the spam issues that keep getting created once in a while. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[ANNOUNCE] Apache Ant 1.10.12 released
The Apache Ant Team is pleased to announce the release of Apache Ant 1.10.12. Apache Ant is a Java library and command-line tool that helps building software. The Apache Ant team currently maintains two lines of development. The 1.9.x releases require Java 5 at runtime and 1.10.x requires Java 8 at runtime. Both lines are based off of Ant 1.9.7 and the 1.9.x releases are mostly bug fix releases while additional new features are developed for 1.10.x. We recommend using 1.10.12 unless you are required to use versions of Java prior to Java 8 during the build process. Ant 1.10.12 is mainly a bug fix release. Source and binary distributions are available for download from the Apache Ant download site: https://ant.apache.org/bindownload.cgi https://ant.apache.org/srcdownload.cgi When downloading, please verify signatures using the KEYS file available at the above location. Changes in 1.10.12 are as follows: Fixed bugs: --- * The http condition would follow redirects even when "followRedirects" attribute was set to "false". This has now been fixed. Bugzilla Report 65489 * Made sure setting build.compiler to the fully qualified classname that corresponds to extJavac or modern has the same effect as using the shorter alias names. Bugzilla Report 65539 * Prevent potential deadlocks in org.apache.tools.ant.IntrospectionHelper. Bugzilla Report 65424 Other changes: -- * The implementation of AntClassLoader#findResources() has been changed to optimize it for potential performance issues, as those noted at https://issues.jenkins.io/browse/JENKINS-22310?focusedCommentId=197405&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-197405 Github Pull Request #151 * AntClassLoader now implements the ClassLoader#findResource(String) method. Github Pull Request #150 * Ant tries to avoid file name canonicalization when possible. Bugzilla Report 65499 * javadoc task will now look for warning messages in the STDERR stream too when "failonwarning" is set to true to account for changes in JDK 17+ * The tar task now preserves symlinks of nested tarfilesets. Github Pull Request #142 -Jaikiran (on behalf of Apache Ant team) - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Need help with new versions in bugzilla for Ant
Can someone with access to Bugzilla please create a new 1.10.12 product version and a new 1.10.13 milestone version, for Ant? I'm almost done with the rest of the release formalities and will send the release annonucement later today. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [RESULT] Release Apache Ant 1.10.12 based on RC2
With +1s from: - Stefan - Maarten - Jaikiran and no other votes, this release vote has now *passed*. Thank you all for voting, both on this one and the previous RC1. I'll move forward with the rest of the process shortly. -Jaikiran On 18/10/21 2:52 pm, Maarten Coene wrote: +1 Maarten Op zondag 17 oktober 2021 09:02:30 CEST schreef Jaikiran Pai : +1. - Used this version to build some of our internal projects. - Checked some random manuals. All looks fine. -Jaikiran On 13/10/21 11:05 am, Jaikiran Pai wrote: I've created a new RC2 release candidate for 1.10.12: git tag: ANT_1.10.12_RC2 on commit: 4b420359942dfb1221f308d08f3648712fea9f83 tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 50387 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1052 Snapcraft Build Revision 22 in latest/candidate This vote will be open for at least 72 hours and close no earlier than 16th October 2021 05:30 AM UTC. -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 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Apache Ant 1.10.12 based on RC2
+1. - Used this version to build some of our internal projects. - Checked some random manuals. All looks fine. -Jaikiran On 13/10/21 11:05 am, Jaikiran Pai wrote: I've created a new RC2 release candidate for 1.10.12: git tag: ANT_1.10.12_RC2 on commit: 4b420359942dfb1221f308d08f3648712fea9f83 tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 50387 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1052 Snapcraft Build Revision 22 in latest/candidate This vote will be open for at least 72 hours and close no earlier than 16th October 2021 05:30 AM UTC. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[VOTE] Release Apache Ant 1.10.12 based on RC2
I've created a new RC2 release candidate for 1.10.12: git tag: ANT_1.10.12_RC2 on commit: 4b420359942dfb1221f308d08f3648712fea9f83 tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 50387 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1052 Snapcraft Build Revision 22 in latest/candidate This vote will be open for at least 72 hours and close no earlier than 16th October 2021 05:30 AM UTC. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[CANCELLED] [VOTE] Release Apache Ant 1.10.12 based on RC1
A couple of issues have been raised with the current RC1 release that is being voted upon: - Extra files in the source archive which weren't present in previous versions - Mismatch in the version numbers of BCEL and commons-net dependencies between the libraries.properties and the pom.xml files. As a result, I will cancel this vote and will initiate a new vote which should include these fixes, shortly. Thank you all for voting and testing the release artifacts. Sorry about the delay in my responses this week - it has been a busy week at work. -Jaikiran On 07/10/21 7:51 pm, Jaikiran Pai wrote: Hello Paul, On 05/10/21 2:27 pm, Paul King wrote: I was surprised to see binary jars in the src archives under lib/optional. I don't know the history, so perhaps it is fine. Thank you for testing this release. I had a look at our previous releases and they too contain the binary jars in the source archives. So it appears to be historical. Having said that, the current release appears to include a few more binary jars in the source archive's lib/optional as compared to a previous release. I'll spend time on this tomorrow to see if that's OK or if I have to regenerate the source archives. Thank you very much for bringing it to attention. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Apache Ant 1.10.12 based on RC1
On 07/10/21 11:27 am, Gintautas Grigelionis wrote: If the goal of 1.10.12 is to be compilable on Java 17, This 1.10.12 release of Ant (like our previous releases) is a bug fix release. Ant 1.10.x require a Java 8+ runtime. This release changes nothing on that front. One of the bug fixes in this release is a javadoc task fix that is only applicable for Java 17 - that's the only "relevance" of Java 17 to this release. Like previous 1.10.x releases we have been making sure users and projects using Ant can use Ant to build their projects using latest Java versions of their choice. shouldn't unit tests for script-related tasks in Ant core be complemented with an assumption that Rhino, Nashorn or Graal JS is around? I'm not sure what kind of assumption you mean. Is there any specific test case you have in mind? Our CI jobs run against various versions of Java, including early access releases and even the recently released Java 17. None of our tests have shown any relevant failures in these releases. If this is more of a general suggestion for our test cases in Ant and if this doesn't have an impact on the vote of this release, please create a separate thread to discuss that. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Apache Ant 1.10.12 based on RC1
Hello Paul, On 05/10/21 2:27 pm, Paul King wrote: I was surprised to see binary jars in the src archives under lib/optional. I don't know the history, so perhaps it is fine. Thank you for testing this release. I had a look at our previous releases and they too contain the binary jars in the source archives. So it appears to be historical. Having said that, the current release appears to include a few more binary jars in the source archive's lib/optional as compared to a previous release. I'll spend time on this tomorrow to see if that's OK or if I have to regenerate the source archives. Thank you very much for bringing it to attention. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Apache Ant 1.10.12 based on RC1
I'll need one more PMC member's vote on this for me to move forward. Anyone have some time this week to test this? -Jaikiran On 03/10/21 3:23 pm, Stefan Bodewig wrote: On 2021-09-30, Jaikiran Pai wrote: This release is mainly a bug fix release and the exact changes are noted in https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.12.html. Of particular interest is the relatively minor bug fix in the javadoc task which is necessary for it to work properly in the recently released Java 17 version. +1 Stefan - 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
Re: [VOTE] Release Apache Ant 1.10.12 based on RC1
+1 - Downloaded the .tar.gz binary - Checked the NOTICE file and some random manuals - Built internal projects using Java 8 and this version of Ant - Built some sample projects with Java 17 and this version Ant All looks fine. -Jaikiran On 30/09/21 8:28 am, Jaikiran Pai wrote: I've created a release candidate for 1.10.12: git tag: ANT_1.10.12_RC1 on commit: cb7f242aa099c069bd75e6ee4d6e50b56fd73b71 tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 50166 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1051/ Snapcraft Build Revision 21 in latest/candidate This release is mainly a bug fix release and the exact changes are noted in https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.12.html. Of particular interest is the relatively minor bug fix in the javadoc task which is necessary for it to work properly in the recently released Java 17 version. This vote will be open at least for 72 hours and close no earlier than 4th October 2021 03:00 AM UTC (given that it's a weekend in the next couple of days, I decided to extend the voting period till Monday) -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[VOTE] Release Apache Ant 1.10.12 based on RC1
I've created a release candidate for 1.10.12: git tag: ANT_1.10.12_RC1 on commit: cb7f242aa099c069bd75e6ee4d6e50b56fd73b71 tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 50166 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1051/ Snapcraft Build Revision 21 in latest/candidate This release is mainly a bug fix release and the exact changes are noted in https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.12.html. Of particular interest is the relatively minor bug fix in the javadoc task which is necessary for it to work properly in the recently released Java 17 version. This vote will be open at least for 72 hours and close no earlier than 4th October 2021 03:00 AM UTC (given that it's a weekend in the next couple of days, I decided to extend the voting period till Monday) -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Release 1.10.12 of Ant?
On 28/09/21 12:55 pm, Stefan Bodewig wrote: On 2021-09-26, Jaikiran Pai wrote: I was planning to initiate a release tonight, but trying to upgrade one of the optional dependencies has shown up some interesting issue in the maven ant task (which apparently has been EOLed[1]) that we use in our fetch.xml. Maybe you skip upgrading optional dependencies for now? ;-) I looked into that issue in more detail and like you say, skipping this upgrade of optional dependencies is what I will do. The fix will involve bigger changes and not something that's needed or a blocker for this release. I'll send out a separate mail about what that issue is. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Release 1.10.12 of Ant?
On 19/09/21 3:30 pm, Stefan Bodewig wrote: On 2021-09-16, Stefan Bodewig wrote: On 2021-09-15, Jaikiran Pai wrote: I wanted to look into and sort out https://bz.apache.org/bugzilla/show_bug.cgi?id=65424 in this release too, but it looks like I may not be able to do that and I'm not sure how many more days I'll need to get to that issue. The coming weekend I may (or may not) find some time to lend a hand. I believe the HELPERS Hashtable (as well as others) in IntrospecitonHelper could be replaced with a ConcurrentHashMap and some synchronization could be removed if we really want to do that. Unlike some other parts of Ant we don't expose the data structures in public APIs. Actually forget the ConcurrentHashMap thought for now, I'll comment in the ticket with a more detailed answer. Thank you Stefan for reviewing this fix. I was planning to initiate a release tonight, but trying to upgrade one of the optional dependencies has shown up some interesting issue in the maven ant task (which apparently has been EOLed[1]) that we use in our fetch.xml. I'll try and sort that one out first and see what we can do there. I still hope to trigger a release this coming week. [1] https://maven.apache.org/ant-tasks/ -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Release 1.10.12 of Ant?
Java 17 has been released yesterday. We have a relatively minor fix in javadoc task which affects Java 17 in cases where failonwarn=true. Should we consider releasing 1.10.12 of Ant in upcoming days to provide this fix and other fixes that we have done since 1.10.11 release? I wanted to look into and sort out https://bz.apache.org/bugzilla/show_bug.cgi?id=65424 in this release too, but it looks like I may not be able to do that and I'm not sure how many more days I'll need to get to that issue. If anyone else has the time and interest to look into that one, please feel free to do so - I haven't done any real work on that one yet. Are there any other issues that others are working on and want to be part of this release? -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Release Announcement: General Availability of Java 17 / JDK 17
Hello Rory, Congratulations on the Java 17 release. I've run Java 17 build 17+35-2724 and Java 18 build 18-ea+14-756 against our Ant testsuite on Linux and all tests have passed without issues: https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20(latest%20EA%20JDK)/80/jdk_axis=jdk17_ea,label_exp=ubuntu/ https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20(latest%20EA%20JDK)/80/jdk_axis=jdk18_ea,label_exp=ubuntu/ -Jaikiran On 14/09/21 8:37 pm, Rory O'Donnell wrote: Hi Stefan/Jaikiran, *Release Announcement: General Availability of Java 17 / JDK 17 * ** * JDK 17, the reference implementation of Java 17, is now Generally Available. [1] * GPL-licensed OpenJDK builds from Oracle are available here: https://jdk.java.net/17/ <https://jdk.java.net/17/> * JDK 17 Release notes <https://www.oracle.com/java/technologies/javase/17-relnotes.html> * Inside Java: The Arrival of Java 17! <https://inside.java/2021/09/14/the-arrival-of-java17/> *JDK 17 includes the following features [2]:* * JEP 306: Restore Always-Strict Floating-Point Semantics <https://openjdk.java.net/jeps/306> * JEP 356: Enhanced Pseudo-Random Number Generators <https://openjdk.java.net/jeps/356> * JEP 382: New macOS Rendering Pipeline <https://openjdk.java.net/jeps/382> * JEP 391: macOS/AArch64 Port <https://openjdk.java.net/jeps/391> * JEP 398: Deprecate the Applet API for Removal <https://openjdk.java.net/jeps/398> * JEP 403: Strongly Encapsulate JDK Internals <https://openjdk.java.net/jeps/403> * JEP 406: Pattern Matching for switch (Preview) <https://openjdk.java.net/jeps/406> * JEP 407: Remove RMI Activation <https://openjdk.java.net/jeps/407> * JEP 409: Sealed Classes <https://openjdk.java.net/jeps/409> * JEP 410: Remove the Experimental AOT and JIT Compiler <https://openjdk.java.net/jeps/410> * JEP 411: Deprecate the Security Manager for Removal <https://openjdk.java.net/jeps/411> * JEP 412: Foreign Function & Memory API (Incubator) <https://openjdk.java.net/jeps/412> * JEP 414: Vector API (Second Incubator) <https://openjdk.java.net/jeps/414> * JEP 415: Context-Specific Deserialization Filters <https://openjdk.java.net/jeps/415> *JDK 17 will be a long-term-support (LTS) release* from most vendors,including Oracle. If you’re upgrading from the previous LTS release,JDK 11, then you have many more JEPs to look forward to, summarized here: https://openjdk.java.net/jdk/17/jeps-since-jdk-11 <https://openjdk.java.net/jdk/17/jeps-since-jdk-11> Thanks to everyone who contributed to JDK 17, whether by creating features or enhancements, logging bugs, or downloading and testing the early-access builds. *OpenJDK 18 Early Access build 14 is now available at https://jdk.java.net/18/ <https://jdk.java.net/18/> * * These early access, open source builds are provided under the GNU General Public License, version 2, with the Classpath Exception <https://openjdk.java.net/legal/gplv2+ce.html>. * JEPs targeted to JDK 18, so far: o JEP 400: UTF-8 by Default <https://openjdk.java.net/jeps/400> o JEP 413: Code Snippets in Java API Documentation <https://openjdk.java.net/jeps/413> * Release Notes are available at https://jdk.java.net/18/release-notes <https://jdk.java.net/18/release-notes> * Significant changes since the last availability email: o JDK-8271745: Fix Issues With the KW and KWP Modes of SunJCE Provider o JDK-8262186: Call X509KeyManager.chooseClientAlias once for all key types o JDK-8225083: Remove Google certificate that is expiring in December 2021 o JDK-8251329: Zip File System Provider Throws ZipException when entry name element contains "." or ".." o JDK-8225082: Remove IdenTrust certificate that is expiring in September 2021 o *Project Loom Early-Access Builds* * Build 18-loom+2-74 (2021/8/7) based on jdk-18+9 <https://github.com/openjdk/jdk/releases/tag/jdk-18%2B9> is available - https://jdk.java.net/loom/ <https://jdk.java.net/loom/> * These early access, open source builds are provided under the GNU General Public License, version 2, with the Classpath Exception <https://openjdk.java.net/legal/gplv2+ce.html>. * Please send feedback via e-mail to loom-...@openjdk.java.net <mailto:loom-...@openjdk.java.net>. To send e-mail to this address you must first subscribe to the mailing list <https://mail.openjdk.java.net/mailman/listinfo/loom-dev>. Rgds,Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/006037.html [2] https://openjdk.java.net/projects/jdk/17/ <https://openjdk.java.net/projects/jdk/17/> - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Upcoming Java 17 release will have an impact on our javadoc task
Hello Stefan, On 27/06/21 4:10 pm, Stefan Bodewig wrote: On 2021-06-17, Jaikiran Pai wrote: So right now I don't have specific proposals for fixing this but just a note that we will have to look into this one for the upcoming JDK 17 release. I guess we can simply concatenate stderr and stdout and look for the "warnings" message there. This should work for every version of Java supported by Ant. I went ahead and implemented this suggestion. It took me a while to implement this because I noticed that javadoc tool itself exposes a way to fail on warning https://bugs.openjdk.java.net/browse/JDK-8200363 (-Xwerror in JDK8 and -Werror on recent versions). I wanted to try and use it in our javadoc task, but it turned out not to be straightforward since we need to add javadoc tool version checks to get it to work in all versions of the tool. Plus, even after adding that option, if our javadoc task's "failonerror" is set to false (which is the default), the task will still not fail when it sees a warning. Considering all this, I decided looking for the warning in both stderr and stdout is the most consistent way to get this working. -Jaikiran - 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 23/08/21 9:17 pm, Stefan Bodewig wrote: 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. Yes, that's correct. There's no specific timeline specified for the new APIs, so those may or may not come within Java 18 GA time frame. So we have to wait and watch if this is going to impact just Java 18 early access releases or the final GA release too. This is not exactly the user experience I'd be hoping for, but so be it. Agreed. At this point, it's clear that, for us to be able to start consuming Java 18 early access releases in the coming weeks, we need to start passing around the "allow" value for the "java.security.manager" system property. Otherwise, we won't be able to test any of the other non-security manager related stuff that comes in, in these releases, because the bootstrapping of the task itself will start failing. I'll start taking a look at how involved this change is going to be. -Jaikiran - 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
Re: Impact of Java SecurityManager being deprecated for removal post Java 17
On 19/08/21 1:15 pm, Stefan Bodewig wrote: On 2021-08-05, Jaikiran Pai wrote: Ant project will be impacted by this. Ant provides a "permissions" type[1] whose whole goal is to integrate with the Java SecurityManager to allow users to configure the necessary security permissions. With the SecurityManager and the APIs potentially gone after Java 17, we can no longer support this. One additional point to note here is that, Ant also uses the SecurityManager APIs even when "permissions" type is not involved, at least in the "java" task and the "junit" task, where we setup a SecurityManager with very minimal permissions. ... One migration option might be to offer an antlib containing the permissions stuff and deprecate the core types - and remove them from core once the next Java LTS version without SecurityManager arrives. This is an interesting point. It would however mean that core Ant will now depend on an (in theory external) antlib. I haven't checked if we already have such dependencies and if not, whether it's OK to add such a dependency. Furthermore, to make this usable/backward compatible, we would have to use the same package namespace for this permissions stuff in that new antlib jar, which I think can cause issues when the same package "org.apache.tools.ant.types" is now loaded/available in 2 separate CodeSources (jars) - one in core Ant jar and one in this antlib jar. - 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
Hello Stefan, On 19/08/21 1:15 pm, Stefan Bodewig wrote: On 2021-08-05, Jaikiran Pai wrote: Ant project will be impacted by this. Ant provides a "permissions" type[1] whose whole goal is to integrate with the Java SecurityManager to allow users to configure the necessary security permissions. With the SecurityManager and the APIs potentially gone after Java 17, we can no longer support this. One additional point to note here is that, Ant also uses the SecurityManager APIs even when "permissions" type is not involved, at least in the "java" task and the "junit" task, where we setup a SecurityManager with very minimal permissions. 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]. After this is done, when it then calls the ExecuteJava class it finds this non-null Permissions instance and ends up setting up the SecurityManager using the security manager APIs[4]. Effectively, even if users haven't configured any permissions, we end up using a security manager. [1] https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/taskdefs/Java.java [2] https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/taskdefs/Java.java#L142 [3] https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/taskdefs/Java.java#L205 [4] https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/taskdefs/ExecuteJava.java#L215 -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: JDK 17 is now in the Release Candidate Phase
Hello Rory, I ran our Ant testsuite on a Linux setup against both Java 17 and Java 18 EA releases. No new issues noticed and things look fine. -Jaikiran On 07/08/21 8:23 pm, Rory O'Donnell wrote: Hi Stefan/Jaikiran, *Per the JDK 17 schedule , we are now in the Release Candidate Phase [1][2].* * * *Please advise if you find any issues while testing the latest Early Access builds.* * Schedule: o *2021/08/05 Initial Release Candidate * o 2021/08/19 Final Release Candidate o 2021/09/14 General Availability The overall feature set is frozen. No further JEPs will be targeted to this release. * Features integrated in JDK 17: o JEP 306: Restore Always-Strict Floating-Point Semantics <https://openjdk.java.net/jeps/306> o JEP 356: Enhanced Pseudo-Random Number Generators <https://openjdk.java.net/jeps/356> o JEP 382: New macOS Rendering Pipeline <https://openjdk.java.net/jeps/382> o JEP 391: macOS/AArch64 Port <https://openjdk.java.net/jeps/391> o JEP 398: Deprecate the Applet API for Removal <https://openjdk.java.net/jeps/398> o JEP 403: Strongly Encapsulate JDK Internals <https://openjdk.java.net/jeps/403> o JEP 406: Pattern Matching for switch (Preview) <https://openjdk.java.net/jeps/406> o JEP 407: Remove RMI Activation <https://openjdk.java.net/jeps/407> o JEP 409: Sealed Classes <https://openjdk.java.net/jeps/409> o JEP 410: Remove the Experimental AOT and JIT Compiler <https://openjdk.java.net/jeps/410> o JEP 411: Deprecate the Security Manager for Removal <https://openjdk.java.net/jeps/411> o JEP 412: Foreign Function & Memory API (Incubator) <https://openjdk.java.net/jeps/412> o JEP 414: Vector API (Second Incubator) <https://openjdk.java.net/jeps/414> o JEP 415: Context-Specific Deserialization Filters <https://openjdk.java.net/jeps/415> * * *OpenJDK 17 Early Accessbuild 35 is available at **https://jdk.java.net/17* <https://jdk.java.net/17> * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <https://openjdk.java.net/legal/gplv2+ce.html> * Release Notes are available at https://jdk.java.net/17/release-notes <https://jdk.java.net/17/release-notes> * Changes in recent builds that maybe of interest: o JDK-8270866: NPE in DocTreePath.getTreePath()[build 33] + Reportedby jOOQ **Topics of Interest: * * * The latest Newscast covers 17's JEP 356 <https://openjdk.java.net/jeps/356>: Enhanced Pseudo-Random Number Generators - Here <https://inside.java/2021/07/29/insidejava-newscast-009/> * The latest JEP Café cover 17's JEP 409 <https://openjdk.java.net/jeps/409> : Sealed Classes - Here <https://inside.java/2021/07/22/jepcafe2/> * A few updates to JEP 411 <https://openjdk.java.net/jeps/411>: Deprecate the Security Manager for Removal - Here <https://mail.openjdk.java.net/pipermail/security-dev/2021-July/026806.html> * * *OpenJDK**18 Early Access build 9 is available at **https://jdk.java.net/18* <https://jdk.java.net/18> * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <https://openjdk.java.net/legal/gplv2+ce.html> * Release Notes are available at https://jdk.java.net/18/release-notes <https://jdk.java.net/18/release-notes> * Changes in recent builds that maybe of interest: o JDK-8225082: Remove IdenTrust certificate that is expiring in September 2021 [build 9] o JDK-8251329: Zip File System Provider Throws ZipException when entry name element contains "." or ".." [build 9] o JDK-8271359: NPE in DocTreePath.getTreePath() [build 8] + Reported by jOOQ *July 2021 Critical Patch Update Released* * As part of the July 2021, we released JDK 16.0.2, JDK 11.0.12 LTS, JDK 8u301 and JDK 7u311 as well as OpenJDK 16.0.2 (publicly available) Rgds,Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-August/005894.html [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-August/005906.html - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Impact of Java SecurityManager being deprecated for removal post Java 17
Hello everyone, Some of you might have been following the recent discussions in JDK where the SecurityManager and related APIs will be deprecated (for removal) starting the upcoming Java 17 release. To be clear, this change in Java will have no impact in terms of API usage in Java 17 (except for warnings being logged). However, after Java 17, these APIs may not exist. The whole JEP is available at https://openjdk.java.net/jeps/411. Ant project will be impacted by this. Ant provides a "permissions" type[1] whose whole goal is to integrate with the Java SecurityManager to allow users to configure the necessary security permissions. With the SecurityManager and the APIs potentially gone after Java 17, we can no longer support this. One additional point to note here is that, Ant also uses the SecurityManager APIs even when "permissions" type is not involved, at least in the "java" task and the "junit" task, where we setup a SecurityManager with very minimal permissions. When a EA release of Java 17 was tested against the Ant project, it exposed issues around the amount of warning messages that were being logged by the new Java release for basic Ant builds. The JDK team took that input and fixed that part. Discussion about that can be seen in this thread[2]. At this stage, the dust seems to have settled about the plans around SecurityManager in the JDK and it's clear that it will be gone post Java 17. We (the Ant project) will have to decide and come up with a way where we (the Ant project) will no longer support "permissions" or use SecurityManager APIs post Java 17. I personally haven't been involved in the original SecurityManager integration in Ant and don't have enough background knowledge about this part in Ant nor do I know how many of our users use the "permissions" type or rely on SecurityManager (I was in fact unaware we even had a "permissions" type, until I decided to dig around our code recently to see if/how we will be impacted by SecurityManager API changes). Given this, I would like to have some discussion on how we should proceed with this. [1] https://ant.apache.org/manual/Types/permissions.html [2] https://mail.openjdk.java.net/pipermail/security-dev/2021-June/026660.html -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: JDK 17 is now in Rampdown Phase Two
Hello Rory, We ran this against our Ant project and no new issues have been observed with both these JDK 17 and 18 EA builds. -Jaikiran On 16/07/21 12:51 am, Rory O'Donnell wrote: Hi Stefan/Jaikiran, *Per the JDK 17 schedule , we are in Rampdown Phase Two [1].* *Please advise if you find any issues while testing the latest Early Access builds.* * Schedule: o *2021/07/15 Rampdown Phase Two* o 2021/08/05 Initial Release Candidate o 2021/08/19 Final Release Candidate o 2021/09/14 General Availability The overall feature set is frozen. No further JEPs will be targeted to this release. * Features integrated in JDK 17: o JEP 306: Restore Always-Strict Floating-Point Semantics <https://openjdk.java.net/jeps/306> o JEP 356: Enhanced Pseudo-Random Number Generators <https://openjdk.java.net/jeps/356> o JEP 382: New macOS Rendering Pipeline <https://openjdk.java.net/jeps/382> o JEP 391: macOS/AArch64 Port <https://openjdk.java.net/jeps/391> o JEP 398: Deprecate the Applet API for Removal <https://openjdk.java.net/jeps/398> o JEP 403: Strongly Encapsulate JDK Internals <https://openjdk.java.net/jeps/403> o JEP 406: Pattern Matching for switch (Preview) <https://openjdk.java.net/jeps/406> o JEP 407: Remove RMI Activation <https://openjdk.java.net/jeps/407> o JEP 409: Sealed Classes <https://openjdk.java.net/jeps/409> o JEP 410: Remove the Experimental AOT and JIT Compiler <https://openjdk.java.net/jeps/410> o JEP 411: Deprecate the Security Manager for Removal <https://openjdk.java.net/jeps/411> o JEP 412: Foreign Function & Memory API (Incubator) <https://openjdk.java.net/jeps/412> o JEP 414: Vector API (Second Incubator) <https://openjdk.java.net/jeps/414> o JEP 415: Context-Specific Deserialization Filters <https://openjdk.java.net/jeps/415> * * *OpenJDK 17 Early Access build 31 is available at **https://jdk.java.net/17* <https://jdk.java.net/17> * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <https://openjdk.java.net/legal/gplv2+ce.html> * Release Notes are available at https://jdk.java.net/17/release-notes <https://jdk.java.net/17/release-notes> * * *OpenJDK 18 Early Access build 6 is available at * *https://jdk.java.net/18* <https://jdk.java.net/18> * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <https://openjdk.java.net/legal/gplv2+ce.html> * Release Notes are available at https://jdk.java.net/18/release-notes <https://jdk.java.net/18/release-notes> * Changes in recent builds that maybe of interest: o JDK-8269697: JNI_GetPrimitiveArrayCritical() should not accept object array [build 6] o JDK-8253119: Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation [build 6] o JDK-8268960: Prohibit Null for Header Keys and Values in com.sun.net.httpserver.Headers [build 5] o JDK-8256425: Obsolete Biased Locking in JDK 18 [build 4] *Topics of Interest: * * ‘Inside Java’ Podcast #18: Java's steady march towards strong encapsulation <https://inside.java/2021/06/29/podcast-018/> Rgds,Rory [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-July/005752.html <https://mail.openjdk.java.net/pipermail/jdk-dev/2021-July/005752.html> - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Apache Ant 1.9.15 based on RC1
+1. Downloaded .tar.gz binary. Checked some manuals and the NOTICE file. Used this version to build some of our internal projects. All went fine. -Jaikiran On 10/07/21 11:43 pm, Stefan Bodewig wrote: Hi all I've created a release candidate for 1.9.16: git tag: ANT_1.9.16_RC1 on commit: ea698c454 tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 48766 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1049/org/apache/ant/ Cheers Stefan - 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
Re: [VOTE] Release Apache Ant 1.10.11 based on RC1
+1. Downloaded the .tar.gz binary, checked the NOTICE file, some manuals and built our internal projects using this new version. All went fine. -Jaikiran On 11/07/21 12:21 am, Stefan Bodewig wrote: Hi all I've created a release candidate for 1.10.11: git tag: ANT_1.10.11_RC1 on commit: 01ce0c3b1 tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 48767 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1049/org/apache/ant/ Cheers Stefan - 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
Re: [VOTE] Release Apache AntUnit 1.4.1 based on RC1
+1. Did some basic verification: - Downloaded apache-ant-antunit-1.4.1-bin.tar.gz from https://dist.apache.org/repos/dist/dev/ant/antlibs/antunit/binaries/ - Extracted locally. Checked the NOTICE file. - Checked the WHATSNEW file. - Checked the docs/index.html - Checked that ant-antunit-1.4.1.jar is present - Verified the ant-antunit-1.4.1.jar.sha512 checksum is correct. No issues found. -Jaikiran On 03/07/21 6:11 pm, Stefan Bodewig wrote: Hi all I've created a release candidate for AntUnit 1.4.1: git tag: 1_4_1_RC1 on commit: e436acf tarballs: https://dist.apache.org/repos/dist/dev/ant/antlibs/antunit/ revision: 48645 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1048/org/apache/ant/ant-antunit/1.4.1/ This Vote will be open at least for 72 hours and close no earlier than 2021-07-06 13:00UTC. Cheers Stefan - 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
Re: new warnings produced by task under Open JDK 17-ea+28-2534
I spent some time on this today and experimented with some sample build scripts and I noticed that these warning messages are a lot more intrusive in their current form than what I had initially thought or noticed. Based on your and one other user's inputs so far, I've raised a discussion in security-dev mailing list of OpenJDK, explaining how this is currently impacting Ant project and some potential ways to reduce this impact. The discussion thread is here https://mail.openjdk.java.net/pipermail/security-dev/2021-June/026660.html -Jaikiran On 28/06/21 8:22 pm, Rick Hillegas wrote: Thanks for that explanation, Jaikiran. On 6/27/21 8:29 PM, Jaikiran Pai wrote: Hello Rick, Thank you for this report. We have been watching this area and have been aware of this issue, including one other user report[1]. I'm just waiting for things to become a bit more clear on this front before coming up with any proposal in the Ant project on how to deal with this. Clearly our permissions[2] type and the whole security manager based implementation will be impacted and needs a rethink. For the java task, we by default apply certain permissions when run without "fork". That's what is triggering this warning. It has been there in the build 26 EA of JDK 17 as well - of course, that version didn't include the exact class which was calling the System.setSecurityManager. That additional detail got included recently[3]. [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=65381 [2] http://ant.apache.org/manual/Types/permissions.html [3] https://github.com/openjdk/jdk17/pull/13 -Jaikiran On 27/06/21 11:22 pm, Rick Hillegas wrote: Open JDK 17 build 17-ea+28-2534 causes the ant 1.10.6 task to produce the following warnings when you DON'T fork the JVM: WARNING: A terminally deprecated method in java.lang.System has been called WARNING: System::setSecurityManager has been called by org.apache.tools.ant.types.Permissions (file:/opt/ant/lib/ant.jar) For more information, see https://issues.apache.org/jira/browse/DERBY-7110?focusedCommentId=17370259&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17370259 and https://issues.apache.org/jira/browse/DERBY-7110?focusedCommentId=17370302&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17370302 - 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 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: new warnings produced by task under Open JDK 17-ea+28-2534
Hello Rick, Thank you for this report. We have been watching this area and have been aware of this issue, including one other user report[1]. I'm just waiting for things to become a bit more clear on this front before coming up with any proposal in the Ant project on how to deal with this. Clearly our permissions[2] type and the whole security manager based implementation will be impacted and needs a rethink. For the java task, we by default apply certain permissions when run without "fork". That's what is triggering this warning. It has been there in the build 26 EA of JDK 17 as well - of course, that version didn't include the exact class which was calling the System.setSecurityManager. That additional detail got included recently[3]. [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=65381 [2] http://ant.apache.org/manual/Types/permissions.html [3] https://github.com/openjdk/jdk17/pull/13 -Jaikiran On 27/06/21 11:22 pm, Rick Hillegas wrote: Open JDK 17 build 17-ea+28-2534 causes the ant 1.10.6 task to produce the following warnings when you DON'T fork the JVM: WARNING: A terminally deprecated method in java.lang.System has been called WARNING: System::setSecurityManager has been called by org.apache.tools.ant.types.Permissions (file:/opt/ant/lib/ant.jar) For more information, see https://issues.apache.org/jira/browse/DERBY-7110?focusedCommentId=17370259&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17370259 and https://issues.apache.org/jira/browse/DERBY-7110?focusedCommentId=17370302&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17370302 - 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
Re: JDK 17 Early Access build 28 & JDK 18 build 3 are available
Hello Rory, I ran JDK 17 EA (build 17-ea+28-2534) against our Ant testsuite on a linux setup and apart from the one failure[1] that is a result on the intentional change in javadoc tool[2], rest all tests passed fine. We (the Ant project) will sort out the javadoc issue in the coming weeks. [1] https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20(latest%20EA%20JDK)/jdk_axis=jdk17_ea,label_exp=ubuntu/75/testReport/src.tests.antunit.taskdefs/javadoc-test_xml/testFailOnWarning/ [2] https://mail.openjdk.java.net/pipermail/javadoc-dev/2021-June/003075.html -Jaikiran On 25/06/21 1:47 pm, Rory O'Donnell wrote: Hi Stefan/Jaikiran, ** * * *Per the JDK 17 schedule , we are in Rampdown Phase One.* *Please advise if you find any issues while testing the latest Early Access builds.* The overall feature set is frozen. No further JEPs will be targeted to this release. * Features integrated in JDK 17: o JEP 306: Restore Always-Strict Floating-Point Semantics <https://openjdk.java.net/jeps/306> o JEP 356: Enhanced Pseudo-Random Number Generators <https://openjdk.java.net/jeps/356> o JEP 382: New macOS Rendering Pipeline <https://openjdk.java.net/jeps/382> o JEP 391: macOS/AArch64 Port <https://openjdk.java.net/jeps/391> o JEP 398: Deprecate the Applet API for Removal <https://openjdk.java.net/jeps/398> o JEP 403: Strongly Encapsulate JDK Internals <https://openjdk.java.net/jeps/403> o JEP 406: Pattern Matching for switch (Preview) <https://openjdk.java.net/jeps/406> o JEP 407: Remove RMI Activation <https://openjdk.java.net/jeps/407> o JEP 409: Sealed Classes <https://openjdk.java.net/jeps/409> o JEP 410: Remove the Experimental AOT and JIT Compiler <https://openjdk.java.net/jeps/410> o JEP 411: Deprecate the Security Manager for Removal <https://openjdk.java.net/jeps/411> o JEP 412: Foreign Function & Memory API (Incubator) <https://openjdk.java.net/jeps/412> o JEP 414: Vector API (Second Incubator) <https://openjdk.java.net/jeps/414> o JEP 415: Context-Specific Deserialization Filters <https://openjdk.java.net/jeps/415> *OpenJDK 17 Early Access build 28 is available at **https://jdk.java.net/17* <https://jdk.java.net/17> * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <https://openjdk.java.net/legal/gplv2+ce.html> * Release Notes are available at https://jdk.java.net/17/release-notes <https://jdk.java.net/17/release-notes> * Changes in build 28 that maybe of interest: o *JDK-8269028: [BACKOUT] JDK-8196415 Disable SHA-1 Signed JARs * o JDK-8268774: Residual logging output written to STDOUT, not STDERR [*Reported by Apache Ant*] o JDK-8264843: Javac crashes with NullPointerException when finding unencoded XML in tag [*Reported by Apache Lucene*] *OpenJDK 18 Early Access build 3 is now available at **https://jdk.java.net/18* <https://jdk.java.net/18> * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <https://openjdk.java.net/legal/gplv2+ce.html> * Changes in recent builds that maybe of interest: o JDK-8266791: Annotation property which is compiled as an array property but changed to a single element throws NPE [*Reported by Byte Buddy*] * Coming in a future JDK 18 build o Removal of Biased Locking in JDK 18 - Details <https://github.com/openjdk/jdk/pull/4522> *Other Topics of Interest: * * State of Loom: https://www.youtube.com/watch?v=KG24inClY2M <https://www.youtube.com/watch?v=KG24inClY2M> * State of Panama: https://www.youtube.com/watch?v=B8k9QGvPxC0 <https://www.youtube.com/watch?v=B8k9QGvPxC0> * What's a JEP: https://www.youtube.com/watch?v=l1VrmvyIEpM <https://www.youtube.com/watch?v=l1VrmvyIEpM> *Quality Report for June 2021 was published here [1]. *** * Thanks to everyone who contributed by creating features or enhancements, logging bugs, or downloading and testing the early-access builds. Rgds,Rory [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+June+2021* * - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org