JDK 19 - Virtual Threads Testing!

2022-05-16 Thread David Delabassee

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 handlers
- JDK-8282559: Allow multiple search terms in javadoc search

Build 21:
- JDK-822: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms
- JDK-8278370: [win] Disable side-by-side installations of multiple JDK 
updates in Windows JDK installers
- JDK-8281010: [macos] Disable side-by-side installations of multiple 
JDK updates in macOS JDK installers

- JDK-8236128: Allow jpackage create installers for services
- JDK-8279598: provide adapter from RandomGenerator to Random

Build 20:
- JDK-8284553: Deprecate the DEFAULT static field of OAEPParameterSpec
- JDK-8283620: System.out does not use the encoding/charset specified in 
the Javadoc

- JDK-8285445: Enable Windows Alternate Data Streams

Re: [VOTE] Release Apache Commons Imaging 1.0-alpha3 based on RC2

2022-05-16 Thread Thomas Vandahl
Hi Bruno,

> Am 13.05.2022 um 14:02 schrieb Bruno Kinoshita :
> 
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Imaging 1.0-alpha2 was released, so I would like to
> release Apache Commons Imaging 1.0-alpha3.
> 
> Apache Commons Imaging 1.0-alpha3 RC2 is available for review here:
>https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha3-RC2
> (svn revision 54488)
> 
>  [X] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this release because…

Signatures are ok. Please consider having your key signed by some fellow 
Apaches.

Build, test and site build works fine using

—8<—
Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Java version: 11.0.13, vendor: GraalVM Community, runtime: 
/Library/Java/JavaVirtualMachines/graalvm-ce-java11-21.3.0/Contents/Home
Default locale: de_DE, platform encoding: UTF-8
OS name: "mac os x", version: "11.6.5", arch: "x86_64", family: "mac"
—8<—

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



Re: [configuration] CONFIGURATION-753 Interpolation Consistency

2022-05-16 Thread Bruno Kinoshita
I've approved the PR, and also set the fixVersion for the next 2.8.0
release.

This change doesn't break binary compatibility, but does change
behavior/feature. Users who were - for one reason or another - handling
array values, instead of the first value, will have to update their code
after this change.

But on the other hand, the inconsistency could also be considered a bug by
other issues, which would justify including it in the next bugfix or minor
release. I'm in favor of releasing it, with an extra note to the release
notes and/or Announce email about the change for users.

Thanks Matt!

-Bruno

On Mon, 16 May 2022 at 08:11, Matt Juntunen 
wrote:

> Hello,
>
> I've made a new PR [1] for CONFIGURATION-753 as part of my
> preparations for the next release. I'd like to get another pair of
> eyes on it if possible since it adds to the public API. The primary
> cause of the issue is that DefaultConversionHandler and
> ConfigurationInterpolator use different logic when determining how to
> convert container objects (e.g., collections and arrays) to strings.
> DefaultConversionHandler chooses the first element from the container
> and ConfigurationInterpolator just calls toString on the entire
> container, resulting in inconsistent string interpolation results. The
> change I made is to extract the ConfigurationInterpolator string
> conversion logic into a configurable "stringConverter" function that
> defaults to behave similarly to DefaultConversionHandler. If this
> logic is not what users want, they are free to override it.
>
> If anyone has time to give feedback on this, it would be much
> appreciated, especially since I haven't worked with configuration much
> before.
>
> Regards,
> Matt J
>
> [1] https://github.com/apache/commons-configuration/pull/181
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


Re: [VOTE] Release Apache Commons Imaging 1.0-alpha3 based on RC2

2022-05-16 Thread Bruno Kinoshita
> Signatures are ok. Please consider having your key signed by some fellow
Apaches.

I remember reading about Apache... fest? I think there was a small
gathering at ApacheCon for key signing. How's that handled nowadays? If
anyone has any links/suggestions, feel free to let me know. Adding a
post-it to look into it after the release.

Thanks Thomas
-Bruno

On Mon, 16 May 2022 at 21:18, Thomas Vandahl  wrote:

> Hi Bruno,
>
> > Am 13.05.2022 um 14:02 schrieb Bruno Kinoshita :
> >
> > We have fixed quite a few bugs and added some significant enhancements
> > since Apache Commons Imaging 1.0-alpha2 was released, so I would like to
> > release Apache Commons Imaging 1.0-alpha3.
> >
> > Apache Commons Imaging 1.0-alpha3 RC2 is available for review here:
> >https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha3-RC2
> > (svn revision 54488)
> >
> >  [X] +1 Release these artifacts
> >  [ ] +0 OK, but...
> >  [ ] -0 OK, but really should fix...
> >  [ ] -1 I oppose this release because…
>
> Signatures are ok. Please consider having your key signed by some fellow
> Apaches.
>
> Build, test and site build works fine using
>
> —8<—
> Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
> Java version: 11.0.13, vendor: GraalVM Community, runtime:
> /Library/Java/JavaVirtualMachines/graalvm-ce-java11-21.3.0/Contents/Home
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "11.6.5", arch: "x86_64", family: "mac"
> —8<—
>
> Bye, Thomas
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>