Release Ant 1.10.15?

2024-02-21 Thread Jaikiran Pai

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

2023-11-22 Thread Jaikiran Pai

+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

2023-11-19 Thread Jaikiran Pai



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

2023-10-28 Thread Jaikiran Pai

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 release of javac 
may disable 

Re: [ANNOUNCE] Apache Ant 1.10.14 released

2023-09-28 Thread Jaikiran Pai
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

2023-09-11 Thread Jaikiran Pai
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

2023-09-07 Thread Jaikiran Pai
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

2023-08-22 Thread Jaikiran Pai
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

2023-08-20 Thread Jaikiran Pai
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

2023-08-18 Thread Jaikiran Pai

+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

2023-08-18 Thread Jaikiran Pai

+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

2023-08-17 Thread Jaikiran Pai



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

2023-08-17 Thread Jaikiran Pai

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

2023-08-16 Thread Jaikiran Pai

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

2023-08-16 Thread Jaikiran Pai

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

2023-08-13 Thread Jaikiran Pai

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
 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?

2023-08-12 Thread Jaikiran Pai
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

2023-08-09 Thread Jaikiran Pai

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

2023-08-07 Thread Jaikiran Pai

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

2023-05-16 Thread Jaikiran Pai

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: Add 

Re: Release Ant 1.10.13?

2023-05-15 Thread Jaikiran Pai

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

2023-05-14 Thread Jaikiran Pai

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

2023-02-27 Thread Jaikiran Pai

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: Virtual thread 

Re: Need help with Ant versions in bugzilla

2023-01-10 Thread Jaikiran Pai

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

2023-01-10 Thread Jaikiran Pai
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

2023-01-09 Thread Jaikiran Pai
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

2023-01-09 Thread Jaikiran Pai
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

2023-01-08 Thread 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



[VOTE] Release Apache Ant 1.10.13 based on RC1

2023-01-04 Thread Jaikiran Pai

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?

2022-12-11 Thread Jaikiran Pai

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?

2022-12-11 Thread Jaikiran Pai

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

2022-12-11 Thread Jaikiran Pai

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!

2022-12-10 Thread Jaikiran Pai

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 

Re: Release Ant 1.10.13?

2022-11-19 Thread Jaikiran Pai

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?

2022-11-16 Thread Jaikiran Pai

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

2022-11-07 Thread Jaikiran Pai
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

2022-11-03 Thread Jaikiran Pai

+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

2022-10-10 Thread Jaikiran Pai
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

2022-08-18 Thread Jaikiran Pai

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

2022-06-16 Thread Jaikiran Pai
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

2022-06-16 Thread Jaikiran Pai

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 to specific 

Re: synchronized and Loom

2022-06-06 Thread Jaikiran Pai

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?

2022-06-03 Thread Jaikiran Pai

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!

2022-05-21 Thread Jaikiran Pai

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 event 

Re: Build failed in Jenkins: Ant » Ant-Build-from-POMs #120

2022-02-09 Thread Jaikiran Pai

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

2022-02-08 Thread Jaikiran Pai

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

2022-02-08 Thread Jaikiran Pai

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

2022-02-08 Thread Jaikiran Pai

+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

2022-02-07 Thread Jaikiran Pai

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

2022-02-07 Thread Jaikiran Pai

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

2022-02-06 Thread Jaikiran Pai

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 factory 

Re: [DISCUSS] JUnit 5 Customization

2021-12-22 Thread Jaikiran Pai

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
) 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-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: 

Re: JDK 18 Early-Access builds 23 are available

2021-11-18 Thread Jaikiran Pai

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 under the GNU 

Re: Thank you! JDK 18 Early Access build 20 is now available

2021-10-26 Thread Jaikiran Pai

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/ **

*

 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception .
 * Release Notes are available athttps://jdk.java.net/18/release-notes
   
 * Features:
 o JEPs integrated to JDK 18, so far:
 + JEP 400: UTF-8 by Default 
 + JEP 408: Simple Web Server 
 + JEP 413: Code Snippets in Java API Documentation
   
 o JEPs targeted to JDK 18, so far
 + JEP 417: Vector API (Third Incubator)
   
 o JEPs proposed to target JDK 18:
 + JEP 416: Reimplement Core Reflection with Method Handles
   

 * 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/
   *
 o *Part 2: 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/
   *
 * ZGC - What's new in JDK 17**
 o *https://inside.java/2021/10/05/zgc-in-jdk17/
   *
 * JDK 17 Security Enhancements**
 o *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/
   *
 * Faster Charset Encoding**
 o *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/

 * JDK 18 augmented `javac -Xlint:serial` checks
 o 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-foreign-apis/

 * Resource Scope Dependencies
 o 

Re: Need help with new versions in bugzilla for Ant

2021-10-21 Thread Jaikiran Pai



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

2021-10-20 Thread Jaikiran Pai



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

2021-10-19 Thread Jaikiran Pai
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

2021-10-18 Thread Jaikiran Pai

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

2021-10-17 Thread 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



[VOTE] Release Apache Ant 1.10.12 based on RC2

2021-10-12 Thread Jaikiran Pai

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

2021-10-08 Thread Jaikiran Pai
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

2021-10-07 Thread Jaikiran Pai



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

2021-10-07 Thread Jaikiran Pai

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

2021-10-04 Thread Jaikiran Pai
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

2021-10-02 Thread Jaikiran Pai

+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

2021-09-29 Thread Jaikiran Pai

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?

2021-09-28 Thread Jaikiran Pai



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?

2021-09-26 Thread Jaikiran Pai



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?

2021-09-15 Thread Jaikiran Pai
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

2021-09-15 Thread Jaikiran Pai

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/ 
 * JDK 17 Release notes

 * Inside Java: The Arrival of Java 17!
   

*JDK 17 includes the following features [2]:*

 * JEP 306: Restore Always-Strict Floating-Point Semantics
   
 * JEP 356: Enhanced Pseudo-Random Number Generators
   
 * JEP 382: New macOS Rendering Pipeline
   
 * JEP 391: macOS/AArch64 Port 
 * JEP 398: Deprecate the Applet API for Removal
   
 * JEP 403: Strongly Encapsulate JDK Internals
   
 * JEP 406: Pattern Matching for switch (Preview)
   
 * JEP 407: Remove RMI Activation 
 * JEP 409: Sealed Classes 
 * JEP 410: Remove the Experimental AOT and JIT Compiler
   
 * JEP 411: Deprecate the Security Manager for Removal
   
 * JEP 412: Foreign Function & Memory API (Incubator)
   
 * JEP 414: Vector API (Second Incubator)
   
 * JEP 415: Context-Specific Deserialization Filters
   

*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 




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/ 

*

 * These early access, open source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .
 * JEPs targeted to JDK 18, so far:
 o JEP 400: UTF-8 by Default 
 o JEP 413: Code Snippets in Java API Documentation
   

 * Release Notes are available at 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
    is
   available - 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
   .
 * Please send feedback via e-mail to loom-...@openjdk.java.net
   . To send e-mail to this address
   you must first subscribe to the mailing list
.

Rgds,Rory


[1] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/006037.html


[2] 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

2021-09-04 Thread Jaikiran Pai

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

2021-08-24 Thread Jaikiran Pai



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

2021-08-23 Thread Jaikiran Pai



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

2021-08-19 Thread Jaikiran Pai



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

2021-08-19 Thread Jaikiran Pai

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

2021-08-07 Thread Jaikiran Pai

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
   
 o JEP 356: Enhanced Pseudo-Random Number Generators
   
 o JEP 382: New macOS Rendering Pipeline
   
 o JEP 391: macOS/AArch64 Port 
 o JEP 398: Deprecate the Applet API for Removal
   
 o JEP 403: Strongly Encapsulate JDK Internals
   
 o JEP 406: Pattern Matching for switch (Preview)
   
 o JEP 407: Remove RMI Activation 
 o JEP 409: Sealed Classes 
 o JEP 410: Remove the Experimental AOT and JIT Compiler
   
 o JEP 411: Deprecate the Security Manager for Removal
   
 o JEP 412: Foreign Function & Memory API (Incubator)
   
 o JEP 414: Vector API (Second Incubator)
   
 o JEP 415: Context-Specific Deserialization Filters
   

*
*

*OpenJDK 17 Early Accessbuild 35 is available at 
**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 
 * Release Notes are available at 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
   : Enhanced Pseudo-Random Number
   Generators - Here
   
 * The latest JEP Café cover 17's JEP 409
    : Sealed Classes - Here
   
 * A few updates to JEP 411 :
   Deprecate the Security Manager for Removal - Here


*
*

*OpenJDK**18 Early Access build 9 is available at 
**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 
 * Release Notes are available at 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

2021-08-05 Thread Jaikiran Pai

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

2021-07-17 Thread Jaikiran Pai

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
   
 o JEP 356: Enhanced Pseudo-Random Number Generators
   
 o JEP 382: New macOS Rendering Pipeline
   
 o JEP 391: macOS/AArch64 Port 
 o JEP 398: Deprecate the Applet API for Removal
   
 o JEP 403: Strongly Encapsulate JDK Internals
   
 o JEP 406: Pattern Matching for switch (Preview)
   
 o JEP 407: Remove RMI Activation 
 o JEP 409: Sealed Classes 
 o JEP 410: Remove the Experimental AOT and JIT Compiler
   
 o JEP 411: Deprecate the Security Manager for Removal
   
 o JEP 412: Foreign Function & Memory API (Incubator)
   
 o JEP 414: Vector API (Second Incubator)
   
 o JEP 415: Context-Specific Deserialization Filters
   

*
*

*OpenJDK 17 Early Access build 31 is available at 
**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 
 * Release Notes are available at https://jdk.java.net/17/release-notes
   


*
*

*OpenJDK 18 Early Access build 6 is available at * 
*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 
 * Release Notes are available at 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 


Rgds,Rory

[1] 
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

2021-07-11 Thread Jaikiran Pai

+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

2021-07-11 Thread Jaikiran Pai

+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

2021-07-03 Thread Jaikiran Pai

+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

2021-06-28 Thread Jaikiran Pai
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

2021-06-27 Thread Jaikiran Pai

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

2021-06-25 Thread Jaikiran Pai

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
   
 o JEP 356: Enhanced Pseudo-Random Number Generators
   
 o JEP 382: New macOS Rendering Pipeline
   
 o JEP 391: macOS/AArch64 Port 
 o JEP 398: Deprecate the Applet API for Removal
   
 o JEP 403: Strongly Encapsulate JDK Internals
   
 o JEP 406: Pattern Matching for switch (Preview)
   
 o JEP 407: Remove RMI Activation 
 o JEP 409: Sealed Classes 
 o JEP 410: Remove the Experimental AOT and JIT Compiler
   
 o JEP 411: Deprecate the Security Manager for Removal
   
 o JEP 412: Foreign Function & Memory API (Incubator)
   
 o JEP 414: Vector API (Second Incubator)
   
 o JEP 415: Context-Specific Deserialization Filters
   


*OpenJDK 17 Early Access build 28 is available at 
**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 
 * Release Notes are available at 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* 


 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception 
 * 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
   

*Other Topics of Interest: *

 * State of Loom: https://www.youtube.com/watch?v=KG24inClY2M
   
 * State of Panama: https://www.youtube.com/watch?v=B8k9QGvPxC0
   
 * What's a JEP: 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

2021-06-17 Thread Jaikiran Pai
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

2021-06-16 Thread Jaikiran Pai
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

2021-06-15 Thread Jaikiran Pai
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

2021-06-15 Thread Jaikiran Pai



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

2021-06-14 Thread Jaikiran Pai

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*
 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*
 o Removal the Remote Method Invocation (RMI) Activation mechanism,
   while preserving the rest of RMI.
 o It was deprecated for removal by JEP
   385in Java SE 15.
 * *JEP 403: **Strongly Encapsulate JDK
   Internals*
 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*
 o JEP 356: Enhanced Pseudo-Random Number
   Generators
 o JEP 382: New macOS Rendering
   Pipeline
 o JEP 391: macOS/AArch64 Port
 o JEP 398: Deprecate the Applet API for
   Removal
 o *JEP 406: **Pattern Matching for switch
   (Preview)*
 o JEP 409: Sealed Classes
 o JEP 410: Remove the Experimental AOT and JIT
   Compiler
 o JEP 412: Foreign Function & Memory API
   (Incubator)
 o *JEP 414: **Vector API (Second
   Incubator)*
 o *JEP 415: **Context-Specific Deserialization
   Filters*

*OpenJDK 17 Early Access build 26 is available at 
**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

 * Release Notes are available at
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 update" for JDK11+
 o JDK-8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language
   codes to current
 o 

Re: Creating a New AntUnit Release?

2021-05-23 Thread Jaikiran Pai

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

2021-05-21 Thread Jaikiran Pai

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* _


 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception 
 * JEPs targeted to JDK 17, so far:
 o JEP 356: _Enhanced Pseudo-Random Number Generators
   _
 o JEP 382: _New macOS Rendering Pipeline
   _
 o JEP 391: _macOS/AArch64 Port _
 o JEP 398: _Deprecate the Applet API for Removal
   _
 o JEP 409: _Sealed Classes _
 o JEP 410: _Remove the Experimental AOT and JIT Compiler
   _
 o JEP 414: _Vector API (Second Incubator)
   _
 * Release Notes are available at
   _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_

 * "The meaning, or not, of “LTS” | _Link_

 * JFR Remote Recording Stream | _Link_


*Project Loom Early-Access Build: **_Build 17-loom+7-342_* 
*(2021/5/11)*


 * These early-access builds are provided under the _GNU General Public
   License, version 2, with the Classpath Exception_
   .
 * 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
   _.To send e-mail to this address
   you must first _subscribe to the mailing list_
.

*Project Panama Early-Access Build: *_*Build 17-panama+3-167* 
_*(2021/5/18)*


 * These early-access builds are provided under the _GNU General Public
   License, version 2, with the Classpath Exception_
   .
 * 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
   _. To send e-mail to this
   address you must first _subscribe to the mailing list_
.


Rgds,Rory


[1] 
_https://mail.openjdk.java.net/pipermail/nio-dev/2021-May/008988.html_ 

[2] _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

2021-05-10 Thread Jaikiran Pai

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* 


 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception 

 * 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
   
 o JEP 382: New macOS Rendering Pipeline
   
 o JEP 391: macOS/AArch64 Port 
 o JEP 398: Deprecate the Applet API for Removal
   
 o JEP 410: Remove the Experimental AOT and JIT Compiler
   

 * Release Notes are available at 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

 * Foreign Memory Access and NIO channels - Going Further : Link
   

*Project Loom Early-Access Build: **Build 17-loom+6-225* 
*(2021/4/1)*


 * These early-access builds are provided under the GNU General Public
   License, version 2, with the Classpath Exception
   .
 * 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
   . To send e-mail to this address
   you must first subscribe to the mailing list
.**

*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

2021-04-30 Thread Jaikiran Pai

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

2021-04-21 Thread Jaikiran Pai

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 *


 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception 
 * Release Notes are available at http://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

2021-04-19 Thread Jaikiran Pai
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?

2021-04-17 Thread Jaikiran Pai

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?

2021-04-17 Thread Jaikiran Pai
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

2021-04-15 Thread Jaikiran Pai
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

2021-04-15 Thread Jaikiran Pai

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



Re: [VOTE] Release Apache Ant 1.10.10 based on RC1

2021-04-13 Thread Jaikiran Pai

+1

- Downloaded the .tar.gz binary

- Installed locally. Checked the NOTICE file.

- Checked some random manuals, including the java task to verify new 
discardOutput and discardError is present


- Built some internal projects using this version

- Verified that the print summary using junitlauncher is more useful in 
this release, against an existing project.



-Jaikiran

On 13/04/21 1:31 pm, Maarten Coene wrote:

+1

Maarten






Op maandag 12 april 2021 06:31:29 CEST schreef Jaikiran Pai 
:





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



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org



  1   2   3   4   5   >