JDK 19 GA, JDK 20 EAb16, and some heads-up!

2022-09-23 Thread David Delabassee

Greetings!

JDK 19 has been released (General Availability) on September 2Oth as 
planned, the release cadence is working like clockwork! You can find the 
"The Arrival of Java 19" announcement here [1], and some additional Java 
19 material 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!


With JDK 19 released, the focus should now shift to JDK 20 testing. As 
always, if you face any issues with early-access builds of JDK 20 please 
let us know. And do keep in mind that our GitHub Action [2] supports 
Early-Access builds, including JDK 20 EA.


With Virtual Threads (preview), Structured Concurrency (Incubutor), 
Record Patterns (Preview), the Foreign Function & Memory API (Preview), 
etc. Java 19 is a rich feature release, to say the least! This release 
also paves the way for an exciting future! To conclude with Java 19, all 
its features will be covered in great detail during JavaOne (Oct 17-20 
Las Vegas) [3]. If you are planning to come and haven't registered yet, 
I suggest to ping me ASAP.


[1] https://inside.java/2022/09/20/the-arrival-of-java-19/
[2] https://github.com/oracle-actions/setup-java
[3] https://inside.java/javaone/


## Heads-Up: JDK 19 - Double.toString() and Float.toString() change

A bug affecting Double.toString(double) and Float.toString(float) has 
been fixed in Java 19 [4]. According to the Javadoc, 
Double.toString(double) should produce a string with a number of digits 
as small as possible, that still uniquely distinguishes this double from 
its adjacent double. That was not the case for many doubles. For 
example, whereas 1e23 and 9.999E22 are the same double, 
passing 1e23 to Double.toString(double) was returning 
“9.999E22”. The specification has been updated, and the 
implementation along with it. As a consequence and starting with JDK 19 
some of the strings produced are now shorter than the ones produced in 
earlier releases. For example, passing 1e23 to this method in JDK 19 
will return “1.0E23" instead of “9.999E22” in earlier JDK 
releases. Note that in JDK 19, passing 9.999E22 to this 
method also returns "1.0E23" because they are the same double. Many 
string representations of doubles and floats have changed to match the 
specification update.


You can read the release notes [5] and some additional details here [4]. 
You can also learn more about floating point arithmetic in Joe Darcy's 
excellent "Floating-Point Arithmetic : What Every Java Programmer Should 
Know!" session [6].


[4] https://bugs.openjdk.org/browse/JDK-4511638
[5] https://bugs.openjdk.org/browse/JDK-8291475
[6] https://youtu.be/ajaHQ9S4uTA


## Heads-Up: JDK 20 - Drop support for -source/-target/--release 7 from 
javac


JEP 182 (Policy for Retiring javac -source and -target Options) 
describes a policy to remove at a regular pace, from the javac compiler, 
support for obsolete versions. This is required to reduce compiler 
maintenance costs. JEP 182 still needs to be updated to reflect the 
6-month release cadence but in that spirit and given that JDK 7 was 
released in July 2011, i.e. over a decade ago, support for 
-source/-target/--release 7 is dropped in JDK 20. All other supported 
values remain as such in JDK 20, 8 through 20 inclusive.


For more information, you might want to check JDK-8173605 [7] and JEP 
182: Policy for Retiring javac -source and -target Options [8].


[7] https://bugs.openjdk.org/browse/JDK-8173605
[8] https://openjdk.org/jeps/182


## General Availability of Java 19 / JDK 19

JDK 19 is now Generally Available [9]. The OpenJDK builds, provided 
under the GNU General Public License v2 with the Classpath Exception, 
are available here [10]. The JDK 19 Release Notes are available here [11].


[9] https://mail.openjdk.org/pipermail/jdk-dev/2022-September/006933.html
[10] https://jdk.java.net/19/
[11] https://jdk.java.net/19/release-notes

JDK 19 includes seven JEPs:
- 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)
along with hundreds of smaller enhancements and over a thousand bug fixes.


## JDK 20 Early-Access builds

JDK 20 Early-Access builds 16 are now 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://jdk.java.net/20/
[13] https://jdk.java.net/20/release-notes

### Changes in 20EA-b16 that may be of interest:

- JDK-8293499: Provide jmod --compress option
- JDK-8290367: Update default value and extend the scope of 
com.sun.jndi.ldap.object.trustSerialData system property
- JDK-8244681: Add a warning f

Dependabot emails are filling my mailbox

2022-09-23 Thread Matt Sicker
After secretary emails, emails related to Dependabot are the next most common 
message in my mailbox. I’ve already had to clear out several gigs of emails, 
and these Dependabot rebases and relentless updates are making it impossible to 
follow anything on the mailing lists anymore.

Proposal: all Dependabot messages should be batched into a digest email or 
similar. I don’t need multiple notifications per PR, and I don’t need dozens of 
Jira issues commented on for no good reason. Alternative: disable Dependabot as 
a failed experiment.

—
Matt Sicker

Re: Dependabot emails are filling my mailbox

2022-09-23 Thread Robert Middleton
I haven't tried it, but if you go to your settings for Github you can
set dependabot to not notify you.

That doesn't affect the notifications@ list of course.

-Robert Middleton

On Fri, Sep 23, 2022 at 7:47 PM Matt Sicker  wrote:
>
> After secretary emails, emails related to Dependabot are the next most common 
> message in my mailbox. I’ve already had to clear out several gigs of emails, 
> and these Dependabot rebases and relentless updates are making it impossible 
> to follow anything on the mailing lists anymore.
>
> Proposal: all Dependabot messages should be batched into a digest email or 
> similar. I don’t need multiple notifications per PR, and I don’t need dozens 
> of Jira issues commented on for no good reason. Alternative: disable 
> Dependabot as a failed experiment.
>
> —
> Matt Sicker


Re: Dependabot emails are filling my mailbox

2022-09-23 Thread Gary Gregory
Have you ever heard the expression "Don't shoot the messenger"? ;-)

Dependabot is a great tool IMO.

I think someone had proposed a different email address for bot emails that
that obviously did not happen. Then there is classic "inbox rules" reply.
Whomever wants to drive this can go ahead...

Gary

On Fri, Sep 23, 2022, 19:47 Matt Sicker  wrote:

> After secretary emails, emails related to Dependabot are the next most
> common message in my mailbox. I’ve already had to clear out several gigs of
> emails, and these Dependabot rebases and relentless updates are making it
> impossible to follow anything on the mailing lists anymore.
>
> Proposal: all Dependabot messages should be batched into a digest email or
> similar. I don’t need multiple notifications per PR, and I don’t need
> dozens of Jira issues commented on for no good reason. Alternative: disable
> Dependabot as a failed experiment.
>
> —
> Matt Sicker


Re: Dependabot emails are filling my mailbox

2022-09-23 Thread Matt Sicker
The messenger only needs one email per update. I’m getting several for each 
one. I can’t even tell if humans are contributing anything anymore.

—
Matt Sicker

> On Sep 23, 2022, at 17:06, Gary Gregory  wrote:
> 
> Have you ever heard the expression "Don't shoot the messenger"? ;-)
> 
> Dependabot is a great tool IMO.
> 
> I think someone had proposed a different email address for bot emails that
> that obviously did not happen. Then there is classic "inbox rules" reply.
> Whomever wants to drive this can go ahead...
> 
> Gary
> 
>> On Fri, Sep 23, 2022, 19:47 Matt Sicker  wrote:
>> 
>> After secretary emails, emails related to Dependabot are the next most
>> common message in my mailbox. I’ve already had to clear out several gigs of
>> emails, and these Dependabot rebases and relentless updates are making it
>> impossible to follow anything on the mailing lists anymore.
>> 
>> Proposal: all Dependabot messages should be batched into a digest email or
>> similar. I don’t need multiple notifications per PR, and I don’t need
>> dozens of Jira issues commented on for no good reason. Alternative: disable
>> Dependabot as a failed experiment.
>> 
>> —
>> Matt Sicker