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-16 Thread Paul King
Thanks for the update. We have some workarounds in the Groovy codebase too.
I'll try to tidy them up too once this has settled.

Thanks again, Paul.

On Mon, May 15, 2023 at 10:08 PM Jaikiran Pai  wrote:

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