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=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 - JDK-83255
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 from the note text: "A future r
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 - JDK-8305486:
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-8298400:
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 now publishing JavaFX bu
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 possible
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 bind
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 Instant.plusSeconds - JDK-8282420: JFR: Remove e
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 - JDK-8278087: Deserialization filter and filter
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 - To unsubscribe, e
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/ These EA builds are provided
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/2021/09/16/finalizing-the
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=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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17370259 and https://issues.apache.org/jira/browse/DERBY-7110?focusedCommentId=17370302=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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17370259 and https://issues.apache.org/jira/browse/DERBY-7110?focusedCommentId=17370302=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
SecurityManager in Java is being deprecated - Please try your Ant builds against JDK 17 EA builds
Those of you who haven't yet heard, the upcoming JDK 17 release will be deprecating (for future removal) the SecurityManager classes and some of the related infrastructure. The complete details of this proposed change are explained here https://openjdk.java.net/jeps/411. The initial changes around this are already available in an early access release of JDK 17 which is available at https://jdk.java.net/17/ Ant is one of the projects that will be impacted since we internally deal with Java's SecurityManager APIs especially when the "permissions" type https://ant.apache.org/manual/Types/permissions.html is used in Ant builds. I think it would be good to hear from the users of Ant if/how they will be impacted by these changes in the JDK and how severe that impact will be. Please take a look at the JEP and even try out your project builds using the latest early access of JDK and report any issues that you might notice. Please do remember that the proposed change for JDK 17 is making SecurityManager deprecated for future removal and it is _not_ being removed or its behaviour changed in JDK 17 (although you will start seeing some diagnostic warning messages, from the JDK itself, bringing to your attention this deprecation). -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Upcoming Java 17 release will have an impact on our javadoc task
The recently released EA version of JDK 17 has introduced a change in the javadoc tool. Previously (JDK 8 all the way through JDK 16) used to log certain messages from the javadoc tool to STDOUT. Our javadoc task's implementation expects such messages of STDOUT. Starting this JDK EA release the behaviour has changed in the javadoc tool and it now logs those messages to STDERR. This change was discussed in the OpenJDK mailing list[1] and it has been noted that this is an intentional change in the tool. Specifically for the javadoc task in Ant project, it has a "failOnWarning" attribute which fails the task on any "warning" message (actually just the presence of that word) being seen on STDOUT. With this change in JDK, this implementation in our task will no longer work starting JDK 17 (but will still continue to work in previous JDK releases). I haven't yet had a chance to fully review our javadoc task code to see what would be a good way to fix this in a way that would try and avoid Java runtime version checks in the code. 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. [1] https://mail.openjdk.java.net/pipermail/javadoc-dev/2021-June/003075.html -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [External] : Re: JDK 17 is now in Rampdown Phase One
Additionally, more as a FYI - we have started to receive user reports that the new security manager deprecation WARNING messages on System.err are impacting some of their existing build scripts https://bz.apache.org/bugzilla/show_bug.cgi?id=65381 -Jaikiran On 15/06/21 9:51 pm, Jaikiran Pai wrote: Hello Rory, On 14/06/21 11:42 pm, Rory O'Donnell wrote: Many thanks Jaikiran for the analysis and the feedback to the security-dev mailing list ! Do let us know about the final test failure ? I had a look at this one in more detail. The failure is in one of our javadoc related tests[1]. After looking into the details, this appeared to be a genuine regression. So I raised this in the javadoc-dev mailing list[2]. In that discussion it has been acknowledged as an intentional change in this version of the JDK and not a bug. It did however expose another bug for which a new JBS issue has been created[3] The Ant project needs to do certain changes to take into account both the security manager warnings and this change in behaviour of javadoc tool. I'll create a separate Ant dev mailing list thread for that tomorrow. [1] https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20(latest%20EA%20JDK)/jdk_axis=jdk17_ea,label_exp=ubuntu/74/testReport/junit/src.tests.antunit.taskdefs/javadoc-test_xml/testFailOnWarning/ [2] https://mail.openjdk.java.net/pipermail/javadoc-dev/2021-June/003075.html [3] https://bugs.openjdk.java.net/browse/JDK-8268774 -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [External] : Re: JDK 17 is now in Rampdown Phase One
Hello Rory, On 14/06/21 11:42 pm, Rory O'Donnell wrote: Many thanks Jaikiran for the analysis and the feedback to the security-dev mailing list ! Do let us know about the final test failure ? I had a look at this one in more detail. The failure is in one of our javadoc related tests[1]. After looking into the details, this appeared to be a genuine regression. So I raised this in the javadoc-dev mailing list[2]. In that discussion it has been acknowledged as an intentional change in this version of the JDK and not a bug. It did however expose another bug for which a new JBS issue has been created[3] The Ant project needs to do certain changes to take into account both the security manager warnings and this change in behaviour of javadoc tool. I'll create a separate Ant dev mailing list thread for that tomorrow. [1] https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20(latest%20EA%20JDK)/jdk_axis=jdk17_ea,label_exp=ubuntu/74/testReport/junit/src.tests.antunit.taskdefs/javadoc-test_xml/testFailOnWarning/ [2] https://mail.openjdk.java.net/pipermail/javadoc-dev/2021-June/003075.html [3] https://bugs.openjdk.java.net/browse/JDK-8268774 -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 One
Hello Rory, This JDK 17 EA build 26, has caused at least one regression in our testsuite. It relates to the new WARNING message that gets printed out to System.err, when something at runtime sets the security manager. Given the nature of the test that's failing, fixing it is trivial for us, so I'll probably do that tomorrow. However, I would have liked a bit more easy debuggability around what piece of code is setting the security manager. So I've raised this as a question in security-dev mailing list of JDK[1]. Additionally, there's one other test that failed with this build. I haven't yet found the time to look into that one in a bit more detail. I plan to do that tomorrow and send an update if it turns out to be an issue in JDK. [1] https://mail.openjdk.java.net/pipermail/security-dev/2021-June/026456.html -Jaikiran On 14/06/21 3:19 pm, Rory O'Donnell wrote: Hi Stefan/Jaikiran, *Per the JDK 17 schedule , we are in Rampdown Phase One [1].* **Please advise if you find any issues while testing the latest Early Access builds**.** * Schedule: o *2021/06/10 Rampdown Phase One* 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. ** * Important JEPs have been integrated – Attention Required! * *JEP 411: **Deprecate the Security Manager for Removal*<https://openjdk.java.net/jeps/411> o Deprecate, for removal, most Security Manager related classes and methods. o Warning message at startup if the Security Manager is enabled on the command line. o Warning message at run time if a Java application or library installs a Security Manager dynamically. o Deprecation is in concert with the legacy Applet API (JEP 398). * *JEP 407: **Remove RMI Activation*<https://openjdk.java.net/jeps/407> o Removal the Remote Method Invocation (RMI) Activation mechanism, while preserving the rest of RMI. o It was deprecated for removal by JEP 385<https://openjdk.java.net/jeps/385>in Java SE 15. * *JEP 403: **Strongly Encapsulate JDK Internals*<https://openjdk.java.net/jeps/403> o Strongly encapsulate all internal elements of the JDK, except for critical internal APIs such as /sun.misc.Unsafe/. o It will no longer be possible to relax the strong encapsulation of internal elements via a single command-line option. * Other 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 406: **Pattern Matching for switch (Preview)*<https://openjdk.java.net/jeps/406> 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 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 26 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: * *Build 26:* o JDK-8268241: deprecate JVM TI Heap functions 1.0 o JDK-8266846: Add java.time.InstantSource o JDK-8248268: Support KWP in addition to KW o JDK-8204686: Dynamic parallel reference processing support for Parallel GC o JDK-8259530: Generated docs contain MIT/GPL-licenced works without reproducing the licence [*Reported by Apache Maven*] o JDK-8266766: Arrays of types that cannot be an annotation member do not yield exceptions [*Reported by ByteBuddy*] o JDK-8266598: Exception values for AnnotationTypeMismatchException are not always informative [*Reported by ByteBuddy*] * *Build 25* o JDK-8266653: Change update mode for JDK rpm/deb installers as it breaks "yum up
Re: Creating a New AntUnit Release?
Hello Stefan, Releasing a new version sounds good. As for the version number, I'll let you decide since I don't have prior background with AntUnit releases :) -Jaikiran On 23/05/21 2:37 pm, Stefan Bodewig wrote: Hi all it looks as if we didn't do what we preach, see https://bz.apache.org/bugzilla/show_bug.cgi?id=65315 :-) Over the past three years we haven't seen any reason to change anything inside of AntUnit. The issue above is probably standing in the way for somebody, so I'd like to cut a fresh release containing just this fix. I do not intend to start going through the code and modernizing anything. I believe the antlib should still work with 1.8.1 and Java5, but I haven't tried either. This could be 1.5 or 1.4.1, I don't really care. What do you think? 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 17 Early Access build 23 is available
Hello Rory, I ran this against our Ant project on a Linux system. No issues observed in this run with JDK 17 build 17-ea+23-2064. https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20(latest%20EA%20JDK)/jdk_axis=jdk17_ea,label_exp=ubuntu/73/ -Jaikiran On 21/05/21 12:28 pm, Rory O'Donnell wrote: Hi Stefan/Jaikiran, ** *OpenJDK 17 Early Access build 23 is now 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> * JEPs targeted to JDK 17, so far: 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 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 414: _Vector API (Second Incubator) <https://openjdk.java.net/jeps/414>_ * 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 Build 23 + JDK-8243287: Removal of Unsafe::defineAnonymousClass. o Build 22 + *JDK-8266369: New implementation of java.nio.channels.Selector on Microsoft Windows. * o Build 21 + *JDK-8196415: JARs signed with SHA-1 algorithms are restricted by default.* + *JDK-8266858: macOS on ARM early access available.* # The ARM port should behave similarly to the Intel port. There are no known feature differences. # When reporting issues on macOS please specify if using ARM or x64. *We need your help in testing new Selector implementation on Windows [1]:* * The implementation of the Selector API on Windows has been replaced in JDK 17 b22 with a new more scalable implementation [2]. * The old select based Selector implementation has been the default since Java 1.4 (2002) so replacing it is a significant change. * It would be really helpful to get more testing of the new implementation before the fork for Rampdown Phase One on June 10th. *Other Topics which might be of Interest:* * Updates to JEP 411: Deprecate the Security Manager for Removal | _Link_ <https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005569.html> * "The meaning, or not, of “LTS” | _Link_ <https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005543.html> * JFR Remote Recording Stream | _Link_ <https://egahlin.github.io/2021/05/17/remote-recording-stream.html> *Project Loom Early-Access Build: **_Build 17-loom+7-342_* <https://jdk.java.net/loom/>*(2021/5/11)* * These early-access builds are provided under the _GNU General Public License, version 2, with the Classpath Exception_ <https://openjdk.java.net/legal/gplv2+ce.html>. * These builds are produced for the purpose of gathering feedback. Use for any other purpose is at your own risk. * 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>. *Project Panama Early-Access Build: *_*Build 17-panama+3-167* <https://jdk.java.net/panama/>_*(2021/5/18)* * These early-access builds are provided under the _GNU General Public License, version 2, with the Classpath Exception_ <https://openjdk.java.net/legal/gplv2+ce.html>. * This build is aimed at testing a prototype implementation of the foreign memory support, foreign function support and native extraction tooling from the "foreign-jextract" branch of the Panama repo. * Please send feedback via e-mail to _panama-...@openjdk.java.net <mailto:panama-...@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/panama-dev>. Rgds,Rory [1] _https://mail.openjdk.java.net/pipermail/nio-dev/2021-May/008988.html_ <https://mail.openjdk.java.net/pipermail/nio-dev/2021-May/008988.html> [2] _https://bugs.openjdk.java.net/browse/JDK-8266369_ <https://bugs.openjdk.java.net/browse/JDK-8266369> - 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 21 is available
Hello Rory, Ran our Ant testsuite against JDK 16.0.1 (build 16.0.1+9-24)[1] and JDK 17-ea (build 17-ea+21-1866)[2]. No issues observed. [1] https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20(latest%20EA%20JDK)/jdk_axis=jdk16_ea,label_exp=ubuntu/72/ [2] https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20(latest%20EA%20JDK)/jdk_axis=jdk17_ea,label_exp=ubuntu/72/ -Jaikiran On 10/05/21 1:51 pm, Rory O'Donnell wrote: Hi Stefan/Jaikiran, ** *OpenJDK 17 Early Access build 21 is now 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> * Schedule o 2021/06/10 Rampdown Phase One 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 * JEPs targeted to JDK 17, so far: 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 410: Remove the Experimental AOT and JIT Compiler <https://openjdk.java.net/jeps/410> * 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 Build 21: + JDK-8196415: JARs signed with SHA-1 algorithms are restricted by default. + JDK-8265989: System property for the native character encoding name. + JDK-8265137: java.util.Random suddenly has new public methods nowhere documented. # [*Reported by Apache Lucene]* o Build 20 + JDK-8037397: RegEx pattern matching loses character class after intersection (&&) operator. + JDK-8264208: A new public method that returns the `Charset` used in the `Console. o Build 19 + JDK-8228988: AnnotationParser throws NullPointerException on incompatible member type. # *[Reported by ByteBuddy]* + JDK-8258794: Support for CLDR version 39. + JDK-8262108: SimpleDateFormat formatting broken for sq_MK Locale. # *[**Reported by ApacheCommons]* o Build 18 + JDK-8260693: Provide the support for specifying a signer in keytool -genkeypair. + JDK-8263763: Synthetic constructor parameters of enum are not considered for annotation indices. # *[Reported by ByteBuddy]* *Topics of interest from 'Insider Java':* * Security and Sandboxing Post SecurityManager : Link <https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/> * Foreign Memory Access and NIO channels - Going Further : Link <https://inside.java/2021/04/21/fma-and-nio-channels/> *Project Loom Early-Access Build: **Build 17-loom+6-225* <https://jdk.java.net/loom/>*(2021/4/1)* * These early-access builds are provided under the GNU General Public License, version 2, with the Classpath Exception <https://openjdk.java.net/legal/gplv2+ce.html>. * These builds are produced for the purpose of gathering feedback. Use for any other purpose is at your own risk. * 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>.** *April 2021 Critical Patch Update Released:* * As part of the April 2021 CPU we released JDK 16.0.1, JDK 11.0.11 LTS, JDK 8u291 and JDK 7u301 as well as OpenJDK 16.0.1 (publicly available). Rgds,Rory - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [PROPOSAL] ant-junitlauncher watchdog customization
Hello Aleksei, That looks fine to me. I've merged it to our master branch. I've added your github profile name (Alex) to our contributors list. If you want to use a different name to be added, please let us know, I'll update accordingly. -Jaikiran On 30/04/21 2:06 pm, Aleksei Zotov wrote: Hi all, I've raised https://github.com/apache/ant/pull/147 PR for having an ability to customize a watchdog created for test execution. The PR description has all the details explained. Could you, please, have a look and let me know what you think. Thanks, Aleksei Zotov. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: JDK 17 EA build 18 is available
Hello Rory, No issues were observed against our Ant testsuite on a Linux setup with JDK 17 build 17-ea+18-1490. https://ci-builds.apache.org/job/Ant/job/Ant%20Master%20(latest%20EA%20JDK)/71/jdk_axis=jdk17_ea,label_exp=ubuntu/ -Jaikiran On 20/04/21 3:21 pm, Rory O'Donnell wrote: *Hi Stefan/Jaikiran, * *OpenJDK 17 Early Access build 18is now 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 http://jdk.java.net/17/release-notes <https://jdk.java.net/17/release-notes> **G1 pauses may be extremely long with EA build JDK-17+18* *During performance testing we noticed that due to a recent change (JDK-8262068) GC pauses after a G1 full GC may be extremely slow. The problem has been fixed with JDK-8264987 and that has already been integrated. This change will be available with the following EA build JDK-17+19. For more technical info please see [1] *JEP 382 [2]** - Starting with build 19, **JDK 17 for macOS is *temporarily* switched from using OpenGL**to using Apple's Metal API**for Java 2D rendering.* Heads up to anyone who is testing JDK 17 for running apps on macOS. Starting with build 19, JDK 17 for macOS is *temporarily* switched from using OpenGL to using Apple's Metal API for Java 2D rendering. If you are running any kind of 2D / Swing/ AWT UI application on macOS, and see any rendering related problems starting with JDK 17 b19, please do report them to us along with a test case and screen shots. You may also set "-Dsun.java2d.opengl=true" to re-enable OpenGL - which implicitly disables Metal - to confirm that it is a Metal related rendering glltch. Rgds,Rory [1] https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2021-April/034745.html [2] https://openjdk.java.net/jeps/382 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[ANNOUNCE] Apache Ant 1.10.10 released
The Apache Ant Team is pleased to announce the release of Apache Ant 1.10.10. 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.10 unless you are required to use versions of Java prior to Java 8 during the build process. Ant 1.10.10 contains various bug fixes as well as some enhancements. The complete set of changes is listed at the end of this mail. 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 when downloading the release. Changes in 1.10.10 are as follows: Fixed bugs: --- * SCP (with sftp=true) task would fail if fetching file located in root directory Bugzilla Report 64742 * javac task would fail if the arguments file it (internally) created didn't quote the # character. This has now been fixed. Bugzilla Reports 64912, 64790 * made sure LegacyXmlResultFormatter encodes characters illegal in XML the same way JUnit5's built-in formatter would. Bugzilla Report 65030 * LegacyXmlResultFormatter no longer double-encodes <>& in system-err and system-out Bugzilla Report 63436 * Fixes a bug in junitlauncher task's legacy-xml formatter, where the testcase representing a @Parameterized JUnit4 test wasn't being reported in the XML. Bugzilla Report 64952 * Fixes a bug where the ant-testutil-sources.jar that gets published to Maven central repository didn't contain any source files. Bugzilla Report 65110 * The condition didn't follow redirects from http to https. Bugzilla Report 65105 * ZipOutputStream now overrides write(int) in order to make sure single byte writes get the same treatment as array writes. Github Pull Request #145 * Fixes a potential deadlock in junitlauncher task when using legacy-xml reporter. Bugzilla Report 64733 Other changes: -- * javaversion condition now has a new "atmost" attribute. See the javaversion manual for more details * The "listener" nested element of the "junitlauncher" task now has a new "useLegacyReportingName" attribute which can be used to control the test identifiers names that get reported by the listener. See the junitlauncher manual for more details. Note that this change also introduces a new "setUseLegacyReportingName" method on the org.apache.tools.ant.taskdefs.optional.junitlauncher.TestResultFormatter interface. This will break backward compatibility with any of your custom result formatters which implemented this interface and such implementations are now expected to implement this new method. * a new attribute preserveduplicates allows to return the same resource multiple times when set to true. Bugzilla Report 64854 * a new attribute filterbeforeconcat in can be used to decide whether the filterchain should be applied to the concatenated content (the default) or each nested resource individually before concatenating them. Bugzilla Report 64855 * the ssh tasks now share a new nested element additionalConfig that can be used to set config values for the jsch Session used by the task. Bugzilla Report 65089 * added new discardOutput and discardError properties to redirector and the exec, apply and java tasks which can be used to completely discard any (error) output. This is a platform independent alternative to directiong output to any kind of null device. * junitlauncher now prints a more useful and instantaneous summary of tests being run, closely matching the junit task's summary. Bugzilla Report 64836 -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: Close 1.10.10 in bugzilla?
Thank you Stefan. -Jaikiran On 18/04/21 1:36 am, Stefan Bodewig wrote: On 2021-04-17, Jaikiran Pai wrote: I just completed the release formalities for Ant 1.10.10. I will send out the official announcement mail on Monday. In the meantime, could someone which access permissions on Bugzilla please close the 1.10.10 version and create a new 1.10.11 version there? You don't close milestons in Bugzilla. Added a new product version 1.10.10 and a new milestone 1.10.11. 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
Close 1.10.10 in bugzilla?
I just completed the release formalities for Ant 1.10.10. I will send out the official announcement mail on Monday. In the meantime, could someone which access permissions on Bugzilla please close the 1.10.10 version and create a new 1.10.11 version there? -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.10 based on RC1
With +1s from Stefan, Maarten, me and Paul (non-binding), this vote has passed. I'll start the rest of the release activities shortly. Thank you everyone. -Jaikiran On 12/04/21 10:01 am, Jaikiran Pai wrote: I've created a release candidate for 1.10.10: git tag: ANT_1.10.10_RC1 on commit: eccd0a2ceb4fa854ee9f2a95cfea10d55a485dda tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 46988 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1047/org/apache/ant/ Snapcraft Build Revision 18 in latest/candidate This vote will be open at least for 72 hours and close no earlier than 15th April 2021 04:30 AM UTC. -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.10 based on RC1
Thank you Paul for testing this against the Groovy test suite. -Jaikiran On 14/04/21 1:14 pm, Paul King wrote: +1 (non-binding) * Checked signatures and hashes for zip and tar.gz src distributions. * I also ran the Apache Groovy build against the new artifacts. The Groovy test suite has >100 tests exercising various aspects of Ant functionality for Groovy's AntBuilder and Groovy's various Ant tasks. There were no failures. Cheers, Paul. On Mon, Apr 12, 2021 at 2:31 PM Jaikiran Pai wrote: I've created a release candidate for 1.10.10: git tag: ANT_1.10.10_RC1 on commit: eccd0a2ceb4fa854ee9f2a95cfea10d55a485dda tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision: 46988 Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-1047/org/apache/ant/ Snapcraft Build Revision 18 in latest/candidate This vote will be open at least for 72 hours and close no earlier than 15th April 2021 04: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