Re: Updates for our April report to the board?

[Rick Hillegas]

On 3/31/24 7:16 AM, Bryan Pendleton wrote:

Hi all, it is time for our April report to the board.

Could you please send me any information about what the community has
been working on over the last three months, so I can include this in
the report?

thanks,

bryan


Hey Bryan,

Nothing big from me. Just keeping Derby up to date with new Open JDK 
releases and responding to security inquiries.

Re: Fwd: [jira] [Comment Edited] (JDO-836) TCK: QueryCancel Test class fails

[Rick Hillegas]

Hey Craig,

I don't know how DataNucleus tries to cancel a query.

jdbc.sql.Statement.cancel() is an optional method which some DBMSes 
implement but Derby doesn't. The method raises a "Feature not supported" 
exception according to 
https://db.apache.org/derby/docs/10.17/ref/rrefjdbc40794.html




On 2/27/24 5:27 PM, Craig Russell wrote:

Hi,

The JDO project is having some issues with a feature that was never formally 
tested: cancel query. It is intended to allow the JDO user to cancel a query 
from a different thread. It is an optional feature enabled by a user 
configuration flag.

The problem is that it does not seem to work. I've attached a log excerpt that 
shows that query starts in one thread, query cancel is called by the user to 
the DataNucleus implementation which then is supposed to call the Derby cancel 
query via JDBC.

Without diving into the details, can you confirm that the Derby JDBC 
implementation does implement query cancel without throwing an exception?

Thanks,
Craig


Begin forwarded message:

From: "Michael Bouschen (Jira)" 
Subject: [jira] [Comment Edited] (JDO-836) TCK: QueryCancel Test class fails
Date: February 27, 2024 at 11:19:00 PST
To: jdo-...@db.apache.org
Reply-To: jdo-...@db.apache.org

I added some lof statement to check that query cancel is called after 
query.execute has been called:

22:14:11,040 (Query Executor) INFO  [org.apache.jdo.tck] - Start query execute  
   1708809251037
22:14:12,038 (ForkJoinPool-1-worker-19) INFO  [org.apache.jdo.tck] - Start 
query cancel 1708809252038
22:14:12,039 (ForkJoinPool-1-worker-19) INFO  [org.apache.jdo.tck] - End query 
cancel   1708809252039
22:15:00,860 (Query Executor) INFO  [org.apache.jdo.tck] - End query execute
1708809300860
22:15:00,861 (Query Executor) INFO  [org.apache.jdo.tck] - query execute took 
49823ms


Craig L Russell
c...@apache.org

Re: JDK 22 Release Candidates & Virtual Threads pinning heads-up

[Rick Hillegas]

Thanks for the heads-up, David. Derby found no problems with this 
release candidate. See https://issues.apache.org/jira/browse/DERBY-7159


On 2/20/24 12:00 AM, David Delabassee wrote:

Welcome to the latest OpenJDK Quality Outreach update!

The first JDK 22 Release Candidates builds are now available [1]. At this 
stage, only P1 issues will still be evaluated. And with the JDK 22 General 
Availability set for March 19th, it is now time to fully focus on JDK 23. At 
the time of writing, one JEP has already been integrated in JDK 23, i.e., JEP 
455: 'Primitive Types in Patterns, instanceof, and switch (Preview)' [2]. But 
new JEP candidates [3][4] have recently been announced, so things should evolve 
rapidly.

I'd like to thank those of you who have already provided feedback on the JDK 22 EA 
builds. Feedback is always extremely useful, even more, when it comes early in the 
development cycle. Another area where we need your help is Loom. So, please make sure to 
check the heads-up below that discusses the so-called Virtual Threads "pinning" 
issue.

[1] https://openjdk.org/projects/jdk/22/
[2] https://openjdk.org/jeps/455
[3] https://openjdk.org/jeps/465
[4] https://openjdk.org/jeps/466


## Heads-up: Virtual Threads “Pinning” Issue

Virtual threads became a permanent feature in JDK 21. This feature has been extremely well received by the 
Java ecosystem but there are still a few pain points. Much has been written about the so-called 
"pinning" issue that arises with synchronized methods or synchronized statements. The two most 
common cases are (a) a virtual thread parks (ex. doing socket I/O) while in a synchronized method, and (b) a 
virtual thread blocks entering a synchronized method because the object's associated monitor is held by 
another thread. In both cases, the underlying carrier/native thread is not "released" to do other 
work. Performance and scalability may suffer and in some cases, starvation and deadlock might happen. This 
recent "Virtual Threads Next Steps" video [5] explains in more details the why's and discusses some 
potential solutions.

New Loom early-access builds haven been recently published [6]. Those Loom EA 
builds have changes to the object monitor implementation that do not pin for 
these two common cases. The Loom team needs your help to test these updated 
object monitors with code that you know is using virtual threads and with 
libraries that are heavily synchronized. The goal is to gauge both reliability 
and performance.

The simplest way to report an issue or feedback is to use the Loom mailing list 
[7]. For the VM savvy, testing with both `-XX:LockingMode=1` (current default) 
and `-XX:LockingMode=2` would be extremely helpful as that would exercise the 
two locking modes currently implemented by the HotSpot VM.

[5] https://inside.java/2024/02/17/virtual-threads-next-steps/
[6] https://jdk.java.net/loom/
[7] https://mail.openjdk.org/pipermail/loom-dev/


## JDK 22 Release Candidates

The JDK 22 Release Candidate builds (builds 36) are available [8] and are 
provided under the GNU General Public License v2, with the Classpath Exception. 
The Release Notes are available here [9], and the javadocs here [10].

[8] https://jdk.java.net/22/
[9] https://jdk.java.net/22/release-notes
[10] https://download.java.net/java/early_access/jdk22/docs/api/


## JDK 23 Early-Access Builds

The JDK 23 Early-Access builds 10 are available [11], and are provided under 
the GNU General Public License v2, with the Classpath Exception. The Release 
Notes are available here [12].

### Changes in recent JDK 23 builds that may be of interest:

- JDK-8324287: Record total and free swap space in JFR
- JDK-8275338: Add JFR events for notable serialization situations
- JDK-8324665: Loose matching of space separators in the lenient date/time 
parsing mode
- JDK-8324066: "clhsdb jstack" should not by default scan for j.u.c locks 
because it can be very slow
- JDK-8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat 
pattern
- JDK-8325221: Obsolete TLABStats
- JDK-8322535: Change default AArch64 SpinPause instruction
- JDK-8323746: Add PathElement hashCode and equals
- JDK-8325570: Update to Graphviz 9.0.0
- JDK-8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files
- JDK-8320458: Improve structural navigation in API documentation
- JDK-8324068: Improve references to tags in the Doc Comment Spec
- JDK-8322366: Add IEEE rounding mode corruption check to JNI checks
- JDK-8321545: Override toString() for Format subclasses
- JDK-8324301: Obsolete MaxGCMinorPauseMillis
- JDK-8324632: Update Zlib Data Compression Library to Version 1.3.1
- JDK-8324771: Obsolete RAMFraction related flags
- JDK-8323645: Remove unused internal sun.net.www.protocol.jar.URLJarFileCa…
- JDK-8325150: (tz) Update Timezone Data to 2024a
- JDK-8324571: JDK 23 L10n resource files update

Note: Complete list of changes can be found here [13].

[11] https://jdk.java.net/23/
[12] 

Re: DERBY-6303: Add ability to defer enforcement of unique indexes until transaction end

[Rick Hillegas]

When I run fxmovierentals6-all.sql, I get a violation of a different 
foreign key than the one mentioned in the comment at the end of the 
script. I get this error:


ERROR 23516: The transaction was aborted because of a deferred 
constraint violation: Foreign key 
'FK9_talent_talent_id_TalentPhoto_talent_id' defined on "APP"."TALENT" 
referencing constraint 
'SQL000362-4dc6d895-018d-4f9a-090e-170eba31' defined on 
"APP"."TALENTPHOTO", key '(0,(2,90))'.


You are missing 3 matching keys in the referenced table. The following 
query (added just before the failed COMMIT) returns the following result:


ij> SELECT talent_id FROM talent WHERE talent_id NOT IN (SELECT 
talent_id FROM talentphoto);

TALENT_ID
---
0
1
2

It appears that you need to fix your data.

Hope this helps,
-Rick

On 1/31/24 1:06 PM, Bart van der Bilt wrote:


On 1/31/24 00:51, Rick Hillegas wrote:

On 1/30/24 12:52 PM, jazz wrote:

Hi,

It would be great if this issue could be implemented, I have a use 
case for testing. How do I get access to JIRA to update the ticket? 
(to include the sql files for testing).
You can request a JIRA account here: 
https://selfserve.apache.org/jira-account.html


Thanks, much appreciated. I added two SQL files in the JIRA ticket for 
testing.




When importing data into the database (which has foreign keys and 
unique constraints) this is useful. Import fails due to a deferred 
constraint violation due to the unique index 
(SQL000140-0fe82566-018d-4f9a-090e-170eba31):


ERROR 23516: The transaction was aborted because of a deferred 
constraint violation: Foreign key 
'FOREIGN_KEY_director_talent_id_talent_talent_id' defined on 
"APP"."DIRECTOR" referencing constraint 
'SQL000140-0fe82566-018d-4f9a-090e-170eba31' defined on 
"APP"."TALENT", key ''.


Import flow is (in ij):

autocommit off;
run('movies_insert.sql');
commit;

Foreign keys are created with deferred constraints (deferrable 
initially deferred).


Any help for a workaround or fix is highly appreciated.


The only workaround which occurs to me is to replace your unique 
indexes with unique constraints.


Thanks for the advice. This is what I did. Still no luck. Maybe I am 
doing something wrong here. I guess the question is how to insert data 
when foreign keys are already created.


Tried to workaround this issue by creating the unique constraints 
(they should be primary keys). Does it have to do something with the 
created backing indexes which are not deferrable?


Best regards, Bart



-Rick



Best regards,

Bart

Re: DERBY-6303: Add ability to defer enforcement of unique indexes until transaction end

[Rick Hillegas]

On 1/30/24 12:52 PM, jazz wrote:

Hi,

It would be great if this issue could be implemented, I have a use 
case for testing. How do I get access to JIRA to update the ticket? 
(to include the sql files for testing).
You can request a JIRA account here: 
https://selfserve.apache.org/jira-account.html


When importing data into the database (which has foreign keys and 
unique constraints) this is useful. Import fails due to a deferred 
constraint violation due to the unique index 
(SQL000140-0fe82566-018d-4f9a-090e-170eba31):


ERROR 23516: The transaction was aborted because of a deferred 
constraint violation: Foreign key 
'FOREIGN_KEY_director_talent_id_talent_talent_id' defined on 
"APP"."DIRECTOR" referencing constraint 
'SQL000140-0fe82566-018d-4f9a-090e-170eba31' defined on 
"APP"."TALENT", key ''.


Import flow is (in ij):

autocommit off;
run('movies_insert.sql');
commit;

Foreign keys are created with deferred constraints (deferrable 
initially deferred).


Any help for a workaround or fix is highly appreciated.


The only workaround which occurs to me is to replace your unique indexes 
with unique constraints.


-Rick



Best regards,

Bart

Re: Derby 10.16.1.2 artifacts release

[Rick Hillegas]

Producing an official Derby release involves a lot of checkins to the 
Subversion-controlled source code. Only committers have the ability to 
checkin source code.


What you could do is build an unofficial set of jars, sign them, and 
post them on a public artifactory.


-Rick

On 1/28/24 8:29 AM, Andrea Selva wrote:

Hi

On Sat, Jan 27, 2024 at 5:56 PM Bryan Pendleton 
wrote:


I don't know of any plans to build another release of 10.16.

It is fairly straightforward for you to build your own release with
the fix. Rick published information about how to do this here, does
that help for you?


https://issues.apache.org/jira/browse/DERBY-7147?focusedCommentId=17805250=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17805250


Those instructions help to create the jars locally, but would be helpful to
have an official release in a public maven repository. Do you know if there
is anything I can do to help with this?



bryan

Andrea
On Fri, Jan 26, 2024 at 5:46 AM Andrea Selva 
wrote:

Hi folks,
looking at 10.16 branch seems that DERBY-7147 has been backported and

checking at file tools/ant/properties/release.properties the
release.id.long is bumped to 10.16.1.2.

There is any plan to ship the release 10.16.1.2?

Thanks
   Andrea

Re: JDK 22 RDP2 & Deprecate sun.misc.Unsafe Memory-Access Methods…

[Rick Hillegas]

Thanks, David. Derby found no problems with build 22-ea+33-2356. See 
https://issues.apache.org/jira/browse/DERBY-7159


On 1/26/24 3:11 AM, David Delabassee wrote:

Greetings!

We are starting 2024 with JDK 22 as it has just entered Rampdown Phase 2 [1]. 
And with the initial JDK 22 Release Candidates now less than 2 weeks away (Feb. 
8th) [2], it is time to shift our attention to JDK 23.

After multiple rounds of incubations and preview, the Foreign Function & Memory 
API is becoming standard and permanent in JDK 22. If we put its 'Function' angle 
aside, this API also offers a standard and secure way to access off-heap API. And 
that brings us to the heads-up below 'Deprecate the memory-access methods in 
sun.misc.Unsafe for removal in a future release' as developers still using 
sun.misc.Unsafe for accessing memory are strongly encouraged to start preparing 
their plans to migrate away from those unsafe methods.

[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-January/008675.html
[2] https://openjdk.org/projects/jdk/22/


## Heads-up: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal 
in a Future Release

The effort focused on enforcing the integrity of the Java platform [3] 
continues! The next phase in that long but important initiative will most 
likely target the sun.misc.Unsafe API used for accessing memory. Those methods 
alone represent 79 methods out of the 87 sun.misc.Unsafe methods!

This draft JEP [4] outlines the plan to deprecate for removal the 
sun.misc.Unsafe Memory-Access methods, the reasons, and the standard 
alternatives. As the draft plan suggests, the first step will be to deprecate 
all memory-access methods (on-heap, off-heap, and bimodal) for removal. This 
will cause compile-time deprecation warnings for code that refers to the 
methods, alerting library developers to their forthcoming removal. In addition, 
a new command-line option will allow users to receive runtime warnings when 
those methods are used. This command-line will help users to assess if their 
codebase uses those unsafe API to access memory. It should be mentioned that 
other tools such as JFR and jdeprscan can also be used to detect the use of 
those deprecated APIs.

Library developers are strongly encouraged to migrate from sun.misc.Unsafe to 
the supported replacements, so that applications can migrate smoothly to modern 
JDKs. The initial step will be to conduct investigations to understand if, how, 
and where sun.misc.Unsafe methods are used to access memory.

[3] https://openjdk.org/jeps/8305968
[4] https://openjdk.org/jeps/8323072


## Heads-up: Java Array Element Alignment - Weakening of Some Methods 
Guarantees ?

Some methods make promises about Java array element alignment that are too 
strong. There are some ongoing reflexions to change the implementation (and the 
specification) of `MethodHandles::byteArrayViewVarHandle`, 
`MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and 
`ByteBuffer::alignmentOffset` to weaken the guarantees they make about the 
alignment of Java array elements, in order to bring them in line with the 
guarantees made by an arbitrary JVM implementation.

For more details, make sure to check JDK-8320247 [5] and the related PR [6] but 
in a nutshell, the new behaviour would be :
- The `VarHandle` returned by `MethodHandles::byteArrayViewVarHandle` would 
only support `get` and `set` methods, and all other access methods would throw 
an exception.
- The `VarHandle` returned by `MethodHandles::byteBufferViewHandle` would only 
support the `get` and `set` access methods when a heap buffer is used, and all 
other access methods would throw an exception when used with a heap buffer. 
Direct byte buffers will continue to work the same way.
- The `ByteBuffer::alignmentOffset` and `ByteBuffer::alignedSlice` methods 
would throw an exception if the buffer is a heap buffer, and the given 
`unitSize` is greater than 1.

If you have relevant feedback about this potential change, please make sure to 
bring it to the core-libs-dev mailing list [7], or comment on the PR [6].

[5] https://bugs.openjdk.org/browse/JDK-8320247
[6] https://github.com/openjdk/jdk/pull/16681
[7] https://mail.openjdk.org/pipermail/core-libs-dev/


## JDK 22 Early-Access Builds

JDK 22 Early-Access builds 33 are now available [8], and are provided under the 
GNU General Public License v2, with the Classpath Exception. The Release Notes 
[9] and the javadocs [10] are also available.

### Changes in recent JDK 22 builds that may be of interest:

- JDK-8320597: RSA signature verification fails on signed data that does not 
encode params correctly [Reported by Apache POI]
- JDK-8322214: Return value of XMLInputFactory.getProperty() changed from 
boolean to String in JDK 22 early access builds [Reported by Apache POI]
- JDK-8322725: (tz) Update Timezone Data to 2023d
- JDK-8321480: ISO 4217 Amendment 176 Update
- JDK-8314468: Improve Compiler loops
- JDK-8314295: Enhance 

Re: Are we missing updates to some registry for 10.17.1 release?

[Rick Hillegas]

I added a 10.17.1.0 entry to doap_Derby.rdf at the root of the Derby 
website source on 2023-11-10 with the derby-7157-13-aa-updateDOAP.diff 
patch. 10.17.1.0 is the first release listed in that file. I seem to 
recall that it takes a while for information in doap descriptors to 
propagate across Apache processes--but two months seems excessive. I 
don't know if some other authority needs to be updated.


On 1/7/24 7:13 AM, Bryan Pendleton wrote:

Hi Rick,

The Apache automated tools think that the most recent Derby
release was Derby 10.16.

Is there a registry of Apache releases that we need to update to
record that Derby 10.17 is now available?

I think I remember that we have to update the "doap" file?

thanks,

bryan

Re: Updates for our January report to the board please?

[Rick Hillegas]

Nothing from me. Thanks.

On 1/1/24 3:51 PM, Bryan Pendleton wrote:

Hi all, it is time for our January report to the board.

Could you please send me any information about what the community has
been working on over the last three months, so I can include them in
the report?

Two things I already have on my list are:
- The Derby 10.17.1 release
- The updated information about CVE-2022-46337

What else should I include?

thanks,

bryan

Re: JDK 22 Feature Freeze!

[Rick Hillegas]

Thanks, David. Derby has found no problems with build 22-ea+27-2262. See 
https://issues.apache.org/jira/browse/DERBY-7159


On 12/13/23 6:08 AM, David Delabassee wrote:

Welcome to the final OpenJDK Quality Outreach update of 2023!

JDK 22, scheduled for General Availability on March 19, 2024, is now in 
Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 22 feature set is 
frozen (see the final list of JEPs integrated into JDK 22 below) and only 
low-risk enhancements might still be considered. The coming weeks should be 
leveraged to identify and resolve as many issues as possible, i.e. before JDK 
22 enters the Release Candidates phase in early February 2024. So, we count on 
you to test your projects and help us make JDK 22 another solid release!

[1] https://mail.openjdk.org/pipermail/jdk-dev/2023-December/008535.html


## JDK 22 Early-Access Builds

JDK 22 Early-Access builds 27 are now available [2] with the Release Notes here 
[3]. Those builds are provided under the GNU GPL v2, with the Classpath 
Exception.

### JEPs integrated into JDK 22:

- JEP 423: Region Pinning for G1
- JEP 447: Statements before super(…) (Preview)
- JEP 454: Foreign Function & Memory API
- JEP 456: Unnamed Variables & Patterns
- JEP 457: Class-File API (Preview)
- JEP 458: Launch Multi-File Source-Code Programs
- JEP 459: String Templates (2nd Preview)
- JEP 460: Vector API (7th Incubator)
- JEP 461: Stream Gatherers (Preview)
- JEP 462: Structured Concurrency (2nd Preview)
- JEP 463: Implicitly Declared Classes and Instance Main Methods (2nd Preview)
- JEP 464: Scoped Values (2nd Preview)

### Changes in recent JDK 22 builds that may be of interest:

- JDK-8318646: Integer#parseInt("") throws empty NumberFormatException message 
[Reported by Apache Lucene]
- JDK-8318082: ConcurrentModificationException from IndexWriter [Reported by 
JOOQ]
- JDK-8319450: New methods java.net.InetXAddress.ofLiteral() miss @since tag 
[Reported by JaCoCo]
- JDK-8321164: javac w/ annotation processor throws AssertionError: Filling 
jrt:/… during … [Reported by Hibernate]
- JDK-8310644: Make panama memory segment close use async handshakes
- JDK-8302233: HSS/LMS: keytool and jarsigner changes
- JDK-8211238: New @Deprecated JFR event
- JDK-8319124: Update XML Security for Java to 3.0.3
- JDK-8306055: Add a built-in Catalog to JDK XML module
- JDK-8319244: implement JVMTI handshakes support for virtual threads
- JDK-8319196: ExecutableElement.getReceiverType doesn't return receiver types 
for methods loaded from bytecode
- JDK-8318759: Add four DigiCert root certificates
- JDK-8317374: Add Let's Encrypt ISRG Root X2
- JDK-8306116: Update CLDR to Version 44.0
- JDK-8287843: File::getCanonicalFile doesn't work for \\?\C:\ style 
paths DOS device paths
- JDK-8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with 
"InterruptedException: sleep interrupted"
- JDK-8311596: Add separate system properties for TLS server and client for 
maximum chain length
- JDK-8318160: javac does not reject private method reference with 
type-variable receiver
- JDK-8305753: Allow JIT compilation for -Xshare:dump
- JDK-8187591: -Werror turns incubator module warning to an error
- JDK-8318096: Introduce AsymmetricKey interface with a getParams method
- JDK-8319174: Enhance robustness of some j.m.BigInteger constructors
- JDK-8288899: Changes to java.util.concurrent.ForkJoinPool and ForkJoinTask
- JDK-8272215: Add InetAddress methods for parsing IP address literals
- JDK-8316996: Catalog API Enhancement: add a factory method
- JDK-8305814: Update Xalan Java to 2.7.3
- JDK-8313643: Update HarfBuzz to 8.2.2
- JDK-8316030: Update Libpng to 1.6.40

Note: A more comprehensive list of changes can be found here [4].

[2] https://jdk.java.net/22/
[3] https://jdk.java.net/22/release-notes
[4] https://github.com/openjdk/jdk/compare/jdk-22+20...jdk-22+27


## JDK 23 Early-Access Builds

Given that JDK 22 is in Rampdown Phase, the initial JDK 23 EA builds are now 
also available [5]. These EA builds are provided under the GNU General Public 
License v2, with the Classpath Exception.

[5] https://jdk.java.net/23/


## JavaFX 22 Early-Access Builds

These are early-access builds of the JavaFX 22 [8] Runtime built from 
openjdk/jfx [9]. This allows JavaFX application developers to build and test 
their applications with JavaFX 22 on JDK 22. The JavaFX 22 API Javadocs are 
also available [10].

The JavaFX runtime is delivered as an SDK and as a set of jmods for each 
platform. You can use the SDK to compile and run JavaFX applications. You can 
use the jmods with jlink to create a JDK that includes the JavaFX modules, and 
optionally, your modular application. JavaFX 22 is designed to work with JDK 
22,but it is known to work with JDK 17 and later versions.

[8] https://jdk.java.net/javafx22/
[9] https://github.com/openjdk/jfx
[10] 
https://download.java.net/java/early_access/javafx22/docs/api/overview-summary.html


## Topics of Interest:

- Java 22 

Re: announcement messages

[Rick Hillegas]

Yes, and that was the same advice which INFRA give me at 
https://issues.apache.org/jira/browse/INFRA-25158. Still no joy for the 
announce@ list. Thanks for checking.


On 11/14/23 2:28 PM, Bryan Pendleton wrote:

Yes, I got the derby-dev , derby-user, and general message.

I did not see anything on the announce list from you. Did you try that
link I sent?

On Tue, Nov 14, 2023 at 11:11 AM Rick Hillegas  wrote:

Thanks, Bryan. I have re-tried sending the announcement, this time
setting my from address to my gmail acccount (which is the forwarding
account for my apache email account). The mail to annou...@apache.org
bounced immediately, complaining that it was not sent from my apache
email account. Did you see the email which I sent to derby-dev,
derby-user, and general@db?

On 11/13/23 5:18 PM, Bryan Pendleton wrote:

Nope, didn't see either one.

bryan

On Mon, Nov 13, 2023 at 4:27 PM Rick Hillegas  wrote:

This morning, I sent an announcement message for the 10.17.1.0 release
to annou...@apache.org and another announcement message to derby-dev,
derby-user, and general@db. I have not seen either of these messages in
my inboxes. Has anyone else seen these messages?

Thanks,

-Rick

Re: announcement messages

[Rick Hillegas]

Thanks, Bryan. I have re-tried sending the announcement, this time 
setting my from address to my gmail acccount (which is the forwarding 
account for my apache email account). The mail to annou...@apache.org 
bounced immediately, complaining that it was not sent from my apache 
email account. Did you see the email which I sent to derby-dev, 
derby-user, and general@db?


On 11/13/23 5:18 PM, Bryan Pendleton wrote:

Nope, didn't see either one.

bryan

On Mon, Nov 13, 2023 at 4:27 PM Rick Hillegas  wrote:

This morning, I sent an announcement message for the 10.17.1.0 release
to annou...@apache.org and another announcement message to derby-dev,
derby-user, and general@db. I have not seen either of these messages in
my inboxes. Has anyone else seen these messages?

Thanks,

-Rick

[ANNOUNCE] Apache Derby 10.17.1.0 released

[Rick Hillegas]

The Apache Derby project is pleased to announce feature release 10.17.1.0.

Apache Derby is a sub-project of the Apache DB project. Derby is a pure 
Java relational database engine which conforms to the ISO/ANSI SQL and 
JDBC standards. Derby aims to be easy for developers and end-users to 
work with.


The chief feature of this release is the removal of calls to deprecated 
Java APIs. Derby 10.17.1.0 has been built and tested on the Java SE 21 
platform, and will run only on Java SE 21 and newer Java platforms. 
Derby 10.17.1.0 cannot be used with older Java platforms. Please see 
http://db.apache.org/derby/derby_downloads.html for more details 
regarding which Derby releases are compatible with which Java platforms.


In addition, Derby 10.17.1.0 fixes a flaw in Derby's LDAP authentication 
logic (CVE-2022-46337).


Derby 10.17.1.0 contains other bug and documentation fixes. The release 
can be obtained from the Derby download site:


http://db.apache.org/derby/derby_downloads.html.

Please try out this new release.

announcement messages

[Rick Hillegas]

This morning, I sent an announcement message for the 10.17.1.0 release 
to annou...@apache.org and another announcement message to derby-dev, 
derby-user, and general@db. I have not seen either of these messages in 
my inboxes. Has anyone else seen these messages?


Thanks,

-Rick

Re: draft release announcement for Derby 10.17.1.0

[Rick Hillegas]

On 11/10/23 12:11 PM, Bryan Pendleton wrote:

Derby 10.17.1.0 has been built and tested on the
Java SE 21 platform, and will run only on Java SE 21 and newer Java
platforms. Derby 10.17.1.0 cannot be used with older Java platforms.
Please seehttp://db.apache.org/derby/derby_downloads.html  for more
details regarding which Derby releases are compatible with which Java
platforms.


Thanks for that feedback, Bryan. Here is a second draft, which 
incorporates your advice:


-

The Apache Derby project is pleased to announce feature release 10.17.1.0.

Apache Derby is a sub-project of the Apache DB project. Derby is a pure 
Java relational database engine which conforms to the ISO/ANSI SQL and 
JDBC standards. Derby aims to be easy for developers and end-users to 
work with.


The chief feature of this release is the removal of calls to deprecated 
Java APIs. Derby 10.17.1.0 has been built and tested on the Java SE 21 
platform, and will run only on Java SE 21 and newer Java platforms. 
Derby 10.17.1.0 cannot be used with older Java platforms. Please see 
http://db.apache.org/derby/derby_downloads.html for more details 
regarding which Derby releases are compatible with which Java platforms.


In addition, Derby 10.17.1.0 fixes a flaw in Derby's LDAP authentication 
logic (CVE-2022-46337).


Derby 10.17.1.0 contains other bug and documentation fixes. The release 
can be obtained from the Derby download site:


http://db.apache.org/derby/derby_downloads.html.

Please try out this new release.

draft release announcement for Derby 10.17.1.0

[Rick Hillegas]

Here is a first draft. Please let me know how to improve it.

---

The Apache Derby project is pleased to announce feature release 10.17.1.0.

Apache Derby is a sub-project of the Apache DB project. Derby is a pure 
Java relational database engine which conforms to the ISO/ANSI SQL and 
JDBC standards. Derby aims to be easy for developers and end-users to 
work with.


The chief feature of this release is the removal of calls to deprecated 
Java APIs. This lets the release run on the Java SE 21 platform.


In addition, Derby 10.17.1.0 fixes a flaw in Derby's LDAP authentication 
logic (CVE-2022-46337).


Derby 10.17.1.0 contains other bug and documentation fixes. Derby 
10.17.1.0 can be obtained from the Derby download site:


   http://db.apache.org/derby/derby_downloads.html.

Please try out this new release.

[RESULT][VOTE] 10.17.1.0 release

[Rick Hillegas]

Thanks for everyone's work on coding, documenting, and testing 
10.17.1.0. The polls have closed. The community has approved 10.17.1.0 
as an official Derby release:


+1:
Bryan Pendleton (pmc)
Knut Anders Hatlen (pmc)
Rick Hillegas (pmc)

No other votes were cast.

Re: [VOTE] 10.17.1.0 release

[Rick Hillegas]

Using a Mac OSX 11.2.3 laptop, I have run full tests of 10.17.1.0 using 
the classpath and the modulepath as well as upgrade tests from all 
previous Derby versions. I have verified the top links in the release 
index, verified the structure of all distributions, and verified that 
code and docs can be built from the source distro.


+1


On 10/22/23 4:11 PM, Rick Hillegas wrote:
Please test-drive the 10.17.1.0 candidate, then vote on whether to 
accept it as a Derby release. The candidate lives at:


https://dist.apache.org/repos/dist/dev/db/derby/db-derby-10.17.1.0/

The polls close at 5:00 pm California time on Monday November 6.

10.17.1.0 is a feature release, described in greater detail here: 
https://cwiki.apache.org/confluence/display/DERBY/DerbyTenSeventeenOneRelease 



Thanks to everyone who contributed to this release.

Regards,
-Rick

Re: derby 10.17.1 release?

[Rick Hillegas]

Much appreciated, Bryan.

On 10/26/23 5:34 PM, Bryan Pendleton wrote:

Short progress report:
- I've successfully tested the distribution on Linux Ubuntu 20.04 with
OpenJDK 21.
- I've verified the signatures and checksums on the distribution

I'm going to try to find time this weekend to do some testing with
both Windows 10 and Windows 11.

Thanks for getting the RC together so quickly, Rick!

bryan

On Mon, Oct 9, 2023 at 1:05 PM Rick Hillegas  wrote:

I volunteer to be release manager for 10.17.1. I have posted a schedule
for this release:
https://cwiki.apache.org/confluence/display/DERBY/DerbyTenSeventeenOneRelease
. I expect to post the first rev of release notes next Monday
(2023-10-16). If all goes well, the release should be published by
2023-11-10.

Thanks to everyone who has volunteered to vet this release.

-Rick

On 10/2/23 9:46 AM, Rick Hillegas wrote:

Our last release is dated May 2022. Would anyone be willing to vet a
new release if I produce it? The key features would be support for the
new LTS version of Java (Java 21) plus a security fix we worked on
earlier this year.

Thanks,

-Rick

[VOTE] 10.17.1.0 release

[Rick Hillegas]

Please test-drive the 10.17.1.0 candidate, then vote on whether to 
accept it as a Derby release. The candidate lives at:


https://dist.apache.org/repos/dist/dev/db/derby/db-derby-10.17.1.0/

The polls close at 5:00 pm California time on Monday November 6.

10.17.1.0 is a feature release, described in greater detail here: 
https://cwiki.apache.org/confluence/display/DERBY/DerbyTenSeventeenOneRelease


Thanks to everyone who contributed to this release.

Regards,
-Rick

first draft of release notes for 10.17.1.0 posted

[Rick Hillegas]

See https://svn.apache.org/repos/asf/db/derby/code/trunk/RELEASE-NOTES.html

Re: derby 10.17.1 release?

[Rick Hillegas]

I volunteer to be release manager for 10.17.1. I have posted a schedule 
for this release: 
https://cwiki.apache.org/confluence/display/DERBY/DerbyTenSeventeenOneRelease 
. I expect to post the first rev of release notes next Monday 
(2023-10-16). If all goes well, the release should be published by 
2023-11-10.


Thanks to everyone who has volunteered to vet this release.

-Rick

On 10/2/23 9:46 AM, Rick Hillegas wrote:
Our last release is dated May 2022. Would anyone be willing to vet a 
new release if I produce it? The key features would be support for the 
new LTS version of Java (Java 21) plus a security fix we worked on 
earlier this year.


Thanks,

-Rick

Re: derby 10.17.1 release?

[Rick Hillegas]

Thanks, Bryan. I'll see if I can scare up one of our alumnae to help vet 
the release.


On 10/2/23 7:49 PM, Bryan Pendleton wrote:

I can definitely be a tester!

I have access to both Windows 10 and to Linux (Ubuntu 20.04) environments.

bryan

On Mon, Oct 2, 2023 at 9:46 AM Rick Hillegas  wrote:

Our last release is dated May 2022. Would anyone be willing to vet a new
release if I produce it? The key features would be support for the new
LTS version of Java (Java 21) plus a security fix we worked on earlier
this year.

Thanks,

-Rick

derby 10.17.1 release?

[Rick Hillegas]

Our last release is dated May 2022. Would anyone be willing to vet a new 
release if I produce it? The key features would be support for the new 
LTS version of Java (Java 21) plus a security fix we worked on earlier 
this year.


Thanks,

-Rick

Re: JDK 21 Release Candidates & JVM Language Summit

[Rick Hillegas]

Derby builds and tests cleanly with Open JDK build 21+35-2513. See 
https://issues.apache.org/jira/browse/DERBY-7155


Regards,
-Rick

On 8/22/23 7:15 AM, David Delabassee wrote:

Greetings!

JDK 21 is now in the Release Candidate Phase so everything is on track for the 
Java 21 GA release on September 19th! If you haven't done so, please start 
testing your project(s) using JDK 22 Early-Access builds and let us know the 
results.

In other news, the JVM Language Summit took place a few days ago in Santa Clara 
(California). During this unique gathering of Java architects and OpenJDK 
developers, key updates were shared and discussed, ex. where Valhalla stands 
today, the new Class-File API, an update on Leyden and Valhalla, Project 
Panama, the challenges of Virtual Threads, continuation internals, etc. We have 
started to publish the JVMLS 2023 videos so make sure to keep an eye on this 
evolving JVMLS playlist [1] to understand where the Java platform is heading to.


## JDK 21 Early-Access Builds

Per the JDK 21 schedule [2], we are now in the Release-Candidate Phase. The 
overall feature set [3] is frozen, no further JEPs will be targeted to this 
release.

### JEPs integrated to JDK 21:
- 430: String Templates (Preview)
- 431: Sequenced Collections
- 439: Generational ZGC
- 440: Record Patterns
- 441: Pattern Matching for switch  
- 442: Foreign Function & Memory API (3rd Preview)
- 443: Unnamed Patterns and Variables (Preview)   
- 444: Virtual Threads
- 445: Unnamed Classes and Instance Main Methods (Preview)
- 446: Scoped Values (Preview)
- 448: Vector API (6th Incubator)
- 449: Deprecate the Windows 32-bit x86 Port for Removal
- 451: Prepare to Disallow the Dynamic Loading of Agents
- 452: Key Encapsulation Mechanism API
- 453: Structured Concurrency (Preview)

The first JDK 21 Release Candidate builds (builds 35) are available [4]. Those 
builds are provided under the GNU General Public License v2, with the Classpath 
Exception. The Release Notes [5] and the Javadocs [6] are also available.

[1] https://www.youtube.com/playlist?list=PLX8CzqL3ArzW90jKUCf4H6xCKpStxsOzp
[2] https://openjdk.org/projects/jdk/21/#Schedule
[3] https://openjdk.org/projects/jdk/21/#Features
[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/


## JDK 22 Early-Access Builds

The latest Early-Access builds 11 are available [7], and are provided under the 
GNU General Public License v2, with the Classpath Exception. The Release Notes 
are available here [8].

### Changes in recent JDK 22 builds (b8-b11) that may be of interest:

Note that this is only a curated list of changes, make sure to check [9] for 
additional changes.

- JDK-8314209: Wrong @since tag for RandomGenerator::equiDoubles [Reported by 
JaCoCo]
- JDK-8312489: Increase Default Value of the System Property 
jdk.jar.maxSignatureFileSize
- JDK-8312433: HttpClient request fails due to connection being considered …
- JDK-8313307: java/util/Formatter/Padding.java fails on some Locales
- JDK-8312821: Javac accepts char literal as template
- JDK-8313251: Add NativeLibraryLoad event
- JDK-8313809: String template fails with java.lang.StringIndexOutOfBoundsE…
- JDK-8312984: javac may crash on a record pattern with too few components
- JDK-8310033: Clarify return value of Java Time compareTo methods
- JDK-8302017: Allocate BadPaddingException only if it will be thrown
- JDK-8310913: Move ReferencedKeyMap to jdk.internal so it may be shared
- JDK-8313251: Add NativeLibraryLoad event to provide more detail about shared 
lib/dll loads
- JDK-8311653: Modify -XshowSettings launcher behavior
- JDK-8306441: Two phase segmented heap dump
- JDK-8311981: JVM May Hang When Using Generational ZGC if a VM Handshake 
Stalls on Memory
- JDK-8308850: Change JVM options with small ranges that get -Wconversion 
warnings to 32 bits

[7] https://jdk.java.net/22/
[8] https://jdk.java.net/22/release-notes
[9] https://github.com/openjdk/jdk/compare/jdk-22%2B8...jdk-22%2B11


## JavaFX 21 & 22 Early-Access Builds

These are early-access builds of the JavaFX Runtime, built from openjdk/jfx 
[10]. They allow JavaFX application developers to build and test their 
applications with JavaFX 21 or 22 on the latest JDK.

The latest builds 29 (2023/8/7) of JavaFX 21 are now available [11]. The 
early-access builds 5 (2023/8/18) of the JavaFX 22 Runtime which is designed to 
work with JDK 22 are also available [12]. These early-access builds are 
provided under the GNU General Public License, version 2, with the Classpath 
Exception. Please send the feedback on the openjfx-dev mailing list [13].

[10] https://github.com/openjdk/jfx
[11] https://jdk.java.net/javafx21/
[12] https://jdk.java.net/javafx22/
[13] http://mail.openjdk.org/mailman/listinfo/openjfx-dev


## Topics of Interest:

JDK 21: G1/Parallel/Serial GC improvements
https://tschatzl.github.io/2023/08/04/jdk21-g1-parallel-gc-changes.html

To Java 21 and 

Re: JDK 22 is in Rampdown Phase 2 | Annotation Processing Change Heads-up

[Rick Hillegas]

Thanks, David. Derby builds and tests cleanly with Open JDK build 
21-ea+33-2490. See https://issues.apache.org/jira/browse/DERBY-7155


On 7/28/23 2:26 AM, 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
- JDK-8227229: Deprecate the launcher -Xdebug/-debug flags that have not done 
anything since Java 6
- JDK-6983726: Reimplement MethodHandleProxies.asInterfaceInstance
- JDK-8281658: Add a security category to the 

Re: Updates for our July report to the board?

[Rick Hillegas]

Nothing from me. Thanks, Bryan

On 6/29/23 7:04 AM, Bryan Pendleton wrote:

Hi all, it's time for our quarterly report, please let me
know of any updates about community activities in
April-June that we should include!

Our report isn't due for another 2 weeks, but I'll
be away from keyboard for the next week so I'm
starting early :)

thanks,

bryan

Re: Updates for our quarterly report to the board?

[Rick Hillegas]

On 4/3/23 5:50 AM, Bryan Pendleton wrote:

Hi all, it's time for our quarterly report, please let me
know of any updates about community activities this
winter that we should include!

thanks,

bryan


Thanks, Bryan. Nothing from me.

Re: JDK 20 Release Candidate and Deprecation

[Rick Hillegas]

Thanks for the heads-up, David. Derby builds and tests cleanly with Open 
JDK build 20+36-2344.


On 2/14/23 9:32 PM, 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 instability when stack overflows
- JDK-8298377: JfrVframeStream causes deadlocks in ZGC


## JDK 21 Early-Access builds

The JDK 21 Early-Access (builds 9) are available [9], and are provided 
under the GNU General Public License v2, with 

Re: JDK 20 Rampdown Phase 2 & JMX Heads-up

[Rick Hillegas]

Thanks, David. I can confirm that Derby builds and tests cleanly using 
Open JDK build 20-ea+32-2328. Cheers


On 1/24/23 9:11 PM, David Delabassee wrote:

Hi,

First off, on behalf of Oracle’s Java Team, I’d like to wish you a 
happy and prosperous new year!


In 2023, two Java releases will be made available: JDK 20 (March) &  
JDK 21 (September).


JDK 20 [1] has entered Rampdown Phase Two (RDP2) [2], its initial 
Release Candidate is planned for February 9. Given that and to be 
better prepared for the future, it makes sense to begin testing your 
project(s) using JDK 21 early-access (EA) builds. Your feedback allows 
us to evaluate and address issues you find while testing EA builds.


[1] https://jdk.java.net/20/
[2] https://mail.openjdk.org/pipermail/jdk-dev/2023-January/007308.html
[3] https://jdk.java.net/21/


## Heads-up - JDK 21: JMX Subject Delegation & Fine-grained Security 
Deprecation


JMX has some features that rely on Security Manager APIs which are 
deprecated for removal (see JEP 411 [4]). These features are "Subject 
Delegation" and "Fine-grained Security", which both seem to be 
generally unused, and would require significant investment to 
implement without touching the deprecated APIs. As a consequence, 
"Subject Delegation" is being proposed for deprecation in JDK 21 [5].


Fine-grained Security is also being considered for deprecation at the 
same time. This feature [6] has allowed configuration of a security 
policy to restrict or permit access to specific MBean actions. It is 
expected that this feature is generally unused, possibly because there 
is simply no demand for such detailed control, and that it is too 
complex to create and maintain the policies.


[4] https://openjdk.org/jeps/411
[5] https://bugs.openjdk.org/browse/JDK-8298966
[6] 
https://docs.oracle.com/en/java/javase/19/jmx/fine-grained-security-example.html



## JDK 20 Early-Access builds

The latest early-access builds of JDK 20 (builds 32) 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://openjdk.org/projects/jdk/20/
[8] https://jdk.java.net/20/release-notes

### JEPs integrated into JDK 20:

- JEP 429: Scoped Values (Incubator)
- JEP 432: Record Patterns (2nd Preview)
- JEP 433: Pattern Matching for switch (4th Preview)
- JEP 434: Foreign Function & Memory API (2nd Preview)
- JEP 436: Virtual Threads (2nd Preview)
- JEP 437: Structured Concurrency (2nd Incubator)

### Changes in recent JDK 20 builds that may be of interest:

- JDK-8298525: javadoc crashes with "UnsupportedOperationException: 
Not yet implemented" in SeeTaglet.inherit [Reported by Apache Ant]

- JDK-8298893: Rename option UsePolyIntrinsics to UsePoly1305Intrinsics
- JDK-8287411: Enhance DTLS Performance
- JDK-8293554: Enhanced DH Key Exchanges


## JDK 21 Early-Access builds

The latest early-access builds of JDK 21 (builds 6) are available [9], 
and are provided under the GNU General Public License v2, with the 
Classpath Exception. The related EA API Javadoc is also available [10].


[9] https://jdk.java.net/21/
[10] https://download.java.net/java/early_access/jdk21/docs/api/

### Changes in recent JDK 21 builds that may be of interest:

- JDK-8297295: Remove ThreadGroup.allowThreadSuspension
- JDK-8287411: Enhance DTLS performance
- JDK-8233269: Improve handling of JAVA_ARGS
- JDK-8297933: Compiler should only use verified interface types for 
optimization
- JDK-8298381: Improve handling of session tickets for multiple 
SSLContexts
- JDK-8299501: Usage of constructors of primitive wrapper classes 
should be avoided in java.util API docs
- JDK-8299475: Enhance SocketException by cause where it is missing in 
net and nio area
- JDK-8299544: Improve performance of CRC32C intrinsics (non-AVX-512) 
for small inputs

- JDK-8299576: Reimplement java.io.Bits using VarHandle access
- JDK-8278326: Socket close is not thread safe and other cleanup
- JDK-8299673: Simplify object pinning interactions with string 
deduplication



## JavaFX 20 & 21 Early-Access Builds

These are early-access builds of the JavaFX Runtime, built from 
openjdk/jfx [11]. Those EA builds are intended to allow JavaFX 
application developers to build and test their applications with 
JavaFX 20 on JDK 20. The latest EA builds (JavaFX 20 EA b16 2023/1/14) 
are now available [12] and are provided under the GNU General Public 
License, version 2, with the Classpath Exception. Please note that 
initial JavaFX 21 early-access builds (JavaFX 21 b1 2023/1/19) are now 
available [13] as well.

Feedback should be reported to the openjfx-dev mailing list [14].

[11] https://github.com/openjdk/jfx
[12] https://jdk.java.net/javafx20/
[13] https://jdk.java.net/javafx21/
[14] http://mail.openjdk.org/mailman/listinfo/openjfx-dev


## Topics of Interest:

- On Markdown in (Java) documentation comments
https://mail.openjdk.org/pipermail/javadoc-dev/2023-January/005563.html

- 

Re: FW: Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds

[Rick Hillegas]

Thanks, Kevin. When your fix turns up in a JDK release, I'll test drive 
it. Then I may be able to back out the changes which I made to the Derby 
tests and docs.


On 1/10/23 6:20 AM, Kevin Walls wrote:

Hi, that's great!

Maybe the remoteDeserializationEnabled() method is no longer needed? ( 
derbyTesting/functionTests/tests/management/CacheManagerMBeanTest.java )

Actually hold that thought while I tell you why I just logged a new JDK bug...

The JDK Core Libraries guide has more detail on Serialization Filters.  There 
is logging to show exactly what is rejected.
https://docs.oracle.com/en/java/javase/19/core/serialization-filtering1.html#GUID-6A048F49-052E-4591-9183-2775DC50831E

If I edit the jdk/conf/logging.properties file and uncomment the line:
handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
and add:
java.io.serialization.level = FINE
..then I get a ~/java0.log in the home directory after the test.  The failing 
class is:

   ObjectInputFilter REJECTED: class javax.management.Attribute, array 
length: -1, nRefs: 1, depth: 1, bytes: 102, ex: n/a

Adding javax.management.Attribute to the list in management.properties works.   
 I'm thinking this should be in the list by default: the filter is intended to 
need customisation for non-standard classes, but the basics should work 
automatically.

The Derby test is calling: setAttribute(name, "CollectAccessCounts", 
Boolean.TRUE);
...so not trying to transfer any of its own types across the connection, so 
this probably is a bug in the filter value.  If the parameters included 
Derby-specific classes, you would expect to fail with the default filter and 
need customisation.

Will follow this up in the JDK bug: https://bugs.openjdk.org/browse/JDK-8299891

Thanks!
Kevin



-Original Message-----
From: Rick Hillegas 
Sent: 09 January 2023 21:19
To: Kevin Walls ; derby-dev@db.apache.org
Cc: David Delabassee 
Subject: Re: FW: Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 
Early-Access builds

Thanks for running that experiment, Kevin. I have reproduced your results, 
re-enabled the skipped MBean tests, and documented this on 
https://urldefense.com/v3/__https://issues.apache.org/jira/browse/DERBY-7149__;!!ACWV5N9M2RV99hQ!JMEmA854HVODhgZXeDIVPYms8W096aLG-_TDeYhrp08mYMdNU38xKiOHS4f_Nl1SUz8x4UtmWOlqeW6LVkEpqR5Z$
 .

While I have your attention, what should developers do when they see a
"java.io.InvalidClassException: filter status: REJECTED" error? Is there a way 
to tease out which classes are failing deserialization so that the filter can be tailored 
exactly? It would be nice to give users a workaround more subtle than turning off the 
deserialization filter completely.

Thanks,
-Rick


On 1/6/23 3:59 PM, Kevin Walls wrote:

Hi Rick,

A little more on this MBean test situation.  I think it was just that the 
database itself was not running with the updated filter property setting.

I could reproduce the failure with:
java junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBe
anTest

I could see that passing -D to the test app to relax the filter, does not pass 
the -D to the spawned database process.

I can't see a way to do that with a setting, maybe there is a property 
somewhere, but to test it I added a parameter in the method that sets up the 
command line for MBean tests:

"../java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/management/MBeanTest.java"

124 protected static String[] getCommandLineProperties(boolean 
authentication)
125 {
126 ArrayList list = new ArrayList();
127 list.add("com.sun.management.jmxremote.serial.filter.pattern=");
...etc...

...and rebuilding, I no longer see a failure.

Hopefully  this, or something similar, can be used.  There is no harm in 
setting the filter pattern in earlier JDKs, where it defaults to being blank.   
It would be great to update the recent edit about there being no way to set 
this property, as that seems misleading.   Apologies I didn't get here quick 
enough to avoid that edit!

Thanks,
Kevin

From: Kevin Walls
Sent: 05 January 2023 13:54
To: rick.hille...@gmail.com
Cc: derby-dev@db.apache.org
Subject: Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4
Early-Access builds

Hi Rick,

David pointed me at this thread about the ObjectInputFilter and Derby.  I see 
the notes on the use of -D to set a filter to run the test, but am unsure how 
the database itself is started.  That is in another process? (I think it's on 
the same system, because you had success when changing the management 
properties file.)  How do we ensure that process is started with the same 
arguments/filter pattern?  (That is the process where we need the filter either 
relaxed, or made more specific).

Thanks
Kevin

Re: Topics for our January report to the board?

[Rick Hillegas]

Hi Bryan,

Thanks again for taking care of this chore. Nothing comes to mind.

On 1/10/23 4:45 AM, Bryan Pendleton wrote:

Apparently, during the holiday season, I forgot about our reporting
schedule, and our quarterly report to the board is due tomorrow.

Please let me know of any topics we should include in our January report.

thanks,

bryan

Re: FW: Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds

[Rick Hillegas]

Thanks for running that experiment, Kevin. I have reproduced your 
results, re-enabled the skipped MBean tests, and documented this on 
https://issues.apache.org/jira/browse/DERBY-7149.


While I have your attention, what should developers do when they see a 
"java.io.InvalidClassException: filter status: REJECTED" error? Is there 
a way to tease out which classes are failing deserialization so that the 
filter can be tailored exactly? It would be nice to give users a 
workaround more subtle than turning off the deserialization filter 
completely.


Thanks,
-Rick


On 1/6/23 3:59 PM, Kevin Walls wrote:

Hi Rick,

A little more on this MBean test situation.  I think it was just that the 
database itself was not running with the updated filter property setting.

I could reproduce the failure with:
java junit.textui.TestRunner 
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest

I could see that passing -D to the test app to relax the filter, does not pass 
the -D to the spawned database process.

I can't see a way to do that with a setting, maybe there is a property 
somewhere, but to test it I added a parameter in the method that sets up the 
command line for MBean tests:

"../java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/management/MBeanTest.java"

   124 protected static String[] getCommandLineProperties(boolean 
authentication)
   125 {
   126 ArrayList list = new ArrayList();
   127 list.add("com.sun.management.jmxremote.serial.filter.pattern=");
   ...etc...

...and rebuilding, I no longer see a failure.

Hopefully  this, or something similar, can be used.  There is no harm in 
setting the filter pattern in earlier JDKs, where it defaults to being blank.   
It would be great to update the recent edit about there being no way to set 
this property, as that seems misleading.   Apologies I didn't get here quick 
enough to avoid that edit!

Thanks,
Kevin

From: Kevin Walls
Sent: 05 January 2023 13:54
To: rick.hille...@gmail.com
Cc: derby-dev@db.apache.org
Subject: Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 
Early-Access builds

Hi Rick,

David pointed me at this thread about the ObjectInputFilter and Derby.  I see 
the notes on the use of -D to set a filter to run the test, but am unsure how 
the database itself is started.  That is in another process? (I think it's on 
the same system, because you had success when changing the management 
properties file.)  How do we ensure that process is started with the same 
arguments/filter pattern?  (That is the process where we need the filter either 
relaxed, or made more specific).

Thanks
Kevin

Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds

[Rick Hillegas]

Hi David,

Derby now builds and tests cleanly after the changes introduced by Open 
JDK build 20-ea+27-2213. Our experience is described at 
https://issues.apache.org/jira/browse/DERBY-7149.


Thanks,
-Rick

On 12/21/22 2:27 AM, David Delabassee wrote:

Hi Rick,

There's now a default serialization filter for JMX since 20-EA build 
22 (1), see release notes (2) and test (3). To confirm this is indeed 
the issue, you can either relax the filter to allow your target 
classes to be deserialized, or disable the filter.


(1) https://bugs.openjdk.org/browse/JDK-8283093
(2) https://bugs.openjdk.org/browse/JDK-8295938
(3) 
https://github.com/openjdk/jdk20/commit/628820f47ef9c9ad3cc62e68db9c4dbc7e659154


Thanks,

--David

On 21/12/2022 02:36, Rick Hillegas wrote:

Hi David,

Open JDK build 20-ea+27-2213 introduces another problem. I see the 
following error when unmarshalling an object on behalf of an MBean:


  java.io.InvalidClassException: filter status: REJECTED

I do not see this problem under build 19+36-2238.

Can you point me at the experts who can advise me on how to address 
this issue?


Thanks,
-Rick


On 12/12/22 2:07 AM, David Delabassee wrote:

Welcome to the final OpenJDK Quality Outreach update for 2022!

JDK 20, scheduled for General Availability on March 21 2023, is now 
in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 20 
[2] feature set is frozen (see below the final list of JEPs 
integrated into JDK 20) and only low-risk enhancements might still 
be considered. The coming weeks should be used to identify and 
resolve as many issues as possible, i.e. before JDK 20 enters the 
Release Candidates phase in early February 2023.



## JDK 20 Early-Access builds

The latest Early-Access (builds 27) are available [2] with the 
Release Notes here [3]. Those builds are provided under the GNU GPL 
v2, with the Classpath Exception.


### JEPs integrated into JDK 20:

JEP 429: Scoped Values (Incubator)
JEP 432: Record Patterns (2nd Preview)
JEP 433: Pattern Matching for switch (4th Preview)
JEP 434: Foreign Function & Memory API (2nd Preview)
JEP 436: Virtual Threads (2nd Preview)
JEP 437: Structured Concurrency (2nd Incubator)

[1] 
https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html
[2] 
https://urldefense.com/v3/__https://jdk.java.net/20/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTyiVEIUD$ 
[3] 
https://urldefense.com/v3/__https://jdk.java.net/20/release-notes__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTzqxD5c4$ 



### Changes in recent JDK 20 builds that may be of interest:

 Build 27:
- JDK-8297794: Deprecate JMX Management Applets for Removal
- JDK-8297118: Change IncompatibleClassChangeError to MatchException 
for exhaustive switch statements and switch expressions

- JDK-8294047: HttpResponseInputStream swallows interrupts
- JDK-8281236: (D)TLS key exchange named groups
- JDK-8280798: com.sun.jdi.ObjectReference::setValue spec should 
prohibit any final field modification

- JDK-8295350: JFR: Add stop methods for recording streams
- JDK-8295044: Implementation of Foreign Function and Memory API 
(2nd Preview)

- JDK-8296896: Change virtual Thread.yield to use external submit
- JDK-8297804: (tz) Update Timezone Data to 2022g
- JDK-8295803: Console should be usable in jshell and other 
environments

- JDK-828: Implementation of Scoped Values (Incubator)
- JDK-8296672: Implementation of Virtual Threads (2nd Preview)

 Build 26:
- JDK-8297276: Remove thread text from Subject.current
- JDK-8297030: Reduce Default Keep-Alive Timeout Value for httpclient
- JDK-8247645: ChaCha20 Intrinsics

 Build 25:
- JDK-8296472: Remove ObjectLocker around 
appendToClassPathForInstrumentation call
- JDK-8290313: Produce warning when user specified java.io.tmpdir 
directory doesn't exist
- JDK-8288717: Add a means to close idle connections in HTTP/2 
connection pool

- JDK-8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions
- JDK-8059632: Method reference compilation uses incorrect 
qualifying type
- JDK-8297161: Add additional Service Attributes to Standard 
Algorithm Names guide
- JDK-8294073: Performance improvement for message digest 
implementations


 Build 24:
- JDK-8294731: Improve multiplicative inverse for secp256r1 
implementation

- JDK-8296715: CLDR v42 update for tzdata 2022f
- JDK-8296958: [JVMCI] add API for retrieving ConstantValue attributes

 Build 23:
- JDK-8296226: Add constructors (String,Throwable) and (Throwable) 
to InvalidParameterException
- JDK-8295673: Deprecate and disable legacy parallel class loading 
workaround for non-parallel-capable class loaders

- JDK-8294241: Deprecate URL public constructors
- JDK-8289689: (fs) Re-examine the need for normalization to Unicode 
Normalization Format D (macOS)

- JDK-8279164: Disable TLS_ECDH_* cipher suites
- JDK-8178355: IdentityHashMap uses iden

Re: [jira] [Commented] (DERBY-7145) MERGE UPDATE failing: Restore of a serializable or SQLData object of class , attempted to read more data than was originally stored

[Rick Hillegas]

Happy New Year, Stanimir. I have not looked into this further. I gave up 
after sinking a fair amount of time into a seemingly plausible solution. 
The MERGE implementation is unfortunately limited and brittle. It is 
hard to fix one problem without breaking something else. At this time, I 
don't have any clever ideas about how to move this issue forward.


On 1/4/23 12:29 PM, Stanimir Stamenkov via derby-dev wrote:

Hi Rick.  Happy new year!

I've wondered if you had a chance to look further into this one?

– Stanimir


Tue, 11 Oct 2022 22:53:00 + (UTC):

 [ 
https://issues.apache.org/jira/browse/DERBY-7145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616095#comment-17616095 
]


Richard N. Hillegas commented on DERBY-7145:


One thing that looks suspicious to me is the following:

For the failing case (with the DEFAULT clause), the type of the 
stored CS value in the spillover conglomerate is SQLInteger. For the 
successful case (without the DEFAULT clause), the type of that stored 
value is a SQLLongint. This could explain the deserialization error: 
we are trying to read back a SQLLongint from a shorter SQLInteger value.


It may take a little while to chase this down, since the SQLInteger 
is being instantiated inside generated code.



MERGE UPDATE failing: Restore of a serializable or SQLData object of 
class , attempted to read more data than was originally stored
--- 



 Key: DERBY-7145
 URL: https://issues.apache.org/jira/browse/DERBY-7145
 Project: Derby
  Issue Type: Bug
  Components: SQL
    Affects Versions: 10.14.2.0, 10.15.2.0, 10.16.1.1, 10.17.0.0
 Environment: Windows 10, JDK 8, Derby 10.14.2.0;
Windows 10, JDK 11, Derby 10.15.2.0;
Windows 10, JDK 17, Derby 10.16.1.1.
    Reporter: Stanimir Stamenkov
    Priority: Major
 Attachments: bug-demo3.zip, derby.log, derby2.log, sysinfo.txt

Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds

[Rick Hillegas]

Thanks for the quick response, David. I'm afraid I'm still confused. 
Editing conf/management/management.properties to set


  com.sun.management.jmxremote.serial.filter.pattern=*

causes

  java junit.textui.TestRunner 
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest


to run cleanly. However, if I add the following debug printout to the 
test...


    System.out.println("XXX 
com.sun.management.jmxremote.serial.filter.pattern = " + 
System.getProperty("com.sun.management.jmxremote.serial.filter.pattern"));

    System.out.flush();

...then I get the following result:

  XXX com.sun.management.jmxremote.serial.filter.pattern = null

If I revert management.properties to the JDK default and then set the 
property on the boot command line,


  java -Dcom.sun.management.jmxremote.serial.filter.pattern=* 
junit.textui.TestRunner 
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest


...the test prints out

  XXX com.sun.management.jmxremote.serial.filter.pattern = *

but the test fails. It appears that the property is not a system 
property, but is managed somewhere else. Is there a way to override this 
property other than by editing conf/management/management.properties? Do 
developers have to hack the JDK in order to get MBeans to function?


Thanks,
-Rick

On 12/21/22 10:06 PM, David Delabassee wrote:

Hi Rick,

Just to confirm, the params passed below in your tests are passed to 
the JVM that is throwing the exception, right ?


Can you try to comment the filter in 
`JDK/conf/management/management.properties` ?


--David

On 21/12/2022 19:25, Rick Hillegas wrote:
Thanks for those pointers, David. I'm afraid that my naive attempts 
have failed to circumvent this filtering. All of the following 
commands fail with the same "java.io.InvalidClassException: filter 
status: REJECTED" error:


java junit.textui.TestRunner 
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest


java -Djdk.serialFilter=* junit.textui.TestRunner 
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest


java -Dcom.sun.management.jmxremote.serial.filter.pattern=* 
junit.textui.TestRunner 
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest


Any advice you can give would be appreciated.

-Rick


On 12/21/22 2:27 AM, David Delabassee wrote:

Hi Rick,

There's now a default serialization filter for JMX since 20-EA build 
22 (1), see release notes (2) and test (3). To confirm this is 
indeed the issue, you can either relax the filter to allow your 
target classes to be deserialized, or disable the filter.


(1) https://bugs.openjdk.org/browse/JDK-8283093
(2) https://bugs.openjdk.org/browse/JDK-8295938
(3) 
https://urldefense.com/v3/__https://github.com/openjdk/jdk20/commit/628820f47ef9c9ad3cc62e68db9c4dbc7e659154__;!!ACWV5N9M2RV99hQ!NpoMjRUQIuayUbvdDVPAmCP3yMP2w6j3kcsIwQah_EzbUtfJpF6uv2K8AQXJznGfVIVn0pBm3umXdjiqGYyjzdgzGiCc$ 


Thanks,

--David

On 21/12/2022 02:36, Rick Hillegas wrote:

Hi David,

Open JDK build 20-ea+27-2213 introduces another problem. I see the 
following error when unmarshalling an object on behalf of an MBean:


  java.io.InvalidClassException: filter status: REJECTED

I do not see this problem under build 19+36-2238.

Can you point me at the experts who can advise me on how to address 
this issue?


Thanks,
-Rick


On 12/12/22 2:07 AM, David Delabassee wrote:

Welcome to the final OpenJDK Quality Outreach update for 2022!

JDK 20, scheduled for General Availability on March 21 2023, is 
now in Rampdown Phase One (RDP1) [1]. At this point, the overall 
JDK 20 [2] feature set is frozen (see below the final list of JEPs 
integrated into JDK 20) and only low-risk enhancements might still 
be considered. The coming weeks should be used to identify and 
resolve as many issues as possible, i.e. before JDK 20 enters the 
Release Candidates phase in early February 2023.



## JDK 20 Early-Access builds

The latest Early-Access (builds 27) are available [2] with the 
Release Notes here [3]. Those builds are provided under the GNU 
GPL v2, with the Classpath Exception.


### JEPs integrated into JDK 20:

JEP 429: Scoped Values (Incubator)
JEP 432: Record Patterns (2nd Preview)
JEP 433: Pattern Matching for switch (4th Preview)
JEP 434: Foreign Function & Memory API (2nd Preview)
JEP 436: Virtual Threads (2nd Preview)
JEP 437: Structured Concurrency (2nd Incubator)

[1] 
https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html
[2] 
https://urldefense.com/v3/__https://jdk.java.net/20/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTyiVEIUD$ 
[3] 
https://urldefense.com/v3/__https://jdk.java.net/20/release-notes__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTzqxD5c4$ 



### Changes in recent JDK 20 builds that may be of interest:

 

Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds

[Rick Hillegas]

Thanks for those pointers, David. I'm afraid that my naive attempts have 
failed to circumvent this filtering. All of the following commands fail 
with the same "java.io.InvalidClassException: filter status: REJECTED" 
error:


java junit.textui.TestRunner 
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest


java -Djdk.serialFilter=* junit.textui.TestRunner 
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest


java -Dcom.sun.management.jmxremote.serial.filter.pattern=* 
junit.textui.TestRunner 
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest


Any advice you can give would be appreciated.

-Rick


On 12/21/22 2:27 AM, David Delabassee wrote:

Hi Rick,

There's now a default serialization filter for JMX since 20-EA build 
22 (1), see release notes (2) and test (3). To confirm this is indeed 
the issue, you can either relax the filter to allow your target 
classes to be deserialized, or disable the filter.


(1) https://bugs.openjdk.org/browse/JDK-8283093
(2) https://bugs.openjdk.org/browse/JDK-8295938
(3) 
https://github.com/openjdk/jdk20/commit/628820f47ef9c9ad3cc62e68db9c4dbc7e659154


Thanks,

--David

On 21/12/2022 02:36, Rick Hillegas wrote:

Hi David,

Open JDK build 20-ea+27-2213 introduces another problem. I see the 
following error when unmarshalling an object on behalf of an MBean:


  java.io.InvalidClassException: filter status: REJECTED

I do not see this problem under build 19+36-2238.

Can you point me at the experts who can advise me on how to address 
this issue?


Thanks,
-Rick


On 12/12/22 2:07 AM, David Delabassee wrote:

Welcome to the final OpenJDK Quality Outreach update for 2022!

JDK 20, scheduled for General Availability on March 21 2023, is now 
in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 20 
[2] feature set is frozen (see below the final list of JEPs 
integrated into JDK 20) and only low-risk enhancements might still 
be considered. The coming weeks should be used to identify and 
resolve as many issues as possible, i.e. before JDK 20 enters the 
Release Candidates phase in early February 2023.



## JDK 20 Early-Access builds

The latest Early-Access (builds 27) are available [2] with the 
Release Notes here [3]. Those builds are provided under the GNU GPL 
v2, with the Classpath Exception.


### JEPs integrated into JDK 20:

JEP 429: Scoped Values (Incubator)
JEP 432: Record Patterns (2nd Preview)
JEP 433: Pattern Matching for switch (4th Preview)
JEP 434: Foreign Function & Memory API (2nd Preview)
JEP 436: Virtual Threads (2nd Preview)
JEP 437: Structured Concurrency (2nd Incubator)

[1] 
https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html
[2] 
https://urldefense.com/v3/__https://jdk.java.net/20/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTyiVEIUD$ 
[3] 
https://urldefense.com/v3/__https://jdk.java.net/20/release-notes__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTzqxD5c4$ 



### Changes in recent JDK 20 builds that may be of interest:

 Build 27:
- JDK-8297794: Deprecate JMX Management Applets for Removal
- JDK-8297118: Change IncompatibleClassChangeError to MatchException 
for exhaustive switch statements and switch expressions

- JDK-8294047: HttpResponseInputStream swallows interrupts
- JDK-8281236: (D)TLS key exchange named groups
- JDK-8280798: com.sun.jdi.ObjectReference::setValue spec should 
prohibit any final field modification

- JDK-8295350: JFR: Add stop methods for recording streams
- JDK-8295044: Implementation of Foreign Function and Memory API 
(2nd Preview)

- JDK-8296896: Change virtual Thread.yield to use external submit
- JDK-8297804: (tz) Update Timezone Data to 2022g
- JDK-8295803: Console should be usable in jshell and other 
environments

- JDK-828: Implementation of Scoped Values (Incubator)
- JDK-8296672: Implementation of Virtual Threads (2nd Preview)

 Build 26:
- JDK-8297276: Remove thread text from Subject.current
- JDK-8297030: Reduce Default Keep-Alive Timeout Value for httpclient
- JDK-8247645: ChaCha20 Intrinsics

 Build 25:
- JDK-8296472: Remove ObjectLocker around 
appendToClassPathForInstrumentation call
- JDK-8290313: Produce warning when user specified java.io.tmpdir 
directory doesn't exist
- JDK-8288717: Add a means to close idle connections in HTTP/2 
connection pool

- JDK-8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions
- JDK-8059632: Method reference compilation uses incorrect 
qualifying type
- JDK-8297161: Add additional Service Attributes to Standard 
Algorithm Names guide
- JDK-8294073: Performance improvement for message digest 
implementations


 Build 24:
- JDK-8294731: Improve multiplicative inverse for secp256r1 
implementation

- JDK-8296715: CLDR v42 update for tzdata 2022f
- JDK-8296958: [JVMCI] add API for retrieving ConstantVa

Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds

[Rick Hillegas]

Hi David,

Open JDK build 20-ea+27-2213 introduces another problem. I see the 
following error when unmarshalling an object on behalf of an MBean:


  java.io.InvalidClassException: filter status: REJECTED

I do not see this problem under build 19+36-2238.

Can you point me at the experts who can advise me on how to address this 
issue?


Thanks,
-Rick


On 12/12/22 2:07 AM, David Delabassee wrote:

Welcome to the final OpenJDK Quality Outreach update for 2022!

JDK 20, scheduled for General Availability on March 21 2023, is now in 
Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 20 [2] 
feature set is frozen (see below the final list of JEPs integrated 
into JDK 20) and only low-risk enhancements might still be considered. 
The coming weeks should be used to identify and resolve as many issues 
as possible, i.e. before JDK 20 enters the Release Candidates phase in 
early February 2023.



## JDK 20 Early-Access builds

The latest Early-Access (builds 27) are available [2] with the Release 
Notes here [3]. Those builds are provided under the GNU GPL v2, with 
the Classpath Exception.


### JEPs integrated into JDK 20:

JEP 429: Scoped Values (Incubator)
JEP 432: Record Patterns (2nd Preview)
JEP 433: Pattern Matching for switch (4th Preview)
JEP 434: Foreign Function & Memory API (2nd Preview)
JEP 436: Virtual Threads (2nd Preview)
JEP 437: Structured Concurrency (2nd Incubator)

[1] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html
[2] https://jdk.java.net/20/
[3] https://jdk.java.net/20/release-notes


### Changes in recent JDK 20 builds that may be of interest:

 Build 27:
- JDK-8297794: Deprecate JMX Management Applets for Removal
- JDK-8297118: Change IncompatibleClassChangeError to MatchException 
for exhaustive switch statements and switch expressions

- JDK-8294047: HttpResponseInputStream swallows interrupts
- JDK-8281236: (D)TLS key exchange named groups
- JDK-8280798: com.sun.jdi.ObjectReference::setValue spec should 
prohibit any final field modification

- JDK-8295350: JFR: Add stop methods for recording streams
- JDK-8295044: Implementation of Foreign Function and Memory API (2nd 
Preview)

- JDK-8296896: Change virtual Thread.yield to use external submit
- JDK-8297804: (tz) Update Timezone Data to 2022g
- JDK-8295803: Console should be usable in jshell and other environments
- JDK-828: Implementation of Scoped Values (Incubator)
- JDK-8296672: Implementation of Virtual Threads (2nd Preview)

 Build 26:
- JDK-8297276: Remove thread text from Subject.current
- JDK-8297030: Reduce Default Keep-Alive Timeout Value for httpclient
- JDK-8247645: ChaCha20 Intrinsics

 Build 25:
- JDK-8296472: Remove ObjectLocker around 
appendToClassPathForInstrumentation call
- JDK-8290313: Produce warning when user specified java.io.tmpdir 
directory doesn't exist
- JDK-8288717: Add a means to close idle connections in HTTP/2 
connection pool

- JDK-8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions
- JDK-8059632: Method reference compilation uses incorrect qualifying 
type
- JDK-8297161: Add additional Service Attributes to Standard Algorithm 
Names guide

- JDK-8294073: Performance improvement for message digest implementations

 Build 24:
- JDK-8294731: Improve multiplicative inverse for secp256r1 
implementation

- JDK-8296715: CLDR v42 update for tzdata 2022f
- JDK-8296958: [JVMCI] add API for retrieving ConstantValue attributes

 Build 23:
- JDK-8296226: Add constructors (String,Throwable) and (Throwable) to 
InvalidParameterException
- JDK-8295673: Deprecate and disable legacy parallel class loading 
workaround for non-parallel-capable class loaders

- JDK-8294241: Deprecate URL public constructors
- JDK-8289689: (fs) Re-examine the need for normalization to Unicode 
Normalization Format D (macOS)

- JDK-8279164: Disable TLS_ECDH_* cipher suites
- JDK-8178355: IdentityHashMap uses identity-based comparison for 
values everywhere except remove(K,V) and replace(K,V,V)

- JDK-8296108: (tz) Update Timezone Data to 2022f


## Heads-up - JDK 21: First Early-Access Builds

When JDK 20 entered RDP1 [4], the JDK mainline [5] was (a) forked into 
a JDK 20 stabilization repository [6], and (b) set to JDK 21. As a 
consequence, the first JDK 21 Early-Access builds have been published 
[7].


[4] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html
[5] https://github.com/openjdk/jdk
[6] https://github.com/openjdk/jdk20
[7] https://jdk.java.net/21/


## Heads-up - Valhalla: LW4 Early-Access Builds

Valhalla LW4 early-access builds have been published [8], those builds 
are primarily focused on implementing the Value Objects JEP draft [9]. 
For additional details on those EA builds, make sure to read these LW4 
release notes [10]. For a more hands-on introduction to Value Object, 
you can watch the latest JEP Café: Java Value Objects in Action [11]. 
Interested developers are encouraged to explore the performance and 
migration 

Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds

[Rick Hillegas]

Thanks for the heads-up, David. I see many deprecation warnings and 
javadoc warnings when I build Derby with Open JDK build 20-ea+27-2213. 
Right now, I am trying to track down a fix for the problems introduced 
by this change:


- JDK-8294241: Deprecate URL public constructors

My naive attempt to workaround this deprecation was to replace instances of

  new URL(urlString)

with

  (new URI(urlString)).toURL()

Unfortunately, this breaks Derby. I see errors like the following:

java.lang.IllegalArgumentException: URI is not absolute
    at java.base/java.net.URL.of(URL.java:854)
    at java.base/java.net.URI.toURL(URI.java:1144)
    at org.apache.derby.impl.store.raw.RawStore.backup(RawStore.java:641)

Can you point me at an expert who can advise me on best practices for 
working around this deprecation?


Thanks,
-Rick

On 12/12/22 2:07 AM, David Delabassee wrote:

Welcome to the final OpenJDK Quality Outreach update for 2022!

JDK 20, scheduled for General Availability on March 21 2023, is now in 
Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 20 [2] 
feature set is frozen (see below the final list of JEPs integrated 
into JDK 20) and only low-risk enhancements might still be considered. 
The coming weeks should be used to identify and resolve as many issues 
as possible, i.e. before JDK 20 enters the Release Candidates phase in 
early February 2023.



## JDK 20 Early-Access builds

The latest Early-Access (builds 27) are available [2] with the Release 
Notes here [3]. Those builds are provided under the GNU GPL v2, with 
the Classpath Exception.


### JEPs integrated into JDK 20:

JEP 429: Scoped Values (Incubator)
JEP 432: Record Patterns (2nd Preview)
JEP 433: Pattern Matching for switch (4th Preview)
JEP 434: Foreign Function & Memory API (2nd Preview)
JEP 436: Virtual Threads (2nd Preview)
JEP 437: Structured Concurrency (2nd Incubator)

[1] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html
[2] https://jdk.java.net/20/
[3] https://jdk.java.net/20/release-notes


### Changes in recent JDK 20 builds that may be of interest:

 Build 27:
- JDK-8297794: Deprecate JMX Management Applets for Removal
- JDK-8297118: Change IncompatibleClassChangeError to MatchException 
for exhaustive switch statements and switch expressions

- JDK-8294047: HttpResponseInputStream swallows interrupts
- JDK-8281236: (D)TLS key exchange named groups
- JDK-8280798: com.sun.jdi.ObjectReference::setValue spec should 
prohibit any final field modification

- JDK-8295350: JFR: Add stop methods for recording streams
- JDK-8295044: Implementation of Foreign Function and Memory API (2nd 
Preview)

- JDK-8296896: Change virtual Thread.yield to use external submit
- JDK-8297804: (tz) Update Timezone Data to 2022g
- JDK-8295803: Console should be usable in jshell and other environments
- JDK-828: Implementation of Scoped Values (Incubator)
- JDK-8296672: Implementation of Virtual Threads (2nd Preview)

 Build 26:
- JDK-8297276: Remove thread text from Subject.current
- JDK-8297030: Reduce Default Keep-Alive Timeout Value for httpclient
- JDK-8247645: ChaCha20 Intrinsics

 Build 25:
- JDK-8296472: Remove ObjectLocker around 
appendToClassPathForInstrumentation call
- JDK-8290313: Produce warning when user specified java.io.tmpdir 
directory doesn't exist
- JDK-8288717: Add a means to close idle connections in HTTP/2 
connection pool

- JDK-8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions
- JDK-8059632: Method reference compilation uses incorrect qualifying 
type
- JDK-8297161: Add additional Service Attributes to Standard Algorithm 
Names guide

- JDK-8294073: Performance improvement for message digest implementations

 Build 24:
- JDK-8294731: Improve multiplicative inverse for secp256r1 
implementation

- JDK-8296715: CLDR v42 update for tzdata 2022f
- JDK-8296958: [JVMCI] add API for retrieving ConstantValue attributes

 Build 23:
- JDK-8296226: Add constructors (String,Throwable) and (Throwable) to 
InvalidParameterException
- JDK-8295673: Deprecate and disable legacy parallel class loading 
workaround for non-parallel-capable class loaders

- JDK-8294241: Deprecate URL public constructors
- JDK-8289689: (fs) Re-examine the need for normalization to Unicode 
Normalization Format D (macOS)

- JDK-8279164: Disable TLS_ECDH_* cipher suites
- JDK-8178355: IdentityHashMap uses identity-based comparison for 
values everywhere except remove(K,V) and replace(K,V,V)

- JDK-8296108: (tz) Update Timezone Data to 2022f


## Heads-up - JDK 21: First Early-Access Builds

When JDK 20 entered RDP1 [4], the JDK mainline [5] was (a) forked into 
a JDK 20 stabilization repository [6], and (b) set to JDK 21. As a 
consequence, the first JDK 21 Early-Access builds have been published 
[7].


[4] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html
[5] https://github.com/openjdk/jdk
[6] https://github.com/openjdk/jdk20
[7] https://jdk.java.net/21/


## Heads-up - 

Re: Topics for our October report to the board?

[Rick Hillegas]

On 10/8/22 7:23 AM, Bryan Pendleton wrote:

Hi, it's time to compile our October report to the board.

Please let me know of anything in particular we should include.

thanks,

bryan


Nothing from me. Thanks.

Re: JDK 19 first Release Candidates!

[Rick Hillegas]

Thanks, David. Derby built and tested cleanly with build 36 of Open JDK 
19. See https://issues.apache.org/jira/browse/DERBY-7133


On 8/22/22 6:16 AM, David Delabassee wrote:

Greetings!

I hope you had a chance to take some time off. On our side, and 
despite the summer vacation, everything is on track for the Java 19 GA 
release on September 20th with JDK 19 now in the Release Candidate 
Phase [1]. If you haven't done so yet, it is time to start testing 
your project(s) using the JDK 20 Early-Access builds. Speaking of 
Early-Access builds, there is now a new set of EA builds, i.e., the 
jextract EA builds. jextract is a tool developed under the Project 
Panama umbrella whose goal is to mechanically generates Java bindings 
from native library headers. If you are using the Foreign Function & 
Memory API (Preview Feature in JDK 19), make sure to check jextract 
too (see the jextract section below).


[1] https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006861.html


## Heads-up - New system properties for `System.out` and `System.err` 
in JDK 19


Two new system properties, `stdout.encoding` and `stderr.encoding`, 
have been introduced. The value of these system properties is the 
encoding used by the standard output (`System.out`) and standard error 
(`System.err`) streams. The default values of these system properties 
depend on the platform. The values take on the value of the 
`native.encoding` property when the platform does not provide streams 
for the console. The properties can be overridden on the launcher's 
command line option, with `-D`, to set them to UTF-8 where required. 
For more details see https://bugs.openjdk.org/browse/JDK-8283620



## Heads-up - SSLSocketImpl finalizer implementation removed in JDK 19

The finalizer implementation in SSLSocket has been removed, with the 
underlying native resource releases now done by the Socket 
implementation. With this update, the TLS close_notify messages will 
no longer be emitted if SSLSocket is not explicitly closed. Not 
closing Sockets properly is an error condition that should be avoided. 
Applications should always close sockets and not rely on garbage 
collection. For more details see 
https://bugs.openjdk.org/browse/JDK-8212136



## Heads-up - New providerPath jarsigner option in JDK 19

A new `-providerPath` option has been added to the jarsigner. This 
option is used to specify the class path of an alternate keystore 
implementation, it can be used together with the -providerClass 
option. For more details see https://bugs.openjdk.org/browse/JDK-8281175



## JDK 19 Release Candidate builds

JDK 19 first Release Candidates (builds 36) are now available [2], and 
are provided under the GNU General Public License v2, with the 
Classpath Exception. The Release Notes are available here [3].


[2] https://jdk.java.net/19/
[3] https://jdk.java.net/19/release-notes


## JDK 20 Early-Access builds

JDK 20 Early-Access builds 11 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].


[4] https://jdk.java.net/20/
[5] https://jdk.java.net/20/release-notes

### Recent changes that maybe of interest:

- JDK-8282730: LdapLoginModule throw NPE from logout method after 
login failure

- JDK-8290706: Remove the support for inline contiguous allocations
- JDK-8289551: Conversions between bit representations of half 
precision values and floats
- JDK-8290485: [vector] REVERSE_BYTES for byte type should not emit 
any instructions
- JDK-8289137: Automatically adapt Young/OldPLABSize and when setting 
only MinTLABSize

- JDK-8290034: Auto vectorize reverse bit operations.
- JDK-8290868: NMT: MallocSiteTable statistics improvements
- JDK-8291822: ARM32: Build errors with GCC 11 in 
frame::saved_oop_result [Reported by JaCoCo]

- JDK-8289249: Add methods to Elements for record constructors
- JDK-8283232: x86: Improve vector broadcast operations
- JDK-8288327: Executable.hasRealParameterData should not be volatile
- JDK-8291360: Create entry points to expose low-level class file 
information

- JDK-8290840: Refactor the "os" class
- JDK-8292327: InflaterInputStream.read throws EOFException
- JDK-8155246: Throw error if default java.security file is missing
- JDK-8289332: Auto-generate ids for user-defined headings
- JDK-8292153: x86: Represent Registers as values


## Jextract Early-Access Builds

Early Access Builds 19-jextract+2-3 (2022/7/19) are now available [6]. 
These open-source builds are provided under the GNU General Public 
License, version 2, with the Classpath Exception.


These builds are from the OpenJDK jextract project [7] which is part 
of Code Tools [8]. jextract is a tool developed under the Panama 
umbrealla whose goal is to mechanically generate Java bindings from 
native library headers. These EA builds are intended for advanced 
users, and are provided as a convenience so that they don't need to 
build it from the sources. 

Re: JDK 19: Rampdown Phase 2 + JavaOne

[Rick Hillegas]

Thanks for the heads-up, David. Derby builds and tests cleanly with JDK 
19 build 19-ea+32-2220. See the last comment on 
https://issues.apache.org/jira/browse/DERBY-7133.


On 7/25/22 7:56 AM, David Delabassee wrote:

Greetings!

JDK 19 is now in Rampdown Phase Two [1]. The overall feature set is 
frozen. Per the JDK Release Process [2] we now turn 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].


Given the current state of affairs, it is a good time to start testing 
your project(s) on JDK 20 Early-Access builds. To conclude, please 
make sure to check the heads-up below, including the one covering 
JavaOne!


[1] https://mail.openjdk.org/pipermail/jdk-dev/2022-July/006803.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


## Heads-up - JavaOne is back!

After a long hiatus, JavaOne is back! From October 17-20 in Las Vegas, 
JavaOne will be jam-packed with hundreds of valuable and actionable 
sessions directly from the experts: learning sessions, tutorials, 
hands-on labs, lightning talks, panels, an unconference, BoF's, etc. 
The full JavaOne content catalog will be released soon. In the 
meantime, make sure to check https://inside.java/javaone/ for more 
updates.


And if you are planning to attend JavaOne, please ping me. I'd like to 
meet you in person to chat over OpenJDK and the Quality Outreach 
program. And the drinks will be on me!



## Heads-up - JavaFX Media enhancements survey

The JavaFX team is conducting a short survey [5] to gather input on 
potential JavaFX Media enhancements.
The process is quite simple as the feedback will be collected via the 
openjfx-dev [6] mailing list. So if you are using JavaFX, make sure to 
raise your voice.


[5] https://mail.openjdk.org/pipermail/openjfx-dev/2022-July/034949.html
[6] https://mail.openjdk.org/mailman/listinfo/openjfx-dev


## JDK 19

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

### 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 (4th Incubator)
- JEP 427: Pattern Matching for switch (3rd Preview)
- JEP 428: Structured Concurrency (Incubator)

### Recent changes that maybe of interest:
- JDK-8289127: Apache Lucene triggers: DEBUG MESSAGE: duplicated 
predicate failed which is impossible
- JDK-8290596: Update java.net.InetAddress to Detect Ambiguous IPv4 
Address Literals
- JDK-8290615: Remove the Alternate ThreadLocal Implementation of the 
Subject::current and Subject::callAs APIs

- JDK-8290417: CDS cannot archive lamda proxy with useImplMethodHandle
- JDK-8287809: Revisit implementation of memory session
- JDK-8289278: Suspend/ResumeAllVirtualThreads need both can_suspend 
and can_support_virtual_threads

- JDK-8288589: Files.readString ignores encoding errors for UTF-16
- JDK-8288425: Footprint regression due MH creation when initializing 
StringConcatFactory



## JDK 20

JDK 20 Early-Access builds 7 are now available [9], and are provided 
under the GNU General Public License v2, with the Classpath Exception.


[9] https://jdk.java.net/20/

### Recent changes that maybe of interest:
- JDK-8264999: GeneralPath.lineTo() to itself produces jagged lines 
[Logged by Apache PDFBox]

- JDK-8284997: arm32 build crashes since JDK-8283326 [Logged by JaCoCo]
- JDK-8286101: Support formatting in @value tag
- JDK-8289260: BigDecimal movePointLeft() and movePointRight() do not 
follow their API spec
- JDK-8287835: Add support for additional float/double to integral 
conversion for x86
- JDK-8283091: Support type conversion between different data sizes in 
SLP

- JDK-8288573: Make Executable.getParameterCount() actually abstract
- JDK-8266670: Better modeling of access flags in core reflection
- JDK-8290601: Update java.net.InetAddress to Detect Ambiguous IPv4 
Address Literals

- JDK-8290334: Update FreeType to 2.12.1
- JDK-8286030: Avoid JVM crash when containers share the same /tmp dir
- JDK-8289743: AArch64: Clean up patching logic
- JDK-8288107: Auto-vectorization for integer min/max
- JDK-8274235: -Xshare:dump should not call vm_direct_exit


## Topics of Interest:

* What is OpenJDK? - Inside Java Newscast
https://inside.java/2022/06/30/insidejava-newscast-028/

* “Towards Generational ZGC!” - Inside Java Podcast
https://inside.java/2022/06/29/podcast-024/

* HotSpot Deep Dive - Safepoint
https://inside.java/2022/07/12/hotspot-deep-dive-safepoint/

* Introduction to Project Panama - Part 2: Variadic Functions

Re: Items for our quarterly report to the Board?

[Rick Hillegas]

On 7/5/22 5:46 PM, Bryan Pendleton wrote:

Hi Derby-dev, I'm preparing our quarterly report to the Board.

For this quarter, I think the main item of interest for the
Derby sub-project is the 10.16.1.1 release.

Is there anything else we should include in our report?

thanks,

bryan


Can't think of anything else. Thanks, Bryan.

Re: JDK 19: Rampdown Phase 1 + EA builds 26 & JDK 20: EA builds 1

[Rick Hillegas]

Thanks, David. We have adjusted Derby so that it builds cleanly without 
the new deprecation warnings introduced by Open JDK build 19-ea+27-2074. 
For more details, see the discussion on 
https://issues.apache.org/jira/browse/DERBY-7133.


On 6/13/22 6:18 AM, 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 

[ANNOUNCE] Apache Derby 10.16.1.1 released

[Rick Hillegas]

The Apache Derby project is pleased to announce feature release 10.16.1.1.

Apache Derby is a sub-project of the Apache DB project. Derby is a pure Java 
relational database engine which conforms to the ISO/ANSI SQL and
JDBC standards. Derby aims to be easy for developers and end-users to work with.

The chief feature of this release is the removal of support for the Java 
SecurityManager, anticipating its removal from the Open JDK as part of
https://openjdk.org/jeps/411. Derby 10.16.1.1 runs on JDK 17 and up. Users who 
need to run Derby-powered applications on older JVMs should select an earlier 
version of Derby, as described on the Derby download site.

Derby 10.16.1.1 also contains bug and documentation fixes and it can be 
obtained from the Derby download site:

 http://db.apache.org/derby/derby_downloads.html.

Please try out this new release.

Re: draft release announcement for 10.16.1.1

[Rick Hillegas]

Thanks for that suggestion, Bryan. Here is a second draft:

--

The Apache Derby project is pleased to announce feature release 10.16.1.1.

Apache Derby is a sub-project of the Apache DB project. Derby is a pure 
Java relational database engine which conforms to the ISO/ANSI SQL and 
JDBC standards. Derby aims to be easy for developers and end-users to 
work with.


The chief feature of this release is the removal of support for the Java 
SecurityManager, anticipating its removal from the Open JDK as part of 
https://openjdk.org/jeps/411. Derby 10.16.1.1 runs on JDK 17 and up. 
Users who need to run Derby-powered applications on older JVMs should 
select an earlier version of Derby, as described on the Derby download site.


Derby 10.16.1.1 also contains bug and documentation fixes and it can be 
obtained from the Derby download site:


    http://db.apache.org/derby/derby_downloads.html.

Please try out this new release.

draft release announcement for 10.16.1.1

[Rick Hillegas]

Here is a first draft. Please let me know how to improve it.

---

The Apache Derby project is pleased to announce feature release 10.16.1.1.

Apache Derby is a sub-project of the Apache DB project. Derby is a pure 
Java relational database engine which conforms to the ISO/ANSI SQL and 
JDBC standards. Derby aims to be easy for developers and end-users to 
work with.


The chief feature of this release is the removal of support for the Java 
SecurityManager, anticipating its removal from the Open JDK as part of 
https://openjdk.org/jeps/411.


Derby 10.16.1.1 also contains bug and documentation fixes and it can be 
obtained from the Derby download site:


   http://db.apache.org/derby/derby_downloads.html.

Please try out this new release.

Re: maven publication step for release 10.16.1.1

[Rick Hillegas]

Good idea. I can add that to the release publication instructions. I'm 
not out of the woods yet, though. Some of the artifacts didn't make it 
into the staging repository, failing with "peer authentication" errors 
which I don't understand.


On 6/11/22 7:03 AM, Bryan Pendleton wrote:

I see you simply had a too-old version of Maven? Does that mean that
we need a documentation update to remind us for future releases?

thanks,

bryan

On Wed, Jun 8, 2022 at 10:30 AM Bryan Pendleton
 wrote:

I think we have to figure out the signature part, but I'm afraid I
don't know what's wrong either.

My instinct is that your maven settings file is somehow incorrect, and
maven isn't helping you figure out what's wrong with it :(

bryan

On Wed, Jun 8, 2022 at 9:17 AM Rick Hillegas  wrote:

I am stuck at the step for using maven to publish 10.16.1.1 artifacts.
The details of the issue can be found at
https://issues.apache.org/jira/browse/INFRA-23348

In a nutshell, I have uploaded artifacts and checksums but not gpg
signatures. I do not know how to generate/upload these signatures via
maven. The error messages are opaque.

Are the gpg signatures essential or are the checksums good enough?

Thanks,

-Rick

maven publication step for release 10.16.1.1

[Rick Hillegas]

I am stuck at the step for using maven to publish 10.16.1.1 artifacts. 
The details of the issue can be found at 
https://issues.apache.org/jira/browse/INFRA-23348


In a nutshell, I have uploaded artifacts and checksums but not gpg 
signatures. I do not know how to generate/upload these signatures via 
maven. The error messages are opaque.


Are the gpg signatures essential or are the checksums good enough?

Thanks,

-Rick

10.16.1.1 publication status

[Rick Hillegas]

The publication of 10.16.1.1 cannot start until the cwiki is available. 
That's where our release publication instructions live. The cwiki is 
undergoing some kind of maintenance right now.

[RESULT] [VOTE] 10.16.1.1 Release

[Rick Hillegas]

Thanks for catching that, Bryan. Re-sending...

On 6/2/22 5:43 PM, Bryan Pendleton wrote:

Not a huge deal, Rick, but the subject line of your message is wrong! :)

bryan

On Thu, Jun 2, 2022 at 5:28 PM Rick Hillegas  wrote:

Thanks for everyone's work on coding, documenting, and testing
10.16.1.1. The polls have closed. The community has approved 10.16.1.1
as an official Derby release:

+1:
Dag Wanvik (pmc)
Bryan Pendleton (pmc)
Rick Hillegas (pmc)

No other votes were cast.

[RESULT] [VOTE] 10.15.2.0 Release

[Rick Hillegas]

Thanks for everyone's work on coding, documenting, and testing 
10.16.1.1. The polls have closed. The community has approved 10.16.1.1 
as an official Derby release:


+1:
Dag Wanvik (pmc)
Bryan Pendleton (pmc)
Rick Hillegas (pmc)

No other votes were cast.

Re: [VOTE] 10.16.1.1 release

[Rick Hillegas]

Bryan and Dag found additional flaws in this release candidate. I have 
corrected those flaws on the trunk and in the 10.16 branch. I agree with 
Bryan and Dag that these problems should not flunk the vote.


No product problems surfaced in the platform tests recorded at 
https://cwiki.apache.org/confluence/display/DERBY/TenSixteenOnePlatformTesting


Adequate sanity checks were recorded at 
https://cwiki.apache.org/confluence/display/DERBY/TenSixteenChecklist


+1

Re: remaining release-vetting tasks

[Rick Hillegas]

Hey Bryan,

What I do is copy the jars from some release distro into the jars/sane 
directory of my development sandbox and then just run regression tests 
there. Hope this helps.


On 5/28/22 11:54 AM, Bryan Pendleton wrote:

Hey Rick, can you please remind me of the syntax you use to run the
regression tests using the packaged release? I munged around in the
Confluence wiki for a while but came up short.

bryan

On Wed, May 25, 2022 at 2:22 PM Rick Hillegas  wrote:

I have ticked off several of the release-vetting checklist items at
https://cwiki.apache.org/confluence/display/DERBY/TenSixteenChecklist It
would be great if someone else could report on the following outstanding
items:

o Signatures and checksums. I don't think that I should be relied on to
verify these.

o bin scripts on platforms other than Mac OSX. In particular, it would
be good to see reports from Linux and Windows platforms.

Also, it would be good to see test results from Linux and Windows at
https://cwiki.apache.org/confluence/display/DERBY/TenSixteenOnePlatformTesting

Thanks,
-Rick

remaining release-vetting tasks

[Rick Hillegas]

I have ticked off several of the release-vetting checklist items at 
https://cwiki.apache.org/confluence/display/DERBY/TenSixteenChecklist It 
would be great if someone else could report on the following outstanding 
items:


o Signatures and checksums. I don't think that I should be relied on to 
verify these.


o bin scripts on platforms other than Mac OSX. In particular, it would 
be good to see reports from Linux and Windows platforms.


Also, it would be good to see test results from Linux and Windows at 
https://cwiki.apache.org/confluence/display/DERBY/TenSixteenOnePlatformTesting


Thanks,
-Rick

[VOTE] 10.16.1.1 release

[Rick Hillegas]

Please test-drive the 10.16.1.1 candidate, then vote on whether to 
accept it as a Derby release. The candidate lives at:


https://dist.apache.org/repos/dist/dev/db/derby/db-derby-10.16.1.1/

The polls close at 5:00 pm California time on Thursday June 2.

10.16.1.1 is a feature release, described in greater detail here: 
https://cwiki.apache.org/confluence/display/DERBY/DerbyTenSixteenOneRelease


Thanks to everyone who contributed to this release.

Regards,
-Rick

[CANCEL VOTE] 10.16.1.0 release

[Rick Hillegas]

I am cancelling the vote on this release candidate because the links to 
pdf versions of the Reference, Security, Admin, and Tuning Guides are 
broken in the top level index page of the bin distribution. I will fix 
these problems and continue to do more sanity testing before generating 
a new release candidate.


On 5/18/22 8:24 AM, Rick Hillegas wrote:
Please test-drive the 10.16.1.0 candidate, then vote on whether to 
accept it as a Derby release. The candidate lives at:


https://dist.apache.org/repos/dist/dev/db/derby/db-derby-10.16.1.0/

The polls close at 5:00 pm California time on Wednesday June 1.

10.16.1.0 is a feature release, described in greater detail here: 
https://cwiki.apache.org/confluence/display/DERBY/DerbyTenSixteenOneRelease 



Thanks to everyone who contributed to this release.

Regards,
-Rick

[VOTE] 10.16.1.0 release

[Rick Hillegas]

Please test-drive the 10.16.1.0 candidate, then vote on whether to 
accept it as a Derby release. The candidate lives at:


https://dist.apache.org/repos/dist/dev/db/derby/db-derby-10.16.1.0/

The polls close at 5:00 pm California time on Wednesday June 1.

10.16.1.0 is a feature release, described in greater detail here: 
https://cwiki.apache.org/confluence/display/DERBY/DerbyTenSixteenOneRelease


Thanks to everyone who contributed to this release.

Regards,
-Rick

Re: Items for our quarterly update to the board?

[Rick Hillegas]

Thanks, Bryan. I don't have anything to add. Cheers

On 4/4/22 4:31 AM, Bryan Pendleton wrote:

Hi all, I am preparing the April 2022 report for the Board.

Can you please send me any updates that I should include?

So far, the only Derby-related topics I have are:
- the Derby community contributed to the efforts to migrate the DB
websites to the new Apache system
- the Derby community are working on a 10.16 release to address
compatibility with JDK 17+.

thanks,

bryan

Re: removing Derby's references to the Java Security Manager

[Rick Hillegas]

On 3/28/22 6:07 AM, Bryan Pendleton wrote:

rototill away references to the Security Manager and update
the Security Guide accordingly. I estimate that this will take about a
month. My preference would be to delay the 10.16.1 release until this is
done.

This plan is fine with me. Glad to help, as my time permits.

Thanks for moving us forward on this.

bryan


Thanks, Bryan. I have opened 
https://issues.apache.org/jira/browse/DERBY-7138 to track the tasks 
needed to remove references to the SecurityManager. I have adjusted the 
10.16.1 milestones, aiming for a release in early June: 
https://cwiki.apache.org/confluence/display/DERBY/DerbyTenSixteenOneRelease

removing Derby's references to the Java Security Manager

[Rick Hillegas]

The Open JDK regards the Java Security Manager as a large, brittle piece 
of code whose further maintenance costs too much. In some imminent 
release, the JVM will remove the Security Manager. See 
https://openjdk.java.net/jeps/411, 
https://issues.apache.org/jira/browse/DERBY-7110, and 
https://issues.apache.org/jira/browse/DERBY-7126.


For Derby, the Security Manager provides important defenses against the 
mis-use of the following security-sensitive operations:


o Reading and setting of system properties.

o Creation of class loaders.

o File access

o Network access

o De-registration of JDBC drivers

In preparation for the 10.16.1 release, I asked the Open JDK security 
team for advice. How should Derby users protect these operations on a 
future JVM which no longer includes the Security Manager? I asked for 
guidance in a security-...@openjdk.java.net email thread titled 
"protecting security-sensitive operations on multi-tenant servers." The 
security team said:


1) The Security Manager was the wrong solution to this problem.

2) The better, modern solution would be to isolate your application 
inside an operating system container.


This seems to be the situation: In some future release, we will need to 
remove all references to the Security Manager and we will need to tell 
users to containerize their applications.


I'm happy to rototill away references to the Security Manager and update 
the Security Guide accordingly. I estimate that this will take about a 
month. My preference would be to delay the 10.16.1 release until this is 
done. However, there may be some reason to produce a 10.16.1 release 
first (the last release which uses the Security Manager) and introduce 
this change in 10.17.1.


What are your thoughts?

-Rick

proposed 10.16.1 release

[Rick Hillegas]

On https://issues.apache.org/jira/browse/DERBY-7126, Bryan and I have 
been discussing the need for a new Derby release to handle the 
disruption introduced by the Open JDK's deprecation of the Java Security 
Manager (see https://openjdk.java.net/jeps/411). Deprecation-related JDK 
changes have put us in the position that no version of Derby can run 
cleanly on all JDK platforms from JDK 9 on up. The gory details are 
discussed on https://issues.apache.org/jira/browse/DERBY-7110 and 
https://issues.apache.org/jira/browse/DERBY-7126.


I am volunteering to manage a 10.16.1 release. 10.16.1 will be compiled 
into Java 17 byte code so that it won't run on older Java platforms and 
incur the deprecation-related problems. Going forward, the download page 
will advertise the following bindings of Derby versions to Open JDK LTS 
versions:


  10.14 for Java 8
  10.15 for Java 11
  10.16 for Java 17

I have posted a 10.16.1 plan at 
https://cwiki.apache.org/confluence/display/DERBY/DerbyTenSixteenOneRelease 
Let me know if you have any objections or suggestions.


Thanks,
-Rick

Re: JDK 18 Release Candidate builds & JDK 19 Early-Access builds

[Rick Hillegas]

Thanks, David. Derby builds and tests cleanly against Open JDK build 
19-ea+11-661. See https://issues.apache.org/jira/browse/DERBY-7133 for 
more detail.


On 2/28/22 12:19 PM, David Delabassee wrote:

Rick, All,

The Release Candidates of JDK 18 have been released [1]. At this 
stage, only P1 issues will be evaluated [2]. And with the JDK 18 
General Availability sets for March 22nd, it is now time to shift the 
focus to JDK 19. I'd like to thank those of you who have already 
provided feedback on the early Early Builds of JDK 19. Feedback is 
always extremely useful, even more, when it comes early in the 
development cycle.


[1] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006404.html

[2] https://openjdk.java.net/jeps/3


## JDK 18 Release Candidate

The Release Candidate builds of JDK 18 are now available [3], and are 
provided under the GNU General Public License v2, with the Classpath 
Exception. The Release Notes are available here [4].


[3] https://jdk.java.net/18/
[4] https://jdk.java.net/18/release-notes


## JDK 19 Early-Access builds

JDK 19 Early-Access builds 11 are now available [5], and are provided 
under the GNU General Public License v2, with the Classpath Exception. 
The Release Notes are available here [6].


[5] https://jdk.java.net/19/
[6] https://jdk.java.net/19/release-notes

Recent changes that maybe of interest:

* JDK-8278067: Make HttpURLConnection default keep alive timeout 
configurable
* JDK-8281000: ClassLoader::registerAsParallelCapable throws NPE if 
caller is null

* JDK-8282279: Interpret case-insensitive string locale independently
* JDK-8176706: Support CLDR's Additional (Skeleton) Date-Time Formats
* JDK-5041655: (ch) FileLock: negative param and overflow issues
* JDK-8255266: Update Public Suffix List to 3c213aa
* JDK-8280958: G1/Parallel: Unify marking code structure
* JDK-8072070: Improve interpreter stack banging
* JDK-8277175: Add a parallel multiply method to BigInteger
* JDK-8278947: Support for array constants in constant table
* JDK-8281462: Annotation toString output for enum not reusable for 
source input

* JDK-8281175: Add a -providerPath option to jarsigner
* JDK-8277795: ldap connection timeout not honoured under contention
* JDK-8279842: HTTPS Channel Binding support for Java GSS/Kerberos
* JDK-8280744: Allow SuppressWarnings to be used in all declaration 
contexts

* JDK-8272984: javadoc support for reproducible builds
* JDK-8272317: jstatd has dependency on Security Manager which needs 
to be removed



## New Project Loom Early-Access builds

Project Loom Early-Access builds19-loom+4-115 (2022/2/13) are 
available [7] with the related Javadoc [8].


These EA builds are based on JDK 19 (jdk-19+9). In those builds, the 
APIs for Structured Concurrency and Scope Locals have been moved into 
the `jdk.incubator.concurrent` incubator module. Note that the module 
name may change later. To use those APIs, simply use `--add-modules 
jdk.incubator.concurrent` at compile and runtime.


Those EA builds are provided under the GNU General Public License, 
version 2, with the Classpath Exception and are produced for the 
purpose of gathering feedback. Use for any other purpose is at your 
own risk. Proper feedback should be sent to the `loom-dev` mailing 
list [9].


[7] https://jdk.java.net/loom/
[8] https://download.java.net/java/early_access/loom/docs/api/
[9] https://mail.openjdk.java.net/mailman/listinfo/loom-dev


## Topics of Interest

* JDK 18 - Card Table Card Size Shenanigans 
https://tschatzl.github.io/2022/02/15/card-table-card-size.html
* Compiled & Tested Code In Javadoc - Inside Java Newscast #20 
https://inside.java/2022/02/10/insidejava-newscast-020/
* New candidate JEP: 423: Region Pinning for G1 
https://mail.openjdk.java.net/pipermail/jdk-dev/2022-February/006368.html
* Refactoring Java 8 code with Java 17 new features - JEP Café #9 
https://inside.java/2022/02/01/jepcafe9/




As always, let us know if you find any issues while testing your 
projects on the latest JDK Early Access builds. Thanks for your support!


--David

Re: Thanks Rick for getting the derby website migrated to the new system

[Rick Hillegas]

On 2/4/22 7:06 AM, Bryan Pendleton wrote:

Much appreciated!

bryan


No problem, as the youngsters say. You might need to delete your old 
website sandbox and recreate a new one from scratch (see 
https://db.apache.org/derby/papers/derby_web.html). Alternatively, it 
might work to just cd to trunk/build and do an svn update. Haven't tried 
that second approach myself.


Cheers,

-Rick

Re: JDK 18 Rampdown Phase 2 & JDK 19 Early-Access Builds

[Rick Hillegas]

After suppressing the new build warnings introduced by this JDK, Derby 
builds and tests cleanly. See 
https://issues.apache.org/jira/browse/DERBY-7126


Regards,
-Rick

On 1/31/22 1:25 AM, 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 property 
error reporting under specified
- JDK-8276766: Enable jar and jmod to produce deterministic 
timestamped content
- JDK-8274679: Remove unnecessary conversion to String in security 
code in java.base

- JDK-8279833: Loop optimization issue in String.encodeUTF8_UTF16
- JDK-8279064: New options for ktab to provide non-default salt
- JDK-8280055: JFR: Improve ObjectContext implementation
- JDK-8268831: Improve javadoc tool handling of streams


## Topics of Interest:

- "State of Valhalla" update
https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2021-December/001747.html 



- Java's Plans for 2022 - Inside Java Newscast

Re: [INFO] DB report for January, 2022

[Rick Hillegas]

Thanks, Bryan.

On 1/9/22 8:59 AM, Bryan Pendleton wrote:

Below is the quarterly report I submitted to the board.

Thanks all; please let me know of any errors or omissions.

bryan



## Description:
The mission of the Apache DB project is to create and maintain
commercial-quality, open-source, database solutions based on software licensed
to the Foundation, for distribution at no charge to the public.

The Apache DB TLP consists of the following subprojects:
  o Derby: a relational database implemented entirely in Java.
  o JDO  : focused on building the API and the TCK for compatibility
   testing of Java Data Object implementations providing data
   persistence.
  o Torque   : an object-relational mapper for Java.

## Issues:
There are no issues requiring board attention.

## Membership Data:
Apache DB was founded 2002-07-16 (19 years ago)
There are currently 47 committers and 45 PMC members in this project.
The Committer-to-PMC ratio is roughly 1:1.

Community changes, past quarter:
- No new PMC members. Last addition was Georg Kallidis on 2020-08-26.
- No new committers. Last addition was Tobias Bouschen on 2021-01-19.

## Project Activity:
- Torque 5.0 was released on 2020-09-22.
- Derby-10.15.2.0 was released on 2020-02-18.
- JDO 3.1 was released on 2015-03-19

The Torque community are preparing their 5.1 release, which contains multiple
new features as well as security fixes. An initial release candidate was voted
on, then withdrawn, due to ongoing work to address the Log4J security fixes. A
subsequent release candidate has been prepared and will be voted upon by the
community.

JDO has prepared release 3.2 and the DB PMC has voted to approve it. The vote
was prior to the log4j2 disclosure and jdo had a dependency on an affected
release of log4j2. This dependency was only for running the TCK so it is not a
critical issue. However, the dependency has been updated for the official
release.

The JCP has completed the Maintenance Draft Review 5 and has scheduled the
Maintenance Review Ballot for January 11 through January 17. We are expecting
a positive result. Once the Ballot is approved we will do a final update of
JDO 3.2 and have a final vote by the DB PMC.

The Derby community have had some discussions as to whether a new
major release of Derby will be needed to support JDK 18. Certain
Derby features may be removed due to underlying changes in the JDK and
the Derby community will need to communicate this to the users of the software.

The DB project has discussed the upcoming shutdown of the CMS and the move
of the ci.apache.org support to the new ci2.apache.org that will occur at
the end of January, and the sub projects will make the necessary changes.

## Community Health:
DB mailing lists show typical levels of activity and appear healthy.
Project release activities and release votes are proceeding normally.

Re: Items for our January report to the board, please?

[Rick Hillegas]

On 1/5/22 5:48 AM, Bryan Pendleton wrote:

Hi all,

Our January report to the Apache Board is due, please let me know what
items you think we should include.

thanks,

bryan


Nothing from me. Thanks, Bryan.

Re: JDK 18: Rampdown Phase 1 & Early-Access builds 27

[Rick Hillegas]

Thanks, David. I looked at the lists of changes for builds 26 and 27 but 
couldn't figure out which ones addressed our concerns. Could you provide 
more detail?


Thanks,
-Rick

On 12/9/21 11:40 PM, David Delabassee wrote:

Rick,

Thank you for being part of the OpenJDK Quality Outreach Program. As 
year-end 2021 approaches, I'd like to share some updates on JDK 18, 
which is scheduled for General Availability on March 22, 2022.


JDK 18 has now entered Rampdown Phase One (RDP1) [1], which means that 
the main-line has been forked into a dedicated JDK 18 stabilization 
repository. At this point, the overall JDK 18 feature set is now 
frozen and no additional JEPs will be targeted to JDK 18. Only 
low-risk enhancements that add small bits of missing functionality or 
improve usability might still be considered. The next few weeks should 
be leveraged to try to identify and resolve as many issues as possible 
(i.e. before JDK 18 enters the Release Candidates phase).


And as you can see below, JDK 18 EA Builds 26 & 27 include fixes for 
issues that were reported by you! So thank you for your help 
contributing to the overall quality of OpenJDK!


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



## JEP 400 - UTF-8 by Default

All JEPs are now integrated, but we would like to draw your attention 
to JEP 400 especially if you are deploying on Windows as it might 
induce some incompatible behavior on that platform.


JEP 400 [2] is changing the default charset to UTF-8. This aligns with 
the existing `newBufferedReader`/`Writer` methods of the 
`java.nio.file.Files` class where UTF-8 is the default when no 
explicit charset is set. By making UTF-8 the default charset, the JDK 
I/O APIs will now always work in the same, predictable manner, with no 
need to pay attention to the host and or user’s environment!


Further, we encourage you to test your project(s) with the latest JDK 
18 Early Access builds. We don't expect issues on macOS and Linux as 
their default encoding is already UTF-8. On Windows, especially for 
East Asian locales such as Chinese/Japanese/Korean, some incompatible 
behavior could be anticipated. If that’s the case, please consider a 
mitigation strategy [3].


[2] https://openjdk.java.net/jeps/400
[3] https://inside.java/2021/10/04/the-default-charset-jep400/


## JDK 18

JDK 18 Early-Access builds 27 are now available [4], and are provided 
under the GNU General Public License v2, with the Classpath Exception. 
Make sure to check the Release Notes [5]. As usual, we encourage you 
to test your project(s) using those EA builds and provide us feedback.


[4] https://jdk.java.net/18/
[5] https://jdk.java.net/18/release-notes

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

### Changes in recent builds that maybe of interest:

 Build 27:

- JDK-8266435: WBMPImageReader.read() should not truncate the input 
stream [Reported by PDFBox]
- JDK-8278078: Cannot reference super before supertype constructor has 
been called

- JDK-8177819: DateTimeFormatterBuilder zone parsing should recognise DST
- JDK-8277965: Enclosing instance optimization affects serialization
- JDK-8275821: Optimize random number generators developed in 
JDK-8248862 using Math.unsignedMultiplyHigh()

- JDK-8225181: KeyStore should have a getAttributes method
- JDK-8275082: Update XML Security for Java to 2.3.0
- JDK-8278270: ServerSocket is not thread safe
- JDK-8277863: Deprecate sun.misc.Unsafe methods that return offsets

 Build 26:

- JDK-8277451: j.l.r.Field::set on static field with invalid argument 
type should throw IAE [Reported by Hibernate & ByteBuddy]
- JDK-8258117: jar tool sets the time stamp of module-info.class 
entries to the current time [Reported by Apache Maven]
- JDK-8268743: Require a better way for copying data between 
MemorySegments and on-heap arrays [Reported by Apache Lucene]
- JDK-8277986: Typo in javadoc of java.util.zip.ZipEntry#setTime 
[Reported by Apache Ant]

- JDK-8277861: Terminally deprecate Thread.stop
- JDK-8276665: ObjectInputStream.GetField.get(name, object) should 
throw ClassNotFoundException
- JDK-8271623: Omit enclosing instance fields from inner classes that 
don't use it
- JDK-8231107: Allow store password to be null when saving a PKCS12 
KeyStore

- JDK-8193682: Infinite loop in ZipOutputStream.close()
- JDK-8277459: Add `jwebserver` tool [see Topics of Interest]

 Build 25:

- JDK-8259643: ZGC can return metaspace OOM prematurely
- JDK-8277212: GC accidentally cleans valid megamorphic vtable inline 
caches

- JDK-8276970: Default charset for 

Re: [External] : Re: JDK 18 Early-Access builds 23 are available

[Rick Hillegas]

Hi David and Deepak,

I have finished my testing of build 18-ea+23-1525. I did not discover 
any further problems beyond the security regression I mentioned before. 
My results are described by 
https://issues.apache.org/jira/browse/DERBY-7126.


Regards,
-Rick

On 11/16/21 8:48 PM, Deepak Damodaran wrote:

Hi Rick,

Link to the latest builds was specified in the email as [5].
This is the link - https://jdk.java.net/18/

Thanks,
Deepak


On 17/11/21, 2:30 AM, "Rick Hillegas"  wrote:

 Thanks for the heads-up, David. The JEP 411 work will almost certainly
 be a disruption for Derby. Is there a particular build which you want us
 to test? I didn't see a link to the latest builds in your email. Rory
 used to include those links.

 Thanks,
 -Rick

 On 11/16/21 3:01 AM, david.delabas...@oracle.com wrote:
 > Hi Rick,
 >
 > 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://urldefense.com/v3/__https://jdk.java.net/18/__;!!ACWV5N9M2RV99hQ!Y2uUgfv_-S-aylTlnPXfoUTvzE0apOEYF1ZhBZM83KKhauMdDa-nqOxJ21WtGrOivCiqLQ$
 > [6] 
https://urldefense.com/v3/__https://jdk.java.net/18/release-notes__;!!ACWV5N9M2RV99hQ!Y2uUgfv_-S-aylTlnPXfoUTvzE0apOEYF1ZhBZM83KKhauMdDa-nqOxJ21WtGrN-iaadaQ$
 >
 >
 > # 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)
 > http

Re: [External] : Re: JDK 18 Early-Access builds 23 are available

[Rick Hillegas]

Hi David and Deepak,

The Derby community has not figured out how we are going to handle this 
latest release of the Open JDK. Please see the discussion on 
https://issues.apache.org/jira/browse/DERBY-7126 for more details.


At this time, we cannot recommend that Derby-powered applications use 
any version of the JDK from JDK 18 onward. This is true for all versions 
of Derby going back 15 years. This is due to recent security regressions 
introduced into the JDK. The latest regression, introduced into build 
18-ea+23-1525, is discussed in a security-dev email thread titled "new 
hurdle for applications which programatically install a 
SecurityManager". It is possible that these regressions will be 
backported to previous JDK release families. In that case, we will not 
be able to recommend that Derby-powered applications use those JDKs 
either. We can only hope that these regressions are not backported to 
JDK 8 and JDK 11.


I am afraid that we cannot provide you any more feedback until we sort 
this out.


Regards,
-Rick


On 11/16/21 8:48 PM, Deepak Damodaran wrote:

Hi Rick,

Link to the latest builds was specified in the email as [5].
This is the link - https://jdk.java.net/18/

Thanks,
Deepak


On 17/11/21, 2:30 AM, "Rick Hillegas"  wrote:

 Thanks for the heads-up, David. The JEP 411 work will almost certainly
 be a disruption for Derby. Is there a particular build which you want us
 to test? I didn't see a link to the latest builds in your email. Rory
 used to include those links.

 Thanks,
 -Rick

 On 11/16/21 3:01 AM, david.delabas...@oracle.com wrote:
 > Hi Rick,
 >
 > 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://urldefense.com/v3/__https://jdk.java.net/18/__;!!ACWV5N9M2RV99hQ!Y2uUgfv_-S-aylTlnPXfoUTvzE0apOEYF1ZhBZM83KKhauMdDa-nqOxJ21WtGrOivCiqLQ$
 > [6] 
https://urldefense.com/v3/__https://jdk.java.net/18/release-notes__;!!ACWV5N9M2RV99hQ!Y2uUgfv_-S-aylTlnPXfoUTvzE0apOEYF1ZhBZM83KKhauMdDa-nqOxJ21WtGrN-iaadaQ$
 >
 >
 > # JEPs integrated to JDK 18, so far:
 >
 > - JEP 400: UTF-8 by Default https://openjdk.java.net/jeps/400
 > - JEP 408: Simple Web Se

Re: [External] : Re: JDK 18 Early-Access builds 23 are available

[Rick Hillegas]

Thanks, Deepak.

On 11/16/21 8:48 PM, Deepak Damodaran wrote:

Hi Rick,

Link to the latest builds was specified in the email as [5].
This is the link - https://jdk.java.net/18/

Thanks,
Deepak


On 17/11/21, 2:30 AM, "Rick Hillegas"  wrote:

 Thanks for the heads-up, David. The JEP 411 work will almost certainly
 be a disruption for Derby. Is there a particular build which you want us
 to test? I didn't see a link to the latest builds in your email. Rory
 used to include those links.

 Thanks,
 -Rick

 On 11/16/21 3:01 AM, david.delabas...@oracle.com wrote:
 > Hi Rick,
 >
 > 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://urldefense.com/v3/__https://jdk.java.net/18/__;!!ACWV5N9M2RV99hQ!Y2uUgfv_-S-aylTlnPXfoUTvzE0apOEYF1ZhBZM83KKhauMdDa-nqOxJ21WtGrOivCiqLQ$
 > [6] 
https://urldefense.com/v3/__https://jdk.java.net/18/release-notes__;!!ACWV5N9M2RV99hQ!Y2uUgfv_-S-aylTlnPXfoUTvzE0apOEYF1ZhBZM83KKhauMdDa-nqOxJ21WtGrN-iaadaQ$
 >
 >
 > # 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

Re: JDK 18 Early-Access builds 23 are available

[Rick Hillegas]

Thanks for the heads-up, David. The JEP 411 work will almost certainly 
be a disruption for Derby. Is there a particular build which you want us 
to test? I didn't see a link to the latest builds in your email. Rory 
used to include those links.


Thanks,
-Rick

On 11/16/21 3:01 AM, david.delabas...@oracle.com wrote:

Hi Rick,

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 General Public License, 
version 2, with the Classpath Exception and are produced for the 
purpose of gathering feedback. Use for any other purpose is at your 
own 

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

[Rick Hillegas]

Will do. Cheers.

On 10/31/21 11:55 AM, Rory O'Donnell wrote:

Thanks Rick, let us know if a Bug gets logged ?

Rgds,Rory

On 31/10/2021 16:45, Rick Hillegas wrote:

Hi Rory and David,

The Derby regressions tests discovered a security regression 
introduced by this build of JDK 18. I have started a discussion on 
security-dev titled "previously prevented exploit now possible with 
JDK 18". More information can be found at 
https://urldefense.com/v3/__https://issues.apache.org/jira/browse/DERBY-7126__;!!ACWV5N9M2RV99hQ!cUAIPe7rr2vLE308fr__XymD5Dy0oigJTz9MAcTJd-_rMeYCB2urEJYin2lqwpD-5Zc$ 
.


That is the only problem which I ran across when I used this distro 
to build and test Derby.


Regards,
-Rick

On 10/26/21 5:16 AM, Rory O'Donnell wrote:

Hi Rick,
*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://urldefense.com/v3/__https://jdk.java.net/18/__;!!ACWV5N9M2RV99hQ!cUAIPe7rr2vLE308fr__XymD5Dy0oigJTz9MAcTJd-_rMeYCB2urEJYin2lq1St-nIc$ 
<https://urldefense.com/v3/__https://jdk.java.net/18/__;!!ACWV5N9M2RV99hQ!cUAIPe7rr2vLE308fr__XymD5Dy0oigJTz9MAcTJd-_rMeYCB2urEJYin2lq1St-nIc$ 
>**

*

 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception <https://openjdk.java.net/legal/gplv2+ce.html>.
 * Release Notes are available athttps://jdk.java.net/18/release-notes
<https://urldefense.com/v3/__https://jdk.java.net/18/release-notes__;!!ACWV5N9M2RV99hQ!cUAIPe7rr2vLE308fr__XymD5Dy0oigJTz9MAcTJd-_rMeYCB2urEJYin2lqJBOY1AQ$ 
>

 * Features:
 o JEPs integrated to JDK 18, so far:
 + JEP 400: UTF-8 by Default 
<https://openjdk.java.net/jeps/400>
 + JEP 408: Simple Web Server 
<https://openjdk.java.net/jeps/408>

 + JEP 413: Code Snippets in Java API Documentation
   <https://openjdk.java.net/jeps/413>
 o JEPs targeted to JDK 18, so far
 + JEP 417: Vector API (Third Incubator)
   <https://openjdk.java.net/jeps/417>
 o JEPs proposed to target JDK 18:
 + JEP 416: Reimplement Core Reflection with Method Handles
   <https://openjdk.java.net/jeps/416>

 * Significant changes since the last availability email:
 o Build 20:
 + JDK-8275252: Migrate cacerts from JKS to password-less 
PKCS12

 + JDK-8275149: (ch) ReadableByteChannel returned by
   Channels.newChannel(InputStream) throws 
ReadOnlyBufferException

 + JDK-8266936: Add a finalization JFR event
 + JDK-8264849: Add KW and KWP support to PKCS11 provider
 o Build 19:
 + JDK-8274840: Update OS detection code to recognize 
Windows 11

 + JDK-8274407: (tz) Update Timezone Data to 2021c
 + JDK-8273102: Delete deprecated for removal the empty
   finalize() in java.desktop module
 o Build 18:
 + JDK-8274656: Remove default_checksum and safe_checksum_type
   from krb5.conf
 + JDK-8274471: Add support for RSASSA-PSS in OCSP Response
 + JDK-8274227: Remove "impl.prefix" jdk system property usage
   from InetAddress
 + JDK-8274002: [win11 and winserver2022] JDK executable
   installer from network drive starts with huge delay
 + JDK-8273670: Remove weak etypes from default krb5 etype list
 o Build 17:
 + JDK-8273401: Disable JarIndex Support In URLClassPath
 + JDK-8231640: (prop) Canonical property storage
 + Build 16:
 + JDK-8269039: Disable SHA-1 Signed JARs

*Topics of Interest:*_
_

_JDK 17:_**
**

 * *Inside Java Podcast “Java 17 is Here!”*
 o *Part 1: 
https://urldefense.com/v3/__https://inside.java/2021/09/14/podcast-019/__;!!ACWV5N9M2RV99hQ!cUAIPe7rr2vLE308fr__XymD5Dy0oigJTz9MAcTJd-_rMeYCB2urEJYin2lqAFhJDcQ$ 
<https://urldefense.com/v3/__https://inside.java/2021/09/14/podcast-019/__;!!ACWV5N9M2RV99hQ!cUAIPe7rr2vLE308fr__XymD5Dy0oigJTz9MAcTJd-_rMeYCB2urEJYin2lqAFhJDcQ$ 
>*
 o *Part 2: 
https://urldefense.com/v3/__https://inside.java/2021/09/27/podcast-020/__;!!ACWV5N9M2RV99hQ!cUAIPe7rr2vLE308fr__XymD5Dy0oigJTz9MAcTJd-_rMeYCB2urEJYin2lq671ZctI$ 
<https://urldefense.com/v3/__https://inside.java/2021/09/27/podcast-020/__;!!ACWV5N9M2RV99hQ!cUAIPe7rr2vLE308fr__XymD5Dy0oigJTz9MAcTJd-_rMeYCB2urEJYin2lq671ZctI$ 
>*

 * *G1 GC & Parallel GC I

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

[Rick Hillegas]

Hi Rory and David,

The Derby regressions tests discovered a security regression introduced 
by this build of JDK 18. I have started a discussion on security-dev 
titled "previously prevented exploit now possible with JDK 18". More 
information can be found at 
https://issues.apache.org/jira/browse/DERBY-7126.


That is the only problem which I ran across when I used this distro to 
build and test Derby.


Regards,
-Rick

On 10/26/21 5:16 AM, Rory O'Donnell wrote:

Hi Rick,
*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 

Re: Items for our quarterly update to the Board?

[Rick Hillegas]

Thanks for that explanation, Bryan. No, I don't see anything improper. I 
just wanted to make sure that feedback from the other projects was being 
collected. Thanks.


On 10/2/21 7:17 AM, Bryan Pendleton wrote:

Thanks Rick. Recently, following a suggestion by Craig R, I've been
using the project dev lists (derby-dev, jdo-dev, torque-dev) instead,
for two reasons: firstly, there's generally nothing sensitive in our
reports to the board, so it's nice to use the broader and more
inclusive development lists to incorporate feedback from the entire
community; second, each development team has their own
project-specific activities which is nice to capture on the
development lists.

Do you think this is an improper approach?

bryan

On Fri, Oct 1, 2021 at 7:30 AM Rick Hillegas  wrote:

I have nothing to add. Did you want to send this message to the DB pmc
mailing list also? I didn't receive a copy addressed to that list.

Thanks,
-Rick

On 9/30/21 11:46 AM, Bryan Pendleton wrote:

Hi all, I am preparing the October report for the Board.

Can you please send me any updates that I should include?

Here is what I currently have.

The DB project received a report of a CWE-502 vulnerability in the
retired DdlUtils source code. Although the DdlUtils subproject is
retired and no longer actively developed, the DB project decided
to address the vulnerability, which is now tracked as CVE-2021-41616,
and removed the insecure source code from the source repository.
The DB project also removed the DdlUtils-1.0 release from
distribution via the Apache mirrors, and updated the DdlUtils web
site to make it more clear that DdlUtils is retired and no longer
actively developed.

The JDO team have published the JDO 3.2 spec (or is it still in review?)

The JDO team have been making changes suggested by the Apache
Diversity Conscious Language Checker, including changing the
name of the git branch from master to main, and investigating
language changes in the source code and specification.

The Derby team have validated Derby behavior with Java 17. This
involved significant work to address changes due to JEP411.

Re: Items for our quarterly update to the Board?

[Rick Hillegas]

I have nothing to add. Did you want to send this message to the DB pmc 
mailing list also? I didn't receive a copy addressed to that list.


Thanks,
-Rick

On 9/30/21 11:46 AM, Bryan Pendleton wrote:

Hi all, I am preparing the October report for the Board.

Can you please send me any updates that I should include?

Here is what I currently have.

The DB project received a report of a CWE-502 vulnerability in the
retired DdlUtils source code. Although the DdlUtils subproject is
retired and no longer actively developed, the DB project decided
to address the vulnerability, which is now tracked as CVE-2021-41616,
and removed the insecure source code from the source repository.
The DB project also removed the DdlUtils-1.0 release from
distribution via the Apache mirrors, and updated the DdlUtils web
site to make it more clear that DdlUtils is retired and no longer
actively developed.

The JDO team have published the JDO 3.2 spec (or is it still in review?)

The JDO team have been making changes suggested by the Apache
Diversity Conscious Language Checker, including changing the
name of the git branch from master to main, and investigating
language changes in the source code and specification.

The Derby team have validated Derby behavior with Java 17. This
involved significant work to address changes due to JEP411.

Re: Question about setting up Derby development in Intellij

[Rick Hillegas]

Welcome to the developers' list. Some responses inline...

On 8/19/21 3:09 AM, Zeyuan Hu wrote:

Hello,

I'm trying to set up Derby development environment in Intellij and run
NetworkServerControl main and I got the following error message after I hit
run

---
Error occurred during initialization of boot layer
java.lang.module.FindException: Error reading module:
/Users/zyh/projects/10.15/out/production/org.apache.derby.tools
Caused by: java.lang.module.InvalidModuleDescriptorException: Package
org.apache.derby.loc.tools not found in module

Process finished with exit code 1
---

1. I couldn't find "org.apache.derby.loc.tools" package, which I hope I can
add the package as a module dependency to org.apache.derby.tools. Can you
please where ""org.apache.derby.loc.tools" is defined. The error is coming
from "opens org.apache.derby.loc.tools" inside module-info.java of
org.apache.derby.tools.
That is a package in derbytools.jar. It holds English localizations for 
error and diagnostic messages raised by Derby tools. The package does 
not exist in the source tree. It is created by the compilation and jar 
file targets.

2. Is there any guide on how to set up Derby in Intellij?

I don't use that IDE. Hopefully, an Intellij expert can advise you.


Thanks!

best
regards,


Zeyuan

Re: JDK 17 is now in the Release Candidate Phase

[Rick Hillegas]

Hi Rory,

No new issues were found with the first release candidate. See 
https://issues.apache.org/jira/browse/DERBY-7110?focusedCommentId=17398033=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17398033 
for more information.


-Rick


On 8/7/21 8:02 AM, Rory O'Donnell wrote:

Hi Rick,

*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

Re: JDK 17 is now in Rampdown Phase Two

[Rick Hillegas]

Hi Rory,

Derby builds and tests cleanly with the rampdown phase 2 jdk. For more 
detail, see 
https://issues.apache.org/jira/browse/DERBY-7110?focusedCommentId=17382573=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17382573


Thanks,
-Rick

On 7/15/21 12:31 PM, Rory O'Donnell wrote:


*Hi Rick, *

*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 

Re: Updates to include in our July report to the board?

[Rick Hillegas]

On 7/5/21 9:43 AM, Bryan Pendleton wrote:

Hi all, our quarterly report to the Board needs to be prepared this week.

Please let me know the major topics we want to include, thanks!

bryan


I have nothing to add. Thanks, Bryan.

Re: JDK 17 Early Access build 28 & JDK 18 build 3 are available

[Rick Hillegas]

Hi Rory,

Derby builds and tests cleanly against Open JDK 17-ea+28-2534--after 
making changes to compensate for recent Open JDK changes made to support 
JEP 411. This included changes made to compensate for the affect of JEP 
411 on the Apache ant build tool, which Derby uses. Our experience is 
recorded here:


o An email thread on the Apache ant developers' list, titled "new 
warnings produced by  task under Open JDK 17-ea+28-2534"


o An email thread on the Open JDK security developers' list: 
https://mail.openjdk.java.net/pipermail/security-dev/2021-June/026660.html


o Comments on https://issues.apache.org/jira/browse/DERBY-7110 from 
2021-06-27 through 2021-06-29.



On 6/25/21 12:49 AM, Rory O'Donnell wrote:


*Hi Rick, *

*
*

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

*

Re: [External] : Re: JDK 17 is now in Rampdown Phase One

[Rick Hillegas]

Hi Rory,

Derby builds and tests cleanly against Open JDK 17-ea+26-2439 after 
suppressing the deprecation warnings introduced by JEP 411. Our 
experience is documented in a security-...@openjdk.java.net email thread 
titled "blizzard of deprecation warnings related to JEP 411" and in 
comments dated between 2021-06-15 and 2021-06-18 on 
https://issues.apache.org/jira/browse/DERBY-7110.


On 6/14/21 11:20 AM, Rory O'Donnell wrote:

Hi Rick,

Excellent feedback , I suggest you send this information to the 
security-dev [1] mailing list to demonstrate the impact

it is having on you and others. Make sure to subscribe first.

Rgds,Rory

[1] security-...@openjdk.java.net <mailto:security-...@openjdk.java.net>

On 14/06/2021 16:43, Rick Hillegas wrote:

Hi Rory,

Copying the Tomcat developer community since this issue probably 
affects them as well.


When I tried to build Derby with the Rampdown Phase One build of open 
JDK 17 (17-ea+26-2439), I saw many warnings related to the 
deprecation of Security Manager classes and methods, undoubtedly the 
consequence of JEP 411 (https://openjdk.java.net/jeps/411). Derby, 
like Tomcat, embraced the Security Manager early on. Permissions 
checks were rototilled across the whole code base. Our distributions 
ship with several template policy files, which we encourage users to 
customize for their environments. The "Configuring Java Security" 
section of our Security Guide explains how to do this 
(https://urldefense.com/v3/__https://db.apache.org/derby/docs/10.15/security/index.html__;!!GqivPVa7Brio!Ir7H5RCIuIIcRhganretmYcvHoP432X-jV4dVUNlqO1EmvYkTvkdZvEBdtBh9kcdocM$ 
).


My build only reported the first 100 warnings. It is likely that 
there are many more.


Having read the summary of JEP 411, I understand the motivation for 
this change. However, I don't understand how applications like Tomcat 
and Derby are supposed to respond to the new blizzard of deprecation 
warnings. For instance, is there a replacement for the deprecated 
AccessController.doPrivileged() method? Or are we supposed to simply 
disable this deprecation check? Is there some security expert whom we 
should contact about this change and how to mitigate its effects?


Thanks,
-Rick


On 6/14/21 2:18 AM, Rory O'Donnell wrote:


Hi Rick,
*
Per the JDK 17 schedule , we are in Rampdown Phase One [1].*

**Please advise if you find any issues while testing the latest 
Early Access builds**.**


 * Schedule:
 o *2021/06/10   Rampdown Phase One*
 o 2021/07/15    Rampdown Phase Two
 o 2021/08/05    Initial Release Candidate
 o 2021/08/19    Final Release Candidate
 o 2021/09/14    General Availability

The overall feature set is frozen. No further JEPs will be targeted 
to this release.


**

 * Important JEPs have been integrated – Attention Required!
 * *JEP 411: **Deprecate the Security Manager for
   Removal*<https://openjdk.java.net/jeps/411>
 o Deprecate, for removal, most Security Manager related classes
   and methods.
 o Warning message at startup if the Security Manager is enabled on
   the command line.
 o Warning message at run time if a Java application or library
   installs a Security Manager dynamically.
 o Deprecation is in concert with the legacy Applet API (JEP 398).
 * *JEP 407: **Remove RMI 
Activation*<https://openjdk.java.net/jeps/407>

 o Removal the Remote Method Invocation (RMI) Activation mechanism,
   while preserving the rest of RMI.
 o It was deprecated for removal by JEP
   385<https://openjdk.java.net/jeps/385>in Java SE 15.
 * *JEP 403: **Strongly Encapsulate JDK
   Internals*<https://openjdk.java.net/jeps/403>
 o Strongly encapsulate all internal elements of the JDK, except
   for critical internal APIs such as /sun.misc.Unsafe/.
 o It will no longer be possible to relax the strong encapsulation
   of internal elements via a single command-line option.

 * Other features integrated in JDK 17:
 o *JEP 306: **Restore Always-Strict Floating-Point
   Semantics*<https://openjdk.java.net/jeps/306>
 o JEP 356: Enhanced Pseudo-Random Number
   Generators<https://openjdk.java.net/jeps/356>
 o JEP 382: New macOS Rendering
   Pipeline<https://openjdk.java.net/jeps/382>
 o JEP 391: macOS/AArch64 Port<https://openjdk.java.net/jeps/391>
 o JEP 398: Deprecate the Applet API for
   Removal<https://openjdk.java.net/jeps/398>
 o *JEP 406: **Pattern Matching for switch
   (Preview)*<https://openjdk.java.net/jeps/406>
 o JEP 409: Sealed Classes<https://openjdk.java.net/jeps/409>
 o JEP 410: Remove the Experimental AOT and JIT
   Compiler<https://openjdk.java.net/jeps/410>
 o JEP 412: Foreign Function & Memory API
   (Incubator)<https://openjdk.java.net/jeps/412>
 o *JEP 414: **Vector API (Second
   Incubator)*&

Re: JDK 17 is now in Rampdown Phase One

[Rick Hillegas]

Hi Rory,

Copying the Tomcat developer community since this issue probably affects 
them as well.


When I tried to build Derby with the Rampdown Phase One build of open 
JDK 17 (17-ea+26-2439), I saw many warnings related to the deprecation 
of Security Manager classes and methods, undoubtedly the consequence of 
JEP 411 (https://openjdk.java.net/jeps/411). Derby, like Tomcat, 
embraced the Security Manager early on. Permissions checks were 
rototilled across the whole code base. Our distributions ship with 
several template policy files, which we encourage users to customize for 
their environments. The "Configuring Java Security" section of our 
Security Guide explains how to do this 
(https://db.apache.org/derby/docs/10.15/security/index.html).


My build only reported the first 100 warnings. It is likely that there 
are many more.


Having read the summary of JEP 411, I understand the motivation for this 
change. However, I don't understand how applications like Tomcat and 
Derby are supposed to respond to the new blizzard of deprecation 
warnings. For instance, is there a replacement for the deprecated 
AccessController.doPrivileged() method? Or are we supposed to simply 
disable this deprecation check? Is there some security expert whom we 
should contact about this change and how to mitigate its effects?


Thanks,
-Rick


On 6/14/21 2:18 AM, Rory O'Donnell wrote:


Hi Rick,
*
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 

Re: JDK 17 Early Access build 23 is available

[Rick Hillegas]

Hi Rory,

Derby builds and tests fine against build 23 of Open JDK 17. See 
https://issues.apache.org/jira/browse/DERBY-7110?focusedCommentId=17350113=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17350113


Cheers,
-Rick

On 5/21/21 12:09 AM, Rory O'Donnell wrote:

Hi Rick, **

*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 412:_Foreign Function & Memory API (Incubator)
   _
 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_ 

Re: JDK 17 Early Access build 21 is available

[Rick Hillegas]

Hi Rory,

Derby built and tested cleanly with early access build 21, except for 
one probably transient or environmental problem. See 
https://issues.apache.org/jira/browse/DERBY-7110?focusedCommentId=17342832=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17342832


Cheers,
-Rick

On 5/10/21 1:29 AM, Rory O'Donnell wrote:


Hi Rick, *** *

*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

Re: JDK 17 Early Access build 18 is available

[Rick Hillegas]

Thanks, Rory. Derby builds and tests cleanly with this early access 
distro. See 
https://issues.apache.org/jira/browse/DERBY-7110?focusedCommentId=17326152=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17326152


Cheers,
-Rick

On 4/20/21 3:03 AM, Rory O'Donnell wrote:


*Hi Rick, *

*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

Re: OpenJDK 17 Early Access build 16 is now available

[Rick Hillegas]

Hi Rory,

Derby builds and the regression tests run cleanly with Open JDK 
17-ea+16-1315. I tweaked Derby's javadoc so that it builds cleanly with 
this JDK. See 
https://issues.apache.org/jira/browse/DERBY-7110?focusedCommentId=17314509=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17314509


By the way, many of the links in your message were http rather than 
https. Maybe you are grabbing them from some legacy source which hasn't 
been updated.


Thanks,
-Rick


On 4/2/21 12:32 AM, Rory O'Donnell wrote:


Hi Rick,

*OpenJDK 17 Early Access build 16 is now available at 
**http://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 (proposed)
 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

 * Features:*Heads-up on an important Candidate JEP
   *
 o *Candidate - JEP 403: **Strongly Encapsulate JDK Internals
   *
 o successor to JEP 396: Strongly Encapsulate JDK Internals by
   Default 
 o strongly encapsulate all internal elements of the JDK by default
 o exception for Critical Internal APIs such as /sun.misc.Unsafe/

 * 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
   

 * Release Notes are available at http://jdk.java.net/17/release-notes
   
 * Changes in recent builds that maybe of interest:
 o Build 16
 + JDK-8263898: (fs) Files.newOutputStream on the "NUL" special
   device throws FileSystemException: "nul: Incorrect function"
   (win)
 # Reported by Apache Ant
 o Build 15
 + JDK-8263575: Conflict between JDK rpms and OL8 Modularity
   prevents dnf install/updates
 o Build 14
 + JDK-8262277: URLClassLoader.getResource throws undocumented
   IllegalArgumentException
 + JDK-8262351: Extra '0' in java.util.Formatter for '%012a'
   conversion with a sign character

*Project Loom Early-Access Build: **Build 17-loom+5-191* 
*(2021/3/19)*


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

*Quality Report for March 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.

*Worth reading - **The Arrival of Java 16! 
*


 * JDK 16 Migration guide -
https://docs.oracle.com/en/java/javase/16/migrate/getting-started.html
 * #AllTestsGreenOnJDK16 - If your tests are green on JDK 16 please
   respond to this *tweet
*.
 * Oracle Developer Live event - Individual sessions:
    1. *Java 16: Consistency and Innovation* (Aurelio Garcia-Ribeyro):
   https://youtu.be/1acKCBbd6f4 
    2. *Java Language Futures: Spring 2021* (Gavin Bierman):
   https://youtu.be/K9SVV0XNIP8 
    3. *Ask the Java Architects* (Mark Reinhold, Brian Goetz, Mikael
   Vidstedt, Ron Pressler): https://youtu.be/CVE4bWvuD3o
   
    4. *Learn Java 16 with IntelliJ IDEA *(Trisha Gee[JetBrains])*:
   *https://youtu.be/1hyWJTjxeGM **
    5. *How Records Can Improve Serialization* (Julia Boes, Chris
   Hegarty): https://youtu.be/44D8M6ZxuLU
   
    6. *Vector API: SIMD Programming in Java* (Paul Sandoz, Sandhya
   Viswanathan[Intel]): https://youtu.be/VYo3p4R66N8
   
    7. *Your Guide to OpenJDK Development* (Jesper Wilhelmsson):
   https://youtu.be/bHcKTYy_Nec 
    8. *Project Skara: Migrating OpenJDK to 

Re: Release Announcement: General Availability of Java 16 / JDK 16

[Rick Hillegas]

Hi Rory,

For the record, the Derby build/test cycle found no problems with the GA 
JDK 16: 
https://issues.apache.org/jira/browse/DERBY-7088?focusedCommentId=17303571=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17303571


Thanks,
-Rick

On 3/16/21 7:54 AM, Rory O'Donnell wrote:


Hi Rick,

*Release Announcement: General Availability of Java 16 / JDK 16 *

**

 * JDK 16, the reference implementation of Java 16, is now Generally
   Available. [1]
 * GPL-licensed OpenJDK builds from Oracle are available here:
   http://jdk.java.net/16/ 
 * JDK 16 Release notes


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

 * JEP 338:Vector API (Incubator) 
 * JEP 347:Enable C++14 Language Features
   
 * JEP 357:Migrate from Mercurial to Git
   
 * JEP 369:Migrate to GitHub 
 * JEP 376:ZGC: Concurrent Thread-Stack Processing
   
 * JEP 380:Unix-Domain Socket Channels 


 * JEP 386:Alpine Linux Port 
 * JEP 387:Elastic Metaspace 
 * JEP 388:Windows/AArch64 Port 
 * JEP 389:Foreign Linker API (Incubator)
   
 * JEP 390:Warnings for Value-Based Classes
   
 * JEP 392:Packaging Tool 
 * JEP 393:Foreign-Memory Access API (Third Incubator)
   
 * JEP 394:Pattern Matching for instanceof
   
 * JEP 395:Records 
 * JEP 396:Strongly Encapsulate JDK Internals by Default
   
 * JEP 397:Sealed Classes (Second Preview)
   

Thanks to everyone who contributed to JDK 16, whether by creating 
features or enhancements, logging bugs, or


downloading and testing the early-access builds.

*OpenJDK 17 Early Access build 13 is now available at 
http://jdk.java.net/17 

*


**

 * These early access, open source builds are provided under the 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
   

 * Release Notes are available at http://jdk.java.net/17/release-notes
   

 * Significant changes since the last availability email:
 o JDK-8259709: Disable SHA-1 XML Signatures (b13)
 o JDK-6323374: (coll) Optimize Collections.unmodifiable* and
   synchronized*(b13)
 o JDK-8139348: Deprecate 3DES and RC4 in Kerberos (b12)
 o JDK-8259662: Don't wrap SocketExceptions into SSLExceptions in
   SSLSocketImpl (b11)
 o JDK-8235139: Deprecate the socket impl factory mechanism(b10)
 o JDK-8225081: Remove Telia Company CA certificate expiring in
   April 2021(b9)


*Project Lanai Early-Access Builds
*

 * EA 10 Build 17-lanai+3-133 (2021/3/2) is available -
   http://jdk.java.net/lanai/
 * These early access, open source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .


*Project Loom Early-Access Builds*

 * Build 17-loom+4-174 (2021/3/12) is available - 
http://jdk.java.net/loom/

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


*Project Panama Early-Access Builds
*

 * Build 17-panama+2-51 (2021/2/12) is available -
   http://jdk.java.net/panama/
 * These early access, open source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .


Rgds,Rory

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


[2] https://openjdk.java.net/projects/jdk/16/ 

Re: JDK 16 is now in the Release Candidate Phase

[Rick Hillegas]

Hi Rory,

No problems found with JDK 16 build 35. See 
https://issues.apache.org/jira/browse/DERBY-7088?focusedCommentId=17280292=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17280292


Cheers,
-Rick

On 2/5/21 2:39 AM, Rory O'Donnell wrote:


*Hi Rick, *

*Per the JDK 16 schedule , we are in the Release Candidate Phase**[1] .*

*Please advise if you find any issues while testing the latest Early 
Access builds.*


 * Schedule for JDK 16
 o *2021/02/04 Initial Release Candidate*
 o 2021/02/18 Final Release Candidate
 o 2021/03/16 General Availability
 * Release Notes [2]

OpenJDK 16 Early Access build 35**is now available at 
http://jdk.java.net/16 


 * These early-access, open-source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .
 * Features [3] - the overall feature set is frozen. No further JEPs
   will be targeted to this release.
 * Changes in recent builds that maybe of interest:
 o Build 34:
 + JDK-8259025: Record compact constructor using
   Objects.requireNonNull
 # Reported by JUnit5
 o Build 32:
 + JDK-8259014: Incomplete support for Unix domain sockets in
   Windows 2019 Server

 * JDK 16 - topics of interest:
 o Unix domain socket channels (JEP-380) overview:
https://inside.java/2021/02/03/jep380-unix-domain-sockets-channels/

 o Java Feature Spotlight: Pattern Matching
https://inside.java/2021/01/22/feature-spotlight-pattern-matching/

 o Foreign Memory Access - Pulling all the thread
https://inside.java/2021/01/25/memory-access-pulling-all-the-threads/

 * General – topic of interest:
 o Inside Java Episode 11 “How to contribute to OpenJDK” with
   Stuart Marks and Jesper Wilhelmsson
   https://inside.java/2021/01/29/podcast-011/
   


Project Lanai EA 9 Build 17-lanai+2-49 (2021/1/20) 
 is available now


 * These early-access builds are provided under the GNU General Public
   License, version 2, with the Classpath Exception
   
 * EA builds are intended for developers looking to test and provide
   feedback on using Project Lanai.
 * This is a macOS-specific project which implements a new Java 2D
   graphics rendering pipeline for macOS.
 * Project Lanai Wiki: https://wiki.openjdk.java.net/display/lanai/Main
   
 * Please send feedback via e-mail to lanai-...@openjdk.java.net
   . To send e-mail to this address
   you must first subscribe to the mailing list
.

Project Loom Build 17-loom+2-42 (2021/1/14) 
 based on JDK-17+5 
 is available now


 * These early-access builds are provided under the GNU General Public
   License, version 2, with the Classpath Exception
   
 * These builds are intended for developers looking to "kick the tyres"
   and provide feedback on using the API or by sending bug reports.
 * API Javadoc :
   https://download.java.net/java/early_access/loom/docs/api/

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

OpenJDK 17 Early Access build 8**is now available at 
http://jdk.java.net/17 


 * These early-access, open-source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .
 * Changes in recent builds that maybe of interest:
 o Build 8:
 + JDK-8222850: Misleading cascade compiler error in switch
   expression with undefined vars
 # Reported by jOOQ.
 + JDK-8217633: Configurable extensions with system properties
 + JDK-8249867: DOM LSSerializer control of newline after XML
   header
 + JDK-8256421: Added 2 HARICA Root CA Certificates
 + JDK-8259801: Enable XML Signature secure validation mode by
   default
 o Build 7:
 + JDK-8165276: Spec states to invoke the premain method in an
   agent class if it's public but implementation differs
 + JDK-8256895: Add support for RFC 8954: Online Certificate
   Status Protocol (OCSP) Nonce Extension
 o Build 

Re: DB web site migration from CMS

[Rick Hillegas]

Thanks, Craig. I have logged 
https://issues.apache.org/jira/browse/INFRA-21381 to request more 
information.


On 2/4/21 10:52 AM, Craig Russell wrote:

What the JDO team did was to open an INFRA JIRA asking for help in migration.

That worked well. There are lots of choices for web sites that do not use CMS.

Infra can point you to the relevant pages on the wiki (I do not know them right 
offhand).

Regards,
Craig


On Feb 4, 2021, at 10:11 AM, Rick Hillegas  wrote:

Could someone please post pointers to the CMS migration effort so that I can 
educate myself about what it entails? Once I know more, I can start a Derby 
community discussion about what, if anything, can be done before this deadline.

Thanks,
-Rick

On 2/2/21 11:26 AM, Craig Russell wrote:

Hi,

priv...@db.apache.org in bcc...

The JDO project is almost complete migrating the db.apache.org/jdo site from 
the soon-to-be-retired CMS system to a new github site repo using GitHub 
Actions and .asf.yaml to publish the site.

Infra wants to know what the plans are for the main site, Derby, and Torque to 
migrate.

Craig

Craig L Russell
c...@apache.org


Craig L Russell
c...@apache.org

Re: DB web site migration from CMS

[Rick Hillegas]

Could someone please post pointers to the CMS migration effort so that I 
can educate myself about what it entails? Once I know more, I can start 
a Derby community discussion about what, if anything, can be done before 
this deadline.


Thanks,
-Rick

On 2/2/21 11:26 AM, Craig Russell wrote:

Hi,

priv...@db.apache.org in bcc...

The JDO project is almost complete migrating the db.apache.org/jdo site from 
the soon-to-be-retired CMS system to a new github site repo using GitHub 
Actions and .asf.yaml to publish the site.

Infra wants to know what the plans are for the main site, Derby, and Torque to 
migrate.

Craig

Craig L Russell
c...@apache.org

Re: DB web site migration from CMS

[Rick Hillegas]

I have not been following this issue. I believe that Bryan put some 
effort into converting the Derby website, but I don't know where that 
stands. A couple questions:


1) How much effort was required to migrate JDO?

2) Can we still manage our code repo with subversion?

Thanks,
-Rick

On 2/2/21 11:26 AM, Craig Russell wrote:

Hi,

priv...@db.apache.org in bcc...

The JDO project is almost complete migrating the db.apache.org/jdo site from 
the soon-to-be-retired CMS system to a new github site repo using GitHub 
Actions and .asf.yaml to publish the site.

Infra wants to know what the plans are for the main site, Derby, and Torque to 
migrate.

Craig

Craig L Russell
c...@apache.org

Re: Items for the (delayed) quarterly report to the board?

[Rick Hillegas]

On 1/27/21 7:28 AM, Bryan Pendleton wrote:

Hi all, I'm preparing our quarterly report to the Apache board.

I missed our regular January report due to a personal problem (better now).

Please let me know of any Derby-related items that we should include
in this quarter's report!

thanks,

bryan


No items from me. I hope that you and your family are well now.

Re: JDK 16 is now in Rampdown Phase Two

[Rick Hillegas]

Hi Rory,

No problems found with early access build 32. For more detail, see 
https://issues.apache.org/jira/browse/DERBY-7088?focusedCommentId=1724=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1724


Thanks,
-Rick

On 1/15/21 1:09 AM, Rory O'Donnell wrote:

Hi Rick,

*Per the JDK 16 schedule , we are in Rampdown Phase Two* *[1] .
*

*Please advise if you find any issues while testing the latest Early 
Access builds.*


 * Schedule for JDK 16
 o *2021/01/14  Rampdown Phase Two*
 o 2021/02/04  Initial Release Candidate
 o 2021/02/18  Final Release Candidate
 o 2021/03/16  General Availability
 * Release Notes [2]

OpenJDK 16 Early Access build 32**is now available at 
http://jdk.java.net/16


 * These early-access, open-source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .
 * Features [3] - the overall feature set is frozen. No further JEPs
   will be targeted to this release.
 * Changes in recent builds that maybe of interest:
 o Build 32:
 + JDK-8259028 - ClassCastException when using custom
   filesystem with wrapper FileChannel impl
 # Apache Lucene found.
 + JDK-8253996 - Javac error on jdk16 build 18: invalid flag:
   -Xdoclint:-missing
 # Apache Zookeeper found.
 o Build 31:
 + JDK-8259027: NullPointerException in makeMappedSegment due
   to NULL Unmapper when length of segment is 0
 # Reported by Apache Lucene
 o Build 30:
 + JDK-8254023: A module declaration is not allowed to be a
   target of an annotation that lacks an @Target meta-annotation
 # Reported by JUnit5
 + JDK-8256693: getAnnotatedReceiverType parameterizes types
   too eagerly

 * JDK 16 - topics of interest
 o Investigating MD5 overheads:
https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html
 o Towards OpenJDK 17 - a quick update on startup performance
   https://cl4es.github.io/2020/12/06/Towards-OpenJDK-17.html
 o Migrating OpenJDK to Git & GitHub - GitHub Universe 2020 session
   replay
   https://inside.java/2020/12/11/skara-github-universe/

Project Panama/foreign EA Build 16-panama+3-385 (2020/12/10) 
 is available now [4]


 * What's new
 o jextract is now fully compatible with Java 16
 o New architecture based on Foreign-Memory Access API (JEP 370
   , JEP 383
   , JEP 393
   ) and Foreign Linker API (JEP
   389 )

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

 * Project Panama - topics of interest
 o “The Vector API” with John Rose and Paul Sandoz
   https://inside.java/2020/11/17/podcast-007/
 o “The Foreign Memory Access API” with Maurizio Cimadamore and
   Jorn Vernee
   https://inside.java/2020/12/11/podcast-009/
 o “The Foreign Linker API” with Maurizio Cimadamore and Jorn Vernee
   https://inside.java/2020/12/21/podcast-010/

OpenJDK 17 Early Access build 5**is now available at 
http://jdk.java.net/17


 * These early-access, open-source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .
 * Changes in recent builds that maybe of interest:
 o Build 4:
 + JDK-8258800: Deprecate -XX:+AlwaysLockClassLoader
 o Build 3:
 + JDK-8246005: KeyStoreSpi::engineStore(LoadStoreParameter)
   spec mismatch to its behavior
 + JDK-8258765: getAnnotatedReceiverType parameterizes types
   too eagerly
 * JDK 17 - topic of interest
 o Towards OpenJDK 17 - a quick update on startup performance:
 + https://cl4es.github.io/2020/12/06/Towards-OpenJDK-17.html

Java Cryptographic Roadmap [5] has been updated

 * Removing root certificates with 1024-bit keys in July 2021 CPU.
 * Disabling of SHA-1 JARS signed after 2019-01-01 has been postponed
   to July 2021 CPU.

Rgds, Rory

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

[2] https://jdk.java.net/16/release-notes
[3] http://openjdk.java.net/projects/jdk/16/ 

[4] 
https://mail.openjdk.java.net/pipermail/panama-dev/2020-December/011605.html 

Re: JDK 16 is in Rampdown Phase One

[Rick Hillegas]

Thanks, Rory. Derby builds and tests cleanly against JDK 16 build 28: 
https://issues.apache.org/jira/browse/DERBY-7088?focusedCommentId=17249888=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17249888


On 12/13/20 8:38 AM, Rory O'Donnell wrote:

Hi Rick,

*Per the JDK 16 schedule , we are in Rampdown Phase One* *[1] .
*

*Please advise if you find any issues while testing the latest Early 
Access builds.*


 * Schedule for JDK 16
 o *2020/12/10 Rampdown Phase One*
 o 2021/01/14  Rampdown Phase Two
 o 2021/02/04  Initial Release Candidate
 o 2021/02/18  Final Release Candidate
 o 2021/03/16  General Availability
 * Release Notes [2]

OpenJDK 16 Early Access build 28**is now available at 
http://jdk.java.net/16


 * Features - the overall feature set is frozen. No further JEPs will
   be targeted to this release.
 * Significant Integrations in b28:
 o *Integrated JEP 396: **Strongly Encapsulate JDK Internals by
   Default **
   *
 + Strongly encapsulate all internal elements of the JDK by
   default, except for critical internal APIs
    such as
   |sun.misc.Unsafe|.
 + Allow end users to choose the relaxed strong encapsulation
   that has been the default since JDK 9.
 o Integrated JEP 397: Sealed Classes (Second Preview)
    with this release.
 + Enhance the Java programming language with sealed classes
   and interfaces
.
 + Refines JEP 360  which
   was delivered in JDK 15 as a preview feature.

 * These early-access , open-source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .
 * Changes in recent builds that maybe of interest:
 o Build 28
 + JDK-8256299: JEP 396: Strongly Encapsulate JDK Internals by
   Default
 + JDK-8166596: TLS support for the EdDSA signature algorithm
 + JDK-8256718: Old tracing flags are now obsolete and must be
   replaced with unified logging
 o Build 27
 + JDK-8159746: (proxy) Support for default methods
 + JDK-8254631: Better support ALPN byte wire values in SunJSSE

Project Loom Early-Access: *Build 16-loom+9-316 
* (2020/11/30) - based on JDK-16+25 



 * These early-access builds are provided under the GNU General Public
   License, version 2, with the Classpath Exception
   
 * These builds are intended for developers looking to "kick the tyres"
   and provide feedback on using the API or by sending bug reports.
 * 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/2020-December/004991.html

[2] https://jdk.java.net/16/release-notes

Re: JDK 16 Early Access build 26 is now available

[Rick Hillegas]

Hi Rory,

Build 16-ea+26-1764 has deprecated two ThreadGroup methods which Derby 
uses: destroy() and isDestroyed(). The JDK 16 javadoc indicates that 
those two methods will be removed from the JDK sometime. Can you point 
me at someone who can answer the following questions:


1) What rev of the JDK will remove these methods?

2) What is the best practice for working around the removal of these 
methods?


Thanks,
-Rick

On 11/27/20 2:45 AM, Rory O'Donnell wrote:

Hi Rick,

OpenJDK 16 Early Access build 26**is now available at 
http://jdk.java.net/16


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

 * Schedule: *JDK 16 Rampdown Phase One Starts on 2020/12/10 [1] *

 * Features [1]: Most recent Integrations:
 o Integrated JEP 389: Foreign Linker API (Incubator)
    with this release.
 + JEP 389 introduces an API that offers statically-typed,
   pure-Java access to native code.
 + This API, together with the JEP 383
   , will considerably
   simplify the otherwise error-prone process of binding to a
   native library.

**

 * Release Notes [2]

 * Changes in recent builds that maybe of interest:
 o Build 26
 + JDK-8202343: *Disable TLS 1.0 and 1.1*
 + JDK-8251317:**Support for CLDR version 38**
 + JDK-8212879: Make JVMTI TagMap table concurrent
 + JDK-8236926: Concurrently uncommit memory in G1
 + JDK-8243559: Removed Root Certificates with 1024-bit Keys
 + JDK-8253459: Argument index of zero or unrepresentable by
   int throws IllegalFormatException
 + JDK-8256643: Terminally deprecate ThreadGroup stop, destroy,
   isDestroyed, setDaemon and isDaemon
 o Build 25
 + JDK-8247781: Day period support added to java.time formats
 + JDK-8202471: (ann) Cannot read type annotations on generic
   receiver type's type variables *[**Reported by ByteBuddy]*
 + JDK-8255947: [macos] Signed macOS jpackage app doesn't
   filter spurious '-psn' argument *[**Reported by JOSM]*
 + JDK-8256063: Module::getPackages returns the set of package
   names in this module

 * JDK 16 - topics of interest
 o Inside Java Episode 7 “The Vector API” with John Rose and Paul
   Sandoz
 + https://inside.java/2020/11/17/podcast-007/
   
 o Biased locking Obsoletion update
 + https://inside.java/2020/11/17/biased-locking-obsoletion/

 * Project Loom with Ron Pressler
 o https://inside.java/2020/11/24/podcast-008/
 * Update on 64-bit ARM Support for Oracle OpenJDK and Oracle JDK
 o https://inside.java/2020/11/12/arm-support-update/
   

Project Lanai Early-Access: EA 7 Build 16-lanai+3-278 
 (2020/11/17)


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

The Java Cryptographic Roadmap has been updated [3]:

 * Distrust TLS 1.0 and TLS 1.1 by default
 o TLS protocol versions 1.0 and 1.1 are no longer considered
   secure and have been superseded by more secure and modern
   versions (TLS 1.2 and 1.3). This change has been integrated with
   JDK 16 Early Access build 26.
 * Upgrade of default algorithms used to encrypt PKCS12 keystores
 o The new algorithms are based on AES-256 and SHA-256 and are
   stronger than the old algorithms which were based on RC2,
   DESede, and SHA-1.This change is already included in JDK 16
   Early Access build 23.

RgdsRory

[1] https://openjdk.java.net/projects/jdk/16/
[2] https://jdk.java.net/16/release-notes
[3] https://www.java.com/en/jre-jdk-cryptoroadmap.html

broken download pages for mirrored releases

[Rick Hillegas]

Download machinery is broken for the two mirrored releases (10.15.2.0 
and 10.14.2.0), that is, the ones with cgi scripts. Before asking INFRA 
for advice on what has changed, I thought that I would ask derby-dev 
first. Does anyone have a theory about what has changed and broken the 
download machinery for our flagship releases? See 
https://issues.apache.org/jira/browse/DERBY-7093


Thanks,

-Rick

Re: [jira] [Commented] (DERBY-7091) Times Inserted Incorrectly Around Daylight Savings Time Change in Spring

[Rick Hillegas]

On 11/16/20 10:41 PM, Anurag Shekhar wrote:
2017-03-12 02:48:00.000 


Thanks for pointing that out, Anurag!

Re: JDK 16 Early Access build 24 is now available

[Rick Hillegas]

Thanks, Rory. Derby builds and tests cleanly using JDK 16 build 24: 
https://issues.apache.org/jira/browse/DERBY-7088?focusedCommentId=17233021=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17233021


On 11/13/20 1:47 AM, Rory O'Donnell wrote:


Hi Rick,

OpenJDK 16 Early Access build 24**is now available at 
http://jdk.java.net/16


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

 * Schedule

            2020/12/10 Rampdown Phase One
            2021/01/14         Rampdown Phase Two
            2021/02/04         Initial Release Candidate
            2021/02/18         Final Release Candidate
            2021/03/16         General Availability

 * Features:
 o JEPs targeted to JDK 16, so far:
 + JEP 338: Vector API (Incubator)
   
 + JEP 347: Enable C++14 Language Features
   
 + JEP 357: Migrate from Mercurial to Git
   
 + JEP 369: Migrate to GitHub 
 + JEP 376: ZGC: Concurrent Thread-Stack Processing
   
 + JEP 380: Unix-Domain Socket Channels
   
 + JEP 386: Alpine Linux Port 
 + JEP 387: Elastic Metaspace 
 + JEP 388: Windows/AArch64 Port
   
 + JEP 392: Packaging Tool 
 + JEP 393: Foreign-Memory Access API (Third Incubator)
   
 + JEP 394: Pattern Matching for instanceof
   
 + JEP 395: Records 

**

 * Release Notes are available at http://jdk.java.net/16/release-notes
   

 * Changes in recent builds that maybe of interest:
 o Build 24
 + JDK-8231599: NPE when loading a preview classfile from a
   future Java version
 # *Reported by JUnit5*
 + JDK-8254661: arm32: additional cleanup after fixing SIGSEGV
 # *Reported by JaCoCo*
 + JDK-8255584: `HttpPrincipal::getName` returns incorrect name
 + JDK-8255226: (tz) Upgrade time-zone data to tzdata2020d
 o Build 23
 + JDK-8254876: (fs) NullPointerException not thrown when first
   argument to Path.of or Paths.get is null
 + JDK-8255576: (fs) Files.isHidden() throws
   ArrayIndexOutOfBoundsException (unix)
 # *Reported by JUnit5*
 + JDK-8255616: Removal of experimental features AOT and Graal 
JIT

 o Build 22
 + JDK-8243583: Change 'final' error checks to throw ICCE
 + JDK-8254982: (tz) Upgrade time-zone data to tzdata2020c

Project Loom Early-Access Build: Build 16-loom+7-285 
 (2020/11/4)


 * *Want to know more* - check out -
   https://inside.java/2020/11/11/project-loom-at-nyc-java-sig/
 * These early-access builds are provided under the GNU General Public
   License, version 2, with the Classpath Exception
   
 o These builds are based on jdk-16+20

 o These EA builds are produced for the purpose of gathering
   feedback. Use for any other purpose is at your own risk.
 o 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

Re: JDK 16 EA build 22 is available

[Rick Hillegas]

Thanks, Rory. Derby builds and tests cleanly with jdk 16 early access 
build 22. See 
https://issues.apache.org/jira/browse/DERBY-7088?focusedCommentId=17224958=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17224958


Cheers,
-Rick

On 11/1/20 9:14 AM, Rory O'Donnell wrote:

Hi Rick,

OpenJDK 16 Early Access build 22**is now available at 
http://jdk.java.net/16


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

 * Schedule

            2020/12/10 Rampdown Phase One
            2021/01/14 Rampdown Phase Two
            2021/02/04         Initial Release Candidate
            2021/02/18         Final Release Candidate
            2021/03/16         General Availability

 * Features:
 o JEPs targeted to JDK 16, so far:
 + JEP 338: Vector API (Incubator)
   
 + JEP 347: Enable C++14 Language Features
   
 + JEP 357: Migrate from Mercurial to Git
   
 + JEP 369: Migrate to GitHub 
 + JEP 376: ZGC: Concurrent Thread-Stack Processing
   
 + JEP 386: Alpine Linux Port 
 + JEP 387: Elastic Metaspace 
 + JEP 388: Windows/AArch64 Port
   

**

 * Changes in recent builds that maybe of interest:
 o Build 21
 + JDK-8236862: Enhance support of Proxy class
 + JDK-8237990: Added Property to Control LDAP Authentication
   Mechanisms Allowed to Authenticate Over Clear Connections
 + JDK-8242068: Signed JAR support for RSASSA-PSS and EdDSA
 + JDK-8245417: Improve certificate chain handling
 + JDK-8253952: Refine ZipOutputStream.putNextEntry() to
   recalculate ZipEntry's compressed size
 o Build 20
 + JDK-8232092: (fs) Files::isWritable returns false on a
   writeable root directory (win)
 # Reported by JUnit5
 + JDK-8248262: Wrong link target in
   ModuleDescriptor#isAutomatic's API documentation
 # Reported by JUnit5
 + JDK-8253965: Delete the outdated java.awt.PeerFixer class
 + JDK-8253566: clazz.isAssignableFrom will return false for
   interface implementors
 # Found by Hibernate Validator
 + JDK-8254177: US/Pacific-New Zone name removed as part of
   tzdata2020b
 o Build 19
 + JDK-8253761: Wrong URI syntax printed by jar --describe-module
 # Reported by JUnit5

Project Lanai Early-Access Build: EA 6 Build 16-lanai+2-229 
 (2020/10/4)


 * These early-access builds are provided under the GNU General Public
   License, version 2, with the Classpath Exception
   .
 * These builds are based upon the latest state of the current in
   development JDK, and so may contain new features and unresolved bugs
   unrelated to Project Lanai. Project Lanai Wiki:
   https://wiki.openjdk.java.net/display/lanai/Main
 * Please send feedback via e-mail tolanai-...@openjdk.java.net
   . To send e-mail to this address
   you must firstsubscribe to the mailing list
.

Project Panama Early-Access Build: Build 16-panama+2-193 
 (2020/10/1)


 * These early-access, open-source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .
 * These builds are based on an incomplete version of JDK 16.
 * Please send feedback via e-mail topanama-...@openjdk.java.net
   . To send e-mail to this address
   you must firstsubscribe to the mailing list
.

Oracle JRE and JDK Cryptographic Roadmap has been updated [1]

 * Oracle has announced plans to add support for x25519 and x448 named
   elliptic curve groups to TLS.
 * Support is targeted for JDK 11 with the January 2021 CPU release.

Oracle Critical Patch Update released 21-Oct-2020

 * https://www.oracle.com/security-alerts/cpuoct2020.html


*__*
Rgds,Rory

[1] https://java.com/en/jre-jdk-cryptoroadmap.html