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: [External] : Re: JDK 22 Release Candidates & Virtual Threads pinning heads-up

[David Delabassee]

Thanks for the update !

--David

From: Rick Hillegas 
Date: Wednesday, 21 February 2024 at 01:12
To: derby-dev@db.apache.org , David Delabassee 

Subject: [External] : Re: JDK 22 Release Candidates & Virtual Threads pinning 
heads-up
Thanks for the heads-up, David. Derby found no problems with this
release candidate. See 
https://urldefense.com/v3/__https://issues.apache.org/jira/browse/DERBY-7159__;!!ACWV5N9M2RV99hQ!NiRSpNaVWJPRXz_9xYmBgaBecMh8TpG-Zc-v_cNJfgb6XebXiveBTs8VWTXKaN00KMFmVIyLSbmICoWVD-UZs8iGLOM3$<https://urldefense.com/v3/__https:/issues.apache.org/jira/browse/DERBY-7159__;!!ACWV5N9M2RV99hQ!NiRSpNaVWJPRXz_9xYmBgaBecMh8TpG-Zc-v_cNJfgb6XebXiveBTs8VWTXKaN00KMFmVIyLSbmICoWVD-UZs8iGLOM3$>

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://urldefense.com/v3/__https://inside.java/2024/02/17/virtual-threads-next-steps/__;!!ACWV5N9M2RV99hQ!NiRSpNaVWJPRXz_9xYmBgaBecMh8TpG-Zc-v_cNJfgb6XebXiveBTs8VWTXKaN00KMFmVIyLSbmICoWVD-UZsxUtvLKd$<https://urldefense.com/v3/__https:/inside.java/2024/02/17/virtual-threads-next-steps/__;!!ACWV5N9M2RV99hQ!NiRSpNaVWJPRXz_9xYmBgaBecMh8TpG-Zc-v_cNJfgb6XebXiveBTs8VWTXKaN00KMFmVIyLSbmICoWVD-UZsxUtvLKd$>
> [6] 
> https://urldefense.com/v3/__https://jdk.java.net/loom/__;!!ACWV5N9M2RV99hQ!NiRSpNaVWJPRXz_9xYmBgaBecMh8TpG-Zc-v_cNJfgb6XebXiveBTs8VWTXKaN00KMFmVIyLSbmICoWVD-UZs2hd_OBY$<https://urldefense.com/v3/__https:/jdk.java.net/loom/__;!!ACWV5N9M2RV99hQ!NiRSpNaVWJPRXz_9xYmBgaBecMh8TpG-Zc-v_cNJfgb6XebXiveBTs8VWTXKaN00KMFmVIyLSbmICoWVD-UZs2hd_OBY$>
> [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://urldefense.com/v3/__https://jdk.java.net/22/__;!!ACWV5N9M2RV99hQ!NiRSpNaVWJPRXz_9xYmBgaBecMh8TpG-Zc-v_cNJfgb6XebXiveBTs8VWTXKaN00KMFmVIyLSbmICoWVD-UZsyPEpb4d$<h

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

[Bart van der Bilt]

On 2/1/24 00:51, Rick Hillegas wrote:
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

Thanks for this query that really helped me! The data had indeed quite 
some issues. After fixing them, and using normal PK's everything works 
great.


No need for special tricks during data import now.

Thanks again for your help.

Best regards, Bart

P.D. 1: I am not sure how to test JIRA issue DERBY-6303 since the PK's 
are also unique.


P.D. 2: Could this database be useful to include in the Derby 
distribution as example?



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]

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

[Bart van der Bilt]

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: [External] : Re: JDK 22 RDP2 & Deprecate sun.misc.Unsafe Memory-Access Methods…

[David Delabassee]

Thanks for the update, Rik!

--David

From: Rick Hillegas 
Date: Sunday, 28 January 2024 at 14:32
To: derby-dev@db.apache.org , David Delabassee 

Subject: [External] : Re: JDK 22 RDP2 & Deprecate sun.misc.Unsafe Memory-Access 
Methods…
Thanks, David. Derby found no problems with build 22-ea+33-2356. See
https://urldefense.com/v3/__https://issues.apache.org/jira/browse/DERBY-7159__;!!ACWV5N9M2RV99hQ!IBtSXk2yDDQeTWeHLTl3jTj5bAcO6FKAkkLz7NfipJr4BmqF8yueQzcXY_Eui4g2yb7-kODH4y05wABIpHZN-IzJtTi8$<https://urldefense.com/v3/__https:/issues.apache.org/jira/browse/DERBY-7159__;!!ACWV5N9M2RV99hQ!IBtSXk2yDDQeTWeHLTl3jTj5bAcO6FKAkkLz7NfipJr4BmqF8yueQzcXY_Eui4g2yb7-kODH4y05wABIpHZN-IzJtTi8$>

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 su

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: Derby 10.16.1.2 artifacts release

[Andrea Selva]

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: Derby 10.16.1.2 artifacts release

[Bryan Pendleton]

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

bryan

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: 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: Are we missing updates to some registry for 10.17.1 release?

[Bryan Pendleton]

I updated the information at reporter.apache.org, but I'm not sure if
there are any other databases registries I forgot about.

bryan

On Sun, Jan 7, 2024 at 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: [External] : Re: JDK 22 Feature Freeze!

[David Delabassee]

Great, thanks for the update!

--David


From: Rick Hillegas 
Date: Friday, 15 December 2023 at 00:17
To: derby-dev@db.apache.org , David Delabassee 

Subject: [External] : Re: JDK 22 Feature Freeze!
Thanks, David. Derby has found no problems with build 22-ea+27-2262. See
https://urldefense.com/v3/__https://issues.apache.org/jira/browse/DERBY-7159__;!!ACWV5N9M2RV99hQ!LuZEZq4YVqzv1AuGzIL4vaD90y_5wsI1_R_Qru9hDxVvPzWOAlka7dqun3FNd8vQHPsLzMOA5yAODVrsOifG9_zIlB6l$<https://urldefense.com/v3/__https:/issues.apache.org/jira/browse/DERBY-7159__;!!ACWV5N9M2RV99hQ!LuZEZq4YVqzv1AuGzIL4vaD90y_5wsI1_R_Qru9hDxVvPzWOAlka7dqun3FNd8vQHPsLzMOA5yAODVrsOifG9_zIlB6l$>

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://urldefense.com/v3/__https://jdk.java.net/22/__;!!ACWV5N9M2RV99hQ!LuZEZq4YVqzv1AuGzIL4vaD90y_5wsI1_R_Qru9hDxVvPzWOAlka7dqun3FNd8vQHPsLzMOA5yAODVrsOifG91Z86X7T$<https://urldefense.com/v3/__https:/jdk.java.net/22/__;!!ACWV5N9M2RV99hQ!LuZEZq4YVqzv1AuGzIL4vaD90y_5wsI1_R_Qru9hDxVvPzWOAlka7dqun3FNd8v

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: [ANNOUNCE] Apache Derby 10.17.1.0 released

[Sergio Lissner via derby-dev]

Congrats Derby team with a new release.
Is there any plan to create official repository/mirror of Derby on github?

Best regards, 
 Sergio Lissner 

On Tuesday, November 14, 2023 at 11:04:52 AM PST, Rick Hillegas 
 wrote:  
 
 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.

  

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

[Bryan Pendleton]

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

Re: announcement messages

[Bryan Pendleton]

Rick, I have this memory that certain email lists require that you
use your Apache email address, and there is some trickery
to get your email vectored through a special mail forwarder
to accomplish that.

I'm not sure if these are the right instructions, but maybe?

https://infra.apache.org/committer-email.html

bryan

On Mon, Nov 13, 2023 at 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

[Bryan Pendleton]

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: draft release announcement for Derby 10.17.1.0

[Bryan Pendleton]

Thanks Rick! No other suggestions from me.

bryan

On Sat, Nov 11, 2023 at 10:57 AM Rick Hillegas  wrote:
>
> 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 see http://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.
>

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.

Re: draft release announcement for Derby 10.17.1.0

[Bryan Pendleton]

Something about "This lets the release run on the Java SE 21 platform"
seems just a little bit awkward to me.

Would it be accurate to say something like:

- The chief feature of Derby 10.17.1.0 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.

thanks,

bryan

On Fri, Nov 10, 2023 at 10:53 AM Rick Hillegas  wrote:
>
> 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.
>

Re: [VOTE] 10.17.1.0 release

[Knut Anders Hatlen]

Rick Hillegas  writes:

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

+1

I've run the regression tests with Java 21 on Debian 12. I've also
verified the signatures of the tarballs and zip files, and done some ad
hoc testing. No problems were found.

Thanks,

-- 
Knut Anders

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: [VOTE] 10.17.1.0 release

[Bryan Pendleton]

I vote +1 for the 10.17.1.0 release candidate.

I tested the release binaries successfully on Linux and on Windows
without finding any problems. I also reviewed the release notes
and I verified the binary signatures. I documented my results
in the wiki.

thanks,

bryan

On Sun, Oct 22, 2023 at 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

Re: derby 10.17.1 release?

[Bryan Pendleton]

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

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

Re: derby 10.17.1 release?

[Bryan Pendleton]

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
>

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: [External] : Re: JDK 20 Rampdown Phase 2 & JMX Heads-up

[David Delabassee]

Good news, thanks a lot for all your efforts!

--David

On 26/01/2023 00:08, Rick Hillegas wrote:
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://urldefense.com/v3/__https://jdk.java.net/20/__;!!ACWV5N9M2RV99hQ!LAi6L2RkPup_xGYw-5hFRhR7zo4U9xVl6bVu6xfV846FJUQtJHcGxi-J9L5TsBM_QN1e1kzkGCP6yw82eeBOossskVg7$ 
[2] https://mail.openjdk.org/pipermail/jdk-dev/2023-January/007308.html
[3] 
https://urldefense.com/v3/__https://jdk.java.net/21/__;!!ACWV5N9M2RV99hQ!LAi6L2RkPup_xGYw-5hFRhR7zo4U9xVl6bVu6xfV846FJUQtJHcGxi-J9L5TsBM_QN1e1kzkGCP6yw82eeBOomhdGAGL$ 



## 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://urldefense.com/v3/__https://jdk.java.net/20/release-notes__;!!ACWV5N9M2RV99hQ!LAi6L2RkPup_xGYw-5hFRhR7zo4U9xVl6bVu6xfV846FJUQtJHcGxi-J9L5TsBM_QN1e1kzkGCP6yw82eeBOoi7nrCpJ$ 


### 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://urldefense.com/v3/__https://jdk.java.net/21/__;!!ACWV5N9M2RV99hQ!LAi6L2RkPup_xGYw-5hFRhR7zo4U9xVl6bVu6xfV846FJUQtJHcGxi-J9L5TsBM_QN1e1kzkGCP6yw82eeBOomhdGAGL$ 
[10] 
https://urldefense.com/v3/__https://download.java.net/java/early_access/jdk21/docs/api/__;!!ACWV5N9M2RV99hQ!LAi6L2RkPup_xGYw-5hFRhR7zo4U9xVl6bVu6xfV846FJUQtJHcGxi-J9L5TsBM_QN1e1kzkGCP6yw82eeBOomHP4Lwr$ 


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

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

[Stanimir Stamenkov via derby-dev]

Thu, 5 Jan 2023 08:26:03 -0800, /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.


Thank you for spending the time to investigate it, nevertheless.  I 
understand it could be an issue that may be nearly impossible to 
resolve.  Wish you and all Derby devs best of luck in the new year!




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?


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 

]

--

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

[Stanimir Stamenkov via derby-dev]

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]

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://urldefense.com/v3/__https://github.com/openjdk/jdk__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTwY8djft$ 
[6] 
https://urldefense.com/v3/__https://github.com/openjdk/jdk20__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoT4oRdAUK$ 
[7] 
https://urldefense.com/v3/__https://jdk.java.net/21/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoT5lq0Ja0$ 



## 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 impact of 
value objects on their applications, and to provide feedback to 
the valhalla-dev [12] mailing list.


[8] 
https://urldefense.com/v3/__https://jdk.java.net/valhalla/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTyVj13HB$ 
[9] https://openjdk.org/jeps/8277163

[10] https://openjdk.org/projects/valhalla/early-access
[11] 
https://urldefense.com/v3/__https://inside.java/2022/12/06/jepcafe15/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTxkGx8mB$ 
[12] https://mail.openjdk.org/pipermail/valhalla-dev/



## Heads-up - Generational ZGC: New Early-Access Builds

New Generational ZGC [13] Early-Access Builds have been updated 
recently [14]. These EA builds are provided under the GNU GPL v2, 
with the Classpath Exception.


### Changes include :
- Rebased on top of jdk-20+21
- Added macOS builds
- Heuristics rewriten to deal with a problematic case where 
Generational ZGC spent too much focus on doing young generation 
collection when it’s more beneficial to spend resources to collect 
the old generation.
- GC logging rewriten to easier see what log lines belon

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

[David Delabassee]

thod 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://urldefense.com/v3/__https://github.com/openjdk/jdk__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTwY8djft$ 
[6] 
https://urldefense.com/v3/__https://github.com/openjdk/jdk20__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoT4oRdAUK$ 
[7] 
https://urldefense.com/v3/__https://jdk.java.net/21/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoT5lq0Ja0$ 



## 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 impact of value objects on 
their applications, and to provide feedback to the valhalla-dev 
[12] mailing list.


[8] 
https://urldefense.com/v3/__https://jdk.java.net/valhalla/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTyVj13HB$ 
[9] https://openjdk.org/jeps/8277163

[10] https://openjdk.org/projects/valhalla/early-access
[11] 
https://urldefense.com/v3/__https://inside.java/2022/12/06/jepcafe15/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTxkGx8mB$ 
[12] https://mail.openjdk.org/pipermail/valhalla-dev/



## Heads-up - Generational ZGC: New Early-Access Builds

New Generational ZGC [13] Early-Access Builds have been updated 
recently [14]. These EA builds are provided under the GNU GPL v2, 
with the Classpath Exception.


### Changes include :
- Rebased on top of jdk-20+21
- Added macOS builds
- Heuristics rewriten to deal with a problematic case where 
Generational ZGC spent too much focus on doing young generation 
collection when it’s more beneficial to spend resources to collect 
the old generation.
- GC logging rewriten to easier see what log lines belong to what 
collection / generation, plus many additional changes that should 
make it easier to read and understand GC logs
- Barrier elision enhanced to remove barriers from array access of 
newly allocated arrays

- Enhanced the generated hs_err crash text file
- Fixed and unified code quality and style

For more information, make sure to watch this Inside Java Newscast 
[15] dedicated on Generational ZGC. Feedback should be sent to the 
zgc-dev mailing list [16].


[13] 
https://urldefense.com/v3/__https://jdk.java.net/genzgc/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoT7oZBrZj$ 
[14] https://bugs.openjdk.org/browse/JDK-8272979
[15] 
https://urldefense.com/v3/__https://inside.java/2022/11/17/insidejava-newscast-037/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoT6cWz8M1$ 
[16] https://mail.openjdk.org/pipermail/zgc-dev/



## JavaFX 20 Early-Access Builds

These are early access builds of the JavaFX 20 Runtime, built from 
openjdk/jfx [17]. They allow JavaFX application developers to build 
and test their applications with JavaFX 20 on JDK 20. The latest 
builds 10 (2022/12/5) are now available [18] with javadoc here 
[19]. Feedback should be forwarded to the openjfx-dev [19] mailing 
list. For more details, you might want to listen this Inside Java 
podcast episo

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

[Rick Hillegas]

lue 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://urldefense.com/v3/__https://github.com/openjdk/jdk__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTwY8djft$ 
[6] 
https://urldefense.com/v3/__https://github.com/openjdk/jdk20__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoT4oRdAUK$ 
[7] 
https://urldefense.com/v3/__https://jdk.java.net/21/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoT5lq0Ja0$ 



## 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 impact of value objects on 
their applications, and to provide feedback to the valhalla-dev [12] 
mailing list.


[8] 
https://urldefense.com/v3/__https://jdk.java.net/valhalla/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTyVj13HB$ 
[9] https://openjdk.org/jeps/8277163

[10] https://openjdk.org/projects/valhalla/early-access
[11] 
https://urldefense.com/v3/__https://inside.java/2022/12/06/jepcafe15/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTxkGx8mB$ 
[12] https://mail.openjdk.org/pipermail/valhalla-dev/



## Heads-up - Generational ZGC: New Early-Access Builds

New Generational ZGC [13] Early-Access Builds have been updated 
recently [14]. These EA builds are provided under the GNU GPL v2, 
with the Classpath Exception.


### Changes include :
- Rebased on top of jdk-20+21
- Added macOS builds
- Heuristics rewriten to deal with a problematic case where 
Generational ZGC spent too much focus on doing young generation 
collection when it’s more beneficial to spend resources to collect 
the old generation.
- GC logging rewriten to easier see what log lines belong to what 
collection / generation, plus many additional changes that should 
make it easier to read and understand GC logs
- Barrier elision enhanced to remove barriers from array access of 
newly allocated arrays

- Enhanced the generated hs_err crash text file
- Fixed and unified code quality and style

For more information, make sure to watch this Inside Java Newscast 
[15] dedicated on Generational ZGC. Feedback should be sent to the 
zgc-dev mailing list [16].


[13] 
https://urldefense.com/v3/__https://jdk.java.net/genzgc/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoT7oZBrZj$ 
[14] https://bugs.openjdk.org/browse/JDK-8272979
[15] 
https://urldefense.com/v3/__https://inside.java/2022/11/17/insidejava-newscast-037/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoT6cWz8M1$ 
[16] https://mail.openjdk.org/pipermail/zgc-dev/



## JavaFX 20 Early-Access Builds

These are early access builds of the JavaFX 20 Runtime, built from 
openjdk/jfx [17]. They allow JavaFX application developers to build 
and test their applications with JavaFX 20 on JDK 20. The latest 
builds 10 (2022/12/5) are now available [18] with javadoc here [19]. 
Feedback should be forwarded to the openjfx-dev [19] mailing list. 
For more details, you might want to listen this Inside Java podcast 
episode [20].


[17] 
https://urldefense.com/v3/__https://github.com/openjdk/jfx__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoT-yh--jZ$ 
[18] 
https://urldefense.com/v3/__https://jdk.java.net/javafx20/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTyYpix7u$ 
[19] 
https://urldefense.

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

[David Delabassee]

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

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 
migra

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

[David Delabassee]

Hi Rick,

I suggest to bring this on https://mail.openjdk.org/mailman/listinfo/net-dev

Thanks,

--David

On 15/12/2022 00:06, Rick Hillegas wrote:
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://urldefense.com/v3/__https://jdk.java.net/20/__;!!ACWV5N9M2RV99hQ!JlAX3Q24L6xKnmCWqVSLexNFj1Ur8YNiWzrUoN5g4vc3ks1238-ajUkxY3UuW2yFFOgqtyyYShAGPbi5Td8Z9h0LcELZ$ 
[3] 
https://urldefense.com/v3/__https://jdk.java.net/20/release-notes__;!!ACWV5N9M2RV99hQ!JlAX3Q24L6xKnmCWqVSLexNFj1Ur8YNiWzrUoN5g4vc3ks1238-ajUkxY3UuW2yFFOgqtyyYShAGPbi5Td8Z9pmawnai$ 



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


## Head

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/


## Head

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 

Re: draft release announcement for 10.16.1.1

[Bryan Pendleton]

Looks great!

bryan

On Tue, Jun 14, 2022 at 3:23 PM Rick Hillegas  wrote:
>
> 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.

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.

Re: draft release announcement for 10.16.1.1

[Bryan Pendleton]

Should the announcement also mention the Java version compatibility level?

bryan

On Tue, Jun 14, 2022 at 10:50 AM Rick Hillegas  wrote:
>
> 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

Re: maven publication step for release 10.16.1.1

[Bryan Pendleton]

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

Re: maven publication step for release 10.16.1.1

[Bryan Pendleton]

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
>

Re: [RESULT] [VOTE] 10.15.2.0 Release

[Bryan Pendleton]

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

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

Re: [VOTE] 10.16.1.1 release

[Bryan Pendleton]

Thanks for putting together the 10.16 release, Rick.

I vote +1.

I successfully used the 10.16.1.1 release with OpenJDK 17 on Ubuntu 18,
and with Oracle JDK 17 on Windows 10. On both platforms I also verified
that attempting to use the 10.16.1.1 release with older versions of Java,
including Java 8, Java 9, and Java 11,  resulted in the expected
"wrong class file version" messages. I ran a number of small tests,
including the jdbcapi suite, without any problems. I recorded the details
in the 10.16 wiki pages in our Confluence.

The only tiny question I had was with
https://svn.apache.org/viewvc/db/derby/code/branches/10.16/BUILDING.html?view=co
which contains the line "You need to install a Java 9 JDK".

I have no other feedback.

bryan

On Thu, May 19, 2022 at 2:32 PM Rick Hillegas  wrote:
>
> 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
>

Re: remaining release-vetting tasks

[Bryan Pendleton]

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
>

Re: remaining release-vetting tasks

[Bryan Pendleton]

Thanks Rick! I'm hoping to spend some time with the Release Candidate
over the upcoming long weekend.

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
>

Re: [External] : [VOTE] 10.16.1.1 release

[Dag Wanvik]

+1

Dag

On 19/05/2022 23:32, Rick Hillegas wrote:
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://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/db/derby/db-derby-10.16.1.1/__;!!ACWV5N9M2RV99hQ!MB5sijgggZqqcHtK5TWCDR8egs4xyHYHy6aqapqHk6CphU0qrrr2WyN0uLEiSGca8kKiYo_Wgq44Ejn0UTOxdwGG$ 


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://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/DERBY/DerbyTenSixteenOneRelease__;!!ACWV5N9M2RV99hQ!MB5sijgggZqqcHtK5TWCDR8egs4xyHYHy6aqapqHk6CphU0qrrr2WyN0uLEiSGca8kKiYo_Wgq44Ejn0UW-tczdG$ 


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

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

[Bryan Pendleton]

> 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

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

[David Delabassee]

Noted, thanks for testing Rick!

On 02/12/2021 23:00, Rick Hillegas wrote:

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://urldefense.com/v3/__https://issues.apache.org/jira/browse/DERBY-7126__;!!ACWV5N9M2RV99hQ!Z0NhSfiUIr712byfebducb6uA7h7IpG_uNV8csT10k4RbH6wwsU4riSOsSYMPZNUBTD1$ 
.


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://urldefense.com/v3/__https://jdk.java.net/18/__;!!ACWV5N9M2RV99hQ!Z0NhSfiUIr712byfebducb6uA7h7IpG_uNV8csT10k4RbH6wwsU4riSOsSYMPVqOsyLE$ 


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
   

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

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

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

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

[Deepak Damodaran]

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

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

*

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

 * *G1 GC & Parallel GC Improvements in JDK 17*
 o 

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

[Rory O'Donnell]

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

*

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

 * *G1 GC & Parallel GC Improvements in JDK 17*
 o 

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?

[Bryan Pendleton]

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: [External] : Re: JDK 17 is now in the Release Candidate Phase

[Rory O'Donnell]

Many thanks Rick!

On 12/08/2021 13:14, Rick Hillegas wrote:

Hi Rory,

No new issues were found with the first release candidate. See 
https://urldefense.com/v3/__https://issues.apache.org/jira/browse/DERBY-7110?focusedCommentId=17398033=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel*comment-17398033__;Iw!!ACWV5N9M2RV99hQ!aBGhgtQw0mpZZrwzDwrQGojKcXCCEroI6zN4IDuBCRMn9WerEV5MjEfeqmvNcuoPjGE$ 
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://urldefense.com/v3/__https://jdk.java.net/17*__;Kg!!ACWV5N9M2RV99hQ!aBGhgtQw0mpZZrwzDwrQGojKcXCCEroI6zN4IDuBCRMn9WerEV5MjEfeqmvNwmMweUk$ 



 * 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://urldefense.com/v3/__https://jdk.java.net/17/release-notes__;!!ACWV5N9M2RV99hQ!aBGhgtQw0mpZZrwzDwrQGojKcXCCEroI6zN4IDuBCRMn9WerEV5MjEfeqmvNaQb_fEg$ 


 * 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://urldefense.com/v3/__https://jdk.java.net/18*__;Kg!!ACWV5N9M2RV99hQ!aBGhgtQw0mpZZrwzDwrQGojKcXCCEroI6zN4IDuBCRMn9WerEV5MjEfeqmvN62z_QV4$ 



 * 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://urldefense.com/v3/__https://jdk.java.net/18/release-notes__;!!ACWV5N9M2RV99hQ!aBGhgtQw0mpZZrwzDwrQGojKcXCCEroI6zN4IDuBCRMn9WerEV5MjEfeqmvNjW0nzgA$ 


 * 

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: [External] : Re: JDK 17 is now in Rampdown Phase Two

[Rory O'Donnell]

Many thanks Rick!

On 17/07/2021 15:03, Rick Hillegas wrote:

Hi Rory,

Derby builds and tests cleanly with the rampdown phase 2 jdk. For more 
detail, see 
https://urldefense.com/v3/__https://issues.apache.org/jira/browse/DERBY-7110?focusedCommentId=17382573=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel*comment-17382573__;Iw!!ACWV5N9M2RV99hQ!blzixLmzP1yKVBfJSHhvbXFDUjVY7Di_GlrFDyTH5l-FDc0viBLxJQIsVxaQ2tz1enU$ 


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://urldefense.com/v3/__https://jdk.java.net/17*__;Kg!!ACWV5N9M2RV99hQ!blzixLmzP1yKVBfJSHhvbXFDUjVY7Di_GlrFDyTH5l-FDc0viBLxJQIsVxaQcNFv1jY$ 



 * 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://urldefense.com/v3/__https://jdk.java.net/17/release-notes__;!!ACWV5N9M2RV99hQ!blzixLmzP1yKVBfJSHhvbXFDUjVY7Di_GlrFDyTH5l-FDc0viBLxJQIsVxaQXJYaTfk$ 




*
*

*OpenJDK 18 Early Access build 6 is available at * 
*https://urldefense.com/v3/__https://jdk.java.net/18*__;Kg!!ACWV5N9M2RV99hQ!blzixLmzP1yKVBfJSHhvbXFDUjVY7Di_GlrFDyTH5l-FDc0viBLxJQIsVxaQKVJ7mGU$ 



 * 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://urldefense.com/v3/__https://jdk.java.net/18/release-notes__;!!ACWV5N9M2RV99hQ!blzixLmzP1yKVBfJSHhvbXFDUjVY7Di_GlrFDyTH5l-FDc0viBLxJQIsVxaQPPF8kVA$ 


 * 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 








--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle 

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