[jira] [Commented] (DERBY-7152) Derby DOAP file has error
[
https://issues.apache.org/jira/browse/DERBY-7152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714697#comment-17714697
]
Richard N. Hillegas commented on DERBY-7152:
Thanks for bringing this to our attention. I have wrapped the 10.15.2.0 version
descriptor in its own element. Let us know if the file passes your
grammar checks now.
> Derby DOAP file has error
> -
>
> Key: DERBY-7152
> URL: https://issues.apache.org/jira/browse/DERBY-7152
> Project: Derby
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 10.16.1.1
>Reporter: Claude Warren
>Priority: Minor
> Attachments: derby-7152-01-aa-missingElementInDOAP.diff
>
>
> The DOAP file [1] as listed in [2] has the error:
> [line: 35, col: 16] \{E201} Multiple children of property element
> [1] http://svn.apache.org/repos/asf/db/derby/site/trunk/doap_Derby.rdf
> [2]
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DERBY-7152) Derby DOAP file has error
[
https://issues.apache.org/jira/browse/DERBY-7152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714695#comment-17714695
]
ASF subversion and git services commented on DERBY-7152:
Commit 1909294 from Richard N. Hillegas in branch 'site/trunk'
[ https://svn.apache.org/r1909294 ]
DERBY-7152: Wrap 10.15.2.0 version description in a separate release element;
commit derby-7152-01-aa-missingElementInDOAP.diff.
> Derby DOAP file has error
> -
>
> Key: DERBY-7152
> URL: https://issues.apache.org/jira/browse/DERBY-7152
> Project: Derby
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 10.16.1.1
>Reporter: Claude Warren
>Priority: Minor
> Attachments: derby-7152-01-aa-missingElementInDOAP.diff
>
>
> The DOAP file [1] as listed in [2] has the error:
> [line: 35, col: 16] \{E201} Multiple children of property element
> [1] http://svn.apache.org/repos/asf/db/derby/site/trunk/doap_Derby.rdf
> [2]
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DERBY-7152) Derby DOAP file has error
[
https://issues.apache.org/jira/browse/DERBY-7152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714694#comment-17714694
]
Richard N. Hillegas commented on DERBY-7152:
Attaching derby-7152-01-aa-missingElementInDOAP.diff. This patch wraps the
10.15.2.0 version description in its own element. Up until now
10.15.2.0 has been sharing the same parent as the 10.16.1.1 version.
Touches the following file:
{noformat}
M doap_Derby.rdf
{noformat}
> Derby DOAP file has error
> -
>
> Key: DERBY-7152
> URL: https://issues.apache.org/jira/browse/DERBY-7152
> Project: Derby
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 10.16.1.1
>Reporter: Claude Warren
>Priority: Minor
> Attachments: derby-7152-01-aa-missingElementInDOAP.diff
>
>
> The DOAP file [1] as listed in [2] has the error:
> [line: 35, col: 16] \{E201} Multiple children of property element
> [1] http://svn.apache.org/repos/asf/db/derby/site/trunk/doap_Derby.rdf
> [2]
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DERBY-7152) Derby DOAP file has error
[
https://issues.apache.org/jira/browse/DERBY-7152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard N. Hillegas updated DERBY-7152:
---
Attachment: derby-7152-01-aa-missingElementInDOAP.diff
> Derby DOAP file has error
> -
>
> Key: DERBY-7152
> URL: https://issues.apache.org/jira/browse/DERBY-7152
> Project: Derby
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 10.16.1.1
>Reporter: Claude Warren
>Priority: Minor
> Attachments: derby-7152-01-aa-missingElementInDOAP.diff
>
>
> The DOAP file [1] as listed in [2] has the error:
> [line: 35, col: 16] \{E201} Multiple children of property element
> [1] http://svn.apache.org/repos/asf/db/derby/site/trunk/doap_Derby.rdf
> [2]
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DERBY-7152) Derby DOAP file has error
Claude Warren created DERBY-7152:
Summary: Derby DOAP file has error
Key: DERBY-7152
URL: https://issues.apache.org/jira/browse/DERBY-7152
Project: Derby
Issue Type: Bug
Components: Documentation
Affects Versions: 10.16.1.1
Reporter: Claude Warren
The DOAP file [1] as listed in [2] has the error:
[line: 35, col: 16] \{E201} Multiple children of property element
[1] http://svn.apache.org/repos/asf/db/derby/site/trunk/doap_Derby.rdf
[2]
https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[INFO] DB Report for April, 2023
Hi all, thanks for the project updates, here is the report I submitted to the board. LMK if I missed anything. thanks, 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 (21 years ago) There are currently 47 committers and 44 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: Recent releases: Derby-10.16.1.1 was released on 2022-06-15. JDO 3.2.1 was released on 2022-05-25. JDO 3.2 was released on 2022-02-01. - The Derby community successfully completed their verification of Derby support for JDK 20. - JDO project is working on sonar cloud reports that will improve the quality of the code. We have already fixed reports under the category of Reliability and Security. Still working on Maintainability. - The Torque community are continuing development work on the version 5.2 code. There has been some new interest in the Torque user community with some new contributions from the community. ## Community Health: It was a quiet winter for the DB subprojects, with reduced activity in some areas but a few welcome increases in activity, such as the new user community interest on the Torque subproject and the appearance of a possible new Torque committer. Torque community have called a vote for the new committer; the results are expected in the next reporting period.
Re: Updates for our quarterly report to the board?
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.
Updates for our quarterly report to the board?
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
JDK 20 is now GA, JDK 21 Early-Access builds, and 2 important heads-up!
Welcome to the latest OpenJDK Quality Outreach update!
Last week was busy as we released both Java 20 and JavaFX 20. To
celebrate the launch, we hosted a live event focused on Java 20, i.e.
Level Up Java Day. All the sessions recordings will be made available
shortly on the YouTube Java channel.
Some recent events shown us that it is useful to conduct tests using the
latest early-access OpenJDK builds. This will benefit the OpenJDK
codebase but also your own codebase. Sometime, a failure could be due to
an actual regression introduced in OpenJDK. In that case, we obviously
want to hear about it while we can still address it. But sometime, a
failure could also be due to a subtle behaviour change... that works as
expected. Regardless of if it's a bug or a test that is now broken due
to a behaviour change, we want to hear from you. In the latter case, it
might also mean that we should probably communicate more about those
changes even if they might seem subtle. On that note, please make sure
to check all the 2 Heads-Up below: "Support for Unicode CLDR Version 42"
and "New network interface names on Windows".
So please, let us know if you observe anything using the latest
early-access builds of JDK 21.
## Heads-Up - JDK 20 - Support for Unicode CLDR Version 42
The JDK's locale data is based on the Unicode Consortium's Unicode
Common Locale Data Repository (CLDR). As mentioned in the December 2022
Quality Outreach newsletter [1], JDK 20 upgraded CLDR [2] to version 42
[3], which was released in October 2022. This version includes a "more
sophisticated handling of spaces" [4] that replaces regular spaces with
non-breaking spaces (NBSP / `\u00A0`) or narrow non-breaking spaces
(NNBSP / `\u202F`):
- in time formats between `a` and time
- in unit formats between {0} and unit
- in Cyrillic date formats before year marker such as `г`
Other noticeable changes include:
* " at " is no longer used for standard date/time format ’ [5]
* fix first day of week info for China (CN) [6]
* Japanese: Support numbers up to 京 [7]
As a consequence, production and test code that produces or parses
locale-dependent strings like formatted dates and times may change
behavior in potentially breaking ways (e.g. when a handcrafted datetime
string with a regular space is parsed, but the parser now expects an
NBSP or NNBSP). Issues can be hard to analyze because expected and
actual strings look very similar or even identical in various text
representations. To detect and fix these issues, make sure to use a text
editor that displays different kinds of spaces differently.
If the required fixes can't be implemented when upgrading to JDK 20,
consider using the JVM argument `-Djava.locale.providers=COMPAT` to use
legacy locale data. Note that this limits some locale-related
functionality and treat it as a temporary workaround, not a proper
solution. Moreover, the `COMPAT` option will be eventually removed in
the future.
It is also important to keep in mind that this kind of locale data
evolves regularly so programs parsing/composing the locale data by
themselves should be routinely checked with each JDK release.
[1]
https://mail.openjdk.org/pipermail/quality-discuss/2022-December/001100.html
[2] https://bugs.openjdk.org/browse/JDK-8284840
[3] https://cldr.unicode.org/index/downloads/cldr-42
[4] https://unicode-org.atlassian.net/browse/CLDR-14032
[5] https://unicode-org.atlassian.net/browse/CLDR-14831
[6] https://unicode-org.atlassian.net/browse/CLDR-11510
[7] https://unicode-org.atlassian.net/browse/CLDR-15966
## Heads-Up - JDK 21 - New network interface names on Windows
Network Names that the JDK assigns to network interfaces on Windows are
changing in JDK 21 [8].
The JDK historically synthesized names for network interfaces on
Windows. This has changed to use the names assigned by the Windows
operating system. For example, the JDK may have historically assigned a
name such as “eth0” for an ethernet interface and “lo” for the loopback.
The equivalent names that Windows assigns may be names such as
“ethernet_32768” and “loopback_0".
This change may impact code that does a lookup of network interfaces
with the `NetworkInterace.getByName(String name)` method. It also may
also be surprising to code that enumerates all network interfaces with
the `NetworkInterfaces.networkInterfaces()` or
`NetworkInterface.getNetworkInterfaces()` methods as the names of the
network interfaces will look different to previous releases. Depending
on configuration, it is possible that enumerating all network interfaces
will enumerate network interfaces that weren’t previously enumerated
because they didn’t have an Internet Protocol address assigned. The
display name returned by `NetworkInterface::getDisplayName` has not
changed so this should facilitate the identification of network
interfaces when using Windows native tools.
[8] https://bugs.openjdk.org/browse/JDK-8303898
## JDK 20
[jira] [Commented] (DERBY-7151) ERROR XSDA7: Restore of a serializable or SQLData object of class , attempted to read more data than was originally stored
[
https://issues.apache.org/jira/browse/DERBY-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695900#comment-17695900
]
Richard N. Hillegas commented on DERBY-7151:
It would be good to see the SQL statement which is failing. If you can't find
it in derby.log, then you may need to increase the level of diagnostic logging
by adding the following system properties to the JVM boot command which starts
your application:
{noformat}
-Dderby.language.logStatementText=true -Dderby.stream.error.logSeverityLevel=0
{noformat}
> ERROR XSDA7: Restore of a serializable or SQLData object of class , attempted
> to read more data than was originally stored
> --
>
> Key: DERBY-7151
> URL: https://issues.apache.org/jira/browse/DERBY-7151
> Project: Derby
> Issue Type: Bug
>Affects Versions: 10.16.1.1
> Environment: 'Windows 10' Version '10.0' Arch 'amd64'
> Java Info: Vendor 'Eclipse Adoptium' URL 'https://adoptium.net/' Version
> '17.0.2'
>Reporter: Daniel Gonzalez
>Priority: Major
>
> Unfortunately we can't reproduce this one but have had a customer report of
> the following crash:
>
> {quote}Restore of a serializable or SQLData object of class , attempted to
> read more data than was originally stored
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:115)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:141)
> at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:252)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:438)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:360)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2405)
> at
> org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:88)
> at
> org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(EmbedResultSet.java:4663)
> at
> org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:490)
> at org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:394)
> at
> uk.co.screamingfrog.seospider.db.UniqueUrlsTableOperations.getEncodedUrlIdFromDb(UniqueUrlsTableOperations.java:213)
> ... 9 more
> Caused by: ERROR XSDA7: Restore of a serializable or SQLData object of class
> , attempted to read more data than was originally stored
> at
> org.apache.derby.shared.common.error.StandardException.newException(StandardException.java:300)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory.java:170)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:75)
> ... 19 more
> Caused by: java.io.EOFException
> at
> org.apache.derby.iapi.services.io.ArrayInputStream.readDerbyUTF(ArrayInputStream.java:429)
> at
> org.apache.derby.iapi.types.SQLChar.readExternalFromArray(SQLChar.java:1093)
> at
> org.apache.derby.impl.store.raw.data.StoredPage.readRecordFromArray(StoredPage.java:5676)
> at
> org.apache.derby.impl.store.raw.data.StoredPage.restoreRecordFromSlot(StoredPage.java:1526)
> at
> org.apache.derby.impl.store.raw.data.BasePage.fetchFromSlot(BasePage.java:450)
> at
> org.apache.derby.impl.store.raw.data.CachedPage.fetchFromSlot(CachedPage.java:53)
> at
> org.apache.derby.impl.store.access.btree.ControlRow.compareIndexRowFromPageToKey(ControlRow.java:1243)
> at
> org.apache.derby.impl.store.access.btree.ControlRow.searchForEntry(ControlRow.java:1001)
> at
> org.apache.derby.impl.store.access.btree.LeafControlRow.search(LeafControlRow.java:328)
> at
> org.apache.derby.impl.store.access.btree.BranchControlRow.search(BranchControlRow.java:291)
> at
> org.apache.derby.impl.store.access.btree.BranchControlRow.search(BranchControlRow.java:291)
> at
> org.apache.derby.impl.store.access.btree.BranchControlRow.search(BranchControlRow.java:291)
> at
> org.apache.derby.impl.store.access.btree.BTreeScan.positionAtStartForForwardScan(BTreeScan.java:392)
> at
> org.apache.derby.impl.store.access.btree.BTreeForwardScan.positionAtStartPosition(BTreeForwardScan.java:70)
> at
> org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java:129)
> at
> org.apache.derby.impl.store.access.btree.BTreeScan.fetchNextGroup(BTreeScan.java:1682)
> at
> org.apache.derby.impl.sql.execute.BulkTableScanResultSet.reloadArray(BulkTableScanResultSet.java:424)
> at
> org.apache.derby.impl.sql.execute.BulkTableScanResultSet.getNextRowCore(BulkTableScanResultSet.java:367)
> at
>
[jira] [Commented] (DERBY-7151) ERROR XSDA7: Restore of a serializable or SQLData object of class , attempted to read more data than was originally stored
[
https://issues.apache.org/jira/browse/DERBY-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695834#comment-17695834
]
Stanimir Stamenkov commented on DERBY-7151:
---
Looks really similar to (if not just the same) DERBY-7145.
> ERROR XSDA7: Restore of a serializable or SQLData object of class , attempted
> to read more data than was originally stored
> --
>
> Key: DERBY-7151
> URL: https://issues.apache.org/jira/browse/DERBY-7151
> Project: Derby
> Issue Type: Bug
>Affects Versions: 10.16.1.1
> Environment: 'Windows 10' Version '10.0' Arch 'amd64'
> Java Info: Vendor 'Eclipse Adoptium' URL 'https://adoptium.net/' Version
> '17.0.2'
>Reporter: Daniel Gonzalez
>Priority: Major
>
> Unfortunately we can't reproduce this one but have had a customer report of
> the following crash:
>
> {quote}Restore of a serializable or SQLData object of class , attempted to
> read more data than was originally stored
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:115)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:141)
> at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:252)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:438)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:360)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2405)
> at
> org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:88)
> at
> org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(EmbedResultSet.java:4663)
> at
> org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:490)
> at org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:394)
> at
> uk.co.screamingfrog.seospider.db.UniqueUrlsTableOperations.getEncodedUrlIdFromDb(UniqueUrlsTableOperations.java:213)
> ... 9 more
> Caused by: ERROR XSDA7: Restore of a serializable or SQLData object of class
> , attempted to read more data than was originally stored
> at
> org.apache.derby.shared.common.error.StandardException.newException(StandardException.java:300)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory.java:170)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:75)
> ... 19 more
> Caused by: java.io.EOFException
> at
> org.apache.derby.iapi.services.io.ArrayInputStream.readDerbyUTF(ArrayInputStream.java:429)
> at
> org.apache.derby.iapi.types.SQLChar.readExternalFromArray(SQLChar.java:1093)
> at
> org.apache.derby.impl.store.raw.data.StoredPage.readRecordFromArray(StoredPage.java:5676)
> at
> org.apache.derby.impl.store.raw.data.StoredPage.restoreRecordFromSlot(StoredPage.java:1526)
> at
> org.apache.derby.impl.store.raw.data.BasePage.fetchFromSlot(BasePage.java:450)
> at
> org.apache.derby.impl.store.raw.data.CachedPage.fetchFromSlot(CachedPage.java:53)
> at
> org.apache.derby.impl.store.access.btree.ControlRow.compareIndexRowFromPageToKey(ControlRow.java:1243)
> at
> org.apache.derby.impl.store.access.btree.ControlRow.searchForEntry(ControlRow.java:1001)
> at
> org.apache.derby.impl.store.access.btree.LeafControlRow.search(LeafControlRow.java:328)
> at
> org.apache.derby.impl.store.access.btree.BranchControlRow.search(BranchControlRow.java:291)
> at
> org.apache.derby.impl.store.access.btree.BranchControlRow.search(BranchControlRow.java:291)
> at
> org.apache.derby.impl.store.access.btree.BranchControlRow.search(BranchControlRow.java:291)
> at
> org.apache.derby.impl.store.access.btree.BTreeScan.positionAtStartForForwardScan(BTreeScan.java:392)
> at
> org.apache.derby.impl.store.access.btree.BTreeForwardScan.positionAtStartPosition(BTreeForwardScan.java:70)
> at
> org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java:129)
> at
> org.apache.derby.impl.store.access.btree.BTreeScan.fetchNextGroup(BTreeScan.java:1682)
> at
> org.apache.derby.impl.sql.execute.BulkTableScanResultSet.reloadArray(BulkTableScanResultSet.java:424)
> at
> org.apache.derby.impl.sql.execute.BulkTableScanResultSet.getNextRowCore(BulkTableScanResultSet.java:367)
> at
> org.apache.derby.impl.sql.execute.IndexRowToBaseRowResultSet.getNextRowCore(IndexRowToBaseRowResultSet.java:346)
> at
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:287)
> at
> org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(BasicNoPutResultSetImpl.java:488)
> at
>
[jira] [Created] (DERBY-7151) ERROR XSDA7: Restore of a serializable or SQLData object of class , attempted to read more data than was originally stored
Daniel Gonzalez created DERBY-7151:
--
Summary: ERROR XSDA7: Restore of a serializable or SQLData object
of class , attempted to read more data than was originally stored
Key: DERBY-7151
URL: https://issues.apache.org/jira/browse/DERBY-7151
Project: Derby
Issue Type: Bug
Affects Versions: 10.16.1.1
Environment: 'Windows 10' Version '10.0' Arch 'amd64'
Java Info: Vendor 'Eclipse Adoptium' URL 'https://adoptium.net/' Version
'17.0.2'
Reporter: Daniel Gonzalez
Unfortunately we can't reproduce this one but have had a customer report of the
following crash:
{quote}Restore of a serializable or SQLData object of class , attempted to read
more data than was originally stored
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:115)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:141)
at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:252)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:438)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:360)
at
org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2405)
at
org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:88)
at
org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(EmbedResultSet.java:4663)
at
org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:490)
at org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:394)
at
uk.co.screamingfrog.seospider.db.UniqueUrlsTableOperations.getEncodedUrlIdFromDb(UniqueUrlsTableOperations.java:213)
... 9 more
Caused by: ERROR XSDA7: Restore of a serializable or SQLData object of class ,
attempted to read more data than was originally stored
at
org.apache.derby.shared.common.error.StandardException.newException(StandardException.java:300)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory.java:170)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:75)
... 19 more
Caused by: java.io.EOFException
at
org.apache.derby.iapi.services.io.ArrayInputStream.readDerbyUTF(ArrayInputStream.java:429)
at org.apache.derby.iapi.types.SQLChar.readExternalFromArray(SQLChar.java:1093)
at
org.apache.derby.impl.store.raw.data.StoredPage.readRecordFromArray(StoredPage.java:5676)
at
org.apache.derby.impl.store.raw.data.StoredPage.restoreRecordFromSlot(StoredPage.java:1526)
at
org.apache.derby.impl.store.raw.data.BasePage.fetchFromSlot(BasePage.java:450)
at
org.apache.derby.impl.store.raw.data.CachedPage.fetchFromSlot(CachedPage.java:53)
at
org.apache.derby.impl.store.access.btree.ControlRow.compareIndexRowFromPageToKey(ControlRow.java:1243)
at
org.apache.derby.impl.store.access.btree.ControlRow.searchForEntry(ControlRow.java:1001)
at
org.apache.derby.impl.store.access.btree.LeafControlRow.search(LeafControlRow.java:328)
at
org.apache.derby.impl.store.access.btree.BranchControlRow.search(BranchControlRow.java:291)
at
org.apache.derby.impl.store.access.btree.BranchControlRow.search(BranchControlRow.java:291)
at
org.apache.derby.impl.store.access.btree.BranchControlRow.search(BranchControlRow.java:291)
at
org.apache.derby.impl.store.access.btree.BTreeScan.positionAtStartForForwardScan(BTreeScan.java:392)
at
org.apache.derby.impl.store.access.btree.BTreeForwardScan.positionAtStartPosition(BTreeForwardScan.java:70)
at
org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java:129)
at
org.apache.derby.impl.store.access.btree.BTreeScan.fetchNextGroup(BTreeScan.java:1682)
at
org.apache.derby.impl.sql.execute.BulkTableScanResultSet.reloadArray(BulkTableScanResultSet.java:424)
at
org.apache.derby.impl.sql.execute.BulkTableScanResultSet.getNextRowCore(BulkTableScanResultSet.java:367)
at
org.apache.derby.impl.sql.execute.IndexRowToBaseRowResultSet.getNextRowCore(IndexRowToBaseRowResultSet.java:346)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:287)
at
org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(BasicNoPutResultSetImpl.java:488)
at
org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:450)
... 11 more
{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: JDK 20 Release Candidate and Deprecation
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
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17689964#comment-17689964 ] Richard N. Hillegas commented on DERBY-7149: Derby builds cleanly (including javadoc) and tests cleanly (with both the classpath and modulepath) using Open JDK build 20+36-2344. > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff, > derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff, > derby-7149-03-aa-JMXdocs.tar, > derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff, > derby-7149-05-aa-reenableJMXTest.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
JDK 20 Release Candidate and Deprecation
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 the Classpath Exception. The related Javadocs are available here [10] and the Release Notes here [11]. [9] https://jdk.java.net/21/ [10]
[jira] [Commented] (DERBY-7150) derby.log locked after database shutdown preventing deletion
[
https://issues.apache.org/jira/browse/DERBY-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684523#comment-17684523
]
Liam Sharp commented on DERBY-7150:
---
Thanks [~rhillegas] for this, much appreciated - I've updated to use this
approach
[here|https://github.com/screamingfrog/hello-world-cli/tree/derby-correct-shutdown]
and the log is released as you suggest. I'll close this one off as not a bug,
thanks again.
> derby.log locked after database shutdown preventing deletion
>
>
> Key: DERBY-7150
> URL: https://issues.apache.org/jira/browse/DERBY-7150
> Project: Derby
> Issue Type: Bug
>Affects Versions: 10.16.1.1
> Environment: Windows
>Reporter: Liam Sharp
>Priority: Major
>
> On Windows I'm unable to delete derby.log after shutting down the database.
>
> I've created a demo maven project
> [here|https://github.com/screamingfrog/hello-world-cli/tree/derby-locking-logfile],
> that if run on Windows, produces the following:
>
> {{2023-02-03 13:16:58,070 [main] INFO - derby.system.home will be set to:
> C:\Users\Administrator\derby-test}}
> {{2023-02-03 13:16:58,073 [main] INFO - Folder exists, deleting}}
> {{2023-02-03 13:16:58,073 [main] INFO - Initalising driver}}
> {{2023-02-03 13:16:58,189 [main] INFO - Creating connection
> jdbc:derby:EmbeddedDBAudit;create=true}}
> {{2023-02-03 13:16:58,955 [main] INFO - Shutting down connection
> jdbc:derby:EmbeddedDBAudit;shutdown=true}}
> {{2023-02-03 13:16:58,978 [main] WARN - Failed to delete file
> C:\Users\Administrator\derby-test\derby.log}}
>
> Code inline is here:
>
> {{{}package com.github.screamingfrog;{}}}{{{}import java.io.File;{}}}
> {{import java.sql.DriverManager;}}
> {{{}import java.sql.SQLException;{}}}{{{}import
> org.apache.logging.log4j.LogManager;{}}}
> {{{}import org.apache.logging.log4j.Logger;{}}}{{{}public class App {}}}
> {{{}}{{ private static final Logger LOGGER =
> LogManager.getLogger(App.class);}}
> {{ }}
> {{ private static final String DRIVER =
> "org.apache.derby.jdbc.EmbeddedDriver";}}{{ private static final String
> CONNECTION_URL = "jdbc:derby:EmbeddedDBAudit";}}
> {{ private static final String CREATE_CONNECTION_URL = CONNECTION_URL +
> ";create=true";}}
> {{ private static final String SHUTDOWN_CONNECTION_URL = CONNECTION_URL +
> ";shutdown=true";}}{{ private static File derbySystemFolder;}}{{ public
> static void main(}}
> {{ String[] args) }}
> {{ {}}
> {{ try }}
> {{ {}}
> {{ initDerbyHomeAndDriver();}}
> {{ createConnection();}}
> {{ shutdownConnectionAndCleanup();}}
> {{ }}}
> {{ catch (SQLException e) }}
> {{ {}}
> {{ LOGGER.error("SQLException: " + e, e);}}
> {{ }}}
> {{ }}}{{ private static void initDerbyHomeAndDriver() }}
> {{ {}}
> {{ setDerbyHome();}}
> {{ initDerbyDriverInstance();}}
> {{ }}}{{ private static void createConnection() throws SQLException }}
> {{ {}}
> {{ LOGGER.info("Creating connection " + CREATE_CONNECTION_URL);}}
> {{ DriverManager.getConnection(CREATE_CONNECTION_URL);}}
> {{ }}}{{ private static void shutdownConnectionAndCleanup() }}
> {{ {}}
> {{ LOGGER.info("Shutting down connection " +
> SHUTDOWN_CONNECTION_URL);}}
> {{ try }}
> {{ {}}
> {{ DriverManager.getConnection(SHUTDOWN_CONNECTION_URL);}}
> {{ }}}
> {{ catch (SQLException e) }}
> {{ {}}
> {{ if (!e.getSQLState().equals("08006"))}}
> {{ {}}
> {{ LOGGER.error("Failed to shutdown database " + e, e);}}
> {{ }}}
> {{ }}}{{ deleteFolder(derbySystemFolder);}}
> {{ }}}{{ private static void setDerbyHome() }}
> {{ {}}
> {{ derbySystemFolder = new File (System.getProperty("user.home") +
> File.separator + "derby-test");}}
> {{ LOGGER.info("derby.system.home will be set to: " +
> derbySystemFolder);}}
> {{ }}
> {{ if (derbySystemFolder.exists()) }}
> {{ {}}
> {{ LOGGER.info("Folder exists, deleting");}}
> {{ deleteFolder(derbySystemFolder);}}
> {{ }}}
> {{ System.setProperty("derby.system.home",
> derbySystemFolder.getAbsolutePath());}}
> {{ }}}{{ private static void initDerbyDriverInstance() }}
> {{ {}}
> {{ LOGGER.info("Initalising driver");}}
> {{ try }}
> {{ {}}
> {{ Class.forName(DRIVER).newInstance();}}
> {{ }}}
> {{ catch (ClassNotFoundException | InstantiationException |
> IllegalAccessException e) }}
> {{ {}}
> {{ LOGGER.error("Failed to init " + DRIVER + " " + e, e);}}
> {{ }}}
> {{ }}}{{ private static void deleteFolder(}}
> {{
[jira] [Closed] (DERBY-7150) derby.log locked after database shutdown preventing deletion
[
https://issues.apache.org/jira/browse/DERBY-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Liam Sharp closed DERBY-7150.
-
Resolution: Not A Bug
> derby.log locked after database shutdown preventing deletion
>
>
> Key: DERBY-7150
> URL: https://issues.apache.org/jira/browse/DERBY-7150
> Project: Derby
> Issue Type: Bug
>Affects Versions: 10.16.1.1
> Environment: Windows
>Reporter: Liam Sharp
>Priority: Major
>
> On Windows I'm unable to delete derby.log after shutting down the database.
>
> I've created a demo maven project
> [here|https://github.com/screamingfrog/hello-world-cli/tree/derby-locking-logfile],
> that if run on Windows, produces the following:
>
> {{2023-02-03 13:16:58,070 [main] INFO - derby.system.home will be set to:
> C:\Users\Administrator\derby-test}}
> {{2023-02-03 13:16:58,073 [main] INFO - Folder exists, deleting}}
> {{2023-02-03 13:16:58,073 [main] INFO - Initalising driver}}
> {{2023-02-03 13:16:58,189 [main] INFO - Creating connection
> jdbc:derby:EmbeddedDBAudit;create=true}}
> {{2023-02-03 13:16:58,955 [main] INFO - Shutting down connection
> jdbc:derby:EmbeddedDBAudit;shutdown=true}}
> {{2023-02-03 13:16:58,978 [main] WARN - Failed to delete file
> C:\Users\Administrator\derby-test\derby.log}}
>
> Code inline is here:
>
> {{{}package com.github.screamingfrog;{}}}{{{}import java.io.File;{}}}
> {{import java.sql.DriverManager;}}
> {{{}import java.sql.SQLException;{}}}{{{}import
> org.apache.logging.log4j.LogManager;{}}}
> {{{}import org.apache.logging.log4j.Logger;{}}}{{{}public class App {}}}
> {{{}}{{ private static final Logger LOGGER =
> LogManager.getLogger(App.class);}}
> {{ }}
> {{ private static final String DRIVER =
> "org.apache.derby.jdbc.EmbeddedDriver";}}{{ private static final String
> CONNECTION_URL = "jdbc:derby:EmbeddedDBAudit";}}
> {{ private static final String CREATE_CONNECTION_URL = CONNECTION_URL +
> ";create=true";}}
> {{ private static final String SHUTDOWN_CONNECTION_URL = CONNECTION_URL +
> ";shutdown=true";}}{{ private static File derbySystemFolder;}}{{ public
> static void main(}}
> {{ String[] args) }}
> {{ {}}
> {{ try }}
> {{ {}}
> {{ initDerbyHomeAndDriver();}}
> {{ createConnection();}}
> {{ shutdownConnectionAndCleanup();}}
> {{ }}}
> {{ catch (SQLException e) }}
> {{ {}}
> {{ LOGGER.error("SQLException: " + e, e);}}
> {{ }}}
> {{ }}}{{ private static void initDerbyHomeAndDriver() }}
> {{ {}}
> {{ setDerbyHome();}}
> {{ initDerbyDriverInstance();}}
> {{ }}}{{ private static void createConnection() throws SQLException }}
> {{ {}}
> {{ LOGGER.info("Creating connection " + CREATE_CONNECTION_URL);}}
> {{ DriverManager.getConnection(CREATE_CONNECTION_URL);}}
> {{ }}}{{ private static void shutdownConnectionAndCleanup() }}
> {{ {}}
> {{ LOGGER.info("Shutting down connection " +
> SHUTDOWN_CONNECTION_URL);}}
> {{ try }}
> {{ {}}
> {{ DriverManager.getConnection(SHUTDOWN_CONNECTION_URL);}}
> {{ }}}
> {{ catch (SQLException e) }}
> {{ {}}
> {{ if (!e.getSQLState().equals("08006"))}}
> {{ {}}
> {{ LOGGER.error("Failed to shutdown database " + e, e);}}
> {{ }}}
> {{ }}}{{ deleteFolder(derbySystemFolder);}}
> {{ }}}{{ private static void setDerbyHome() }}
> {{ {}}
> {{ derbySystemFolder = new File (System.getProperty("user.home") +
> File.separator + "derby-test");}}
> {{ LOGGER.info("derby.system.home will be set to: " +
> derbySystemFolder);}}
> {{ }}
> {{ if (derbySystemFolder.exists()) }}
> {{ {}}
> {{ LOGGER.info("Folder exists, deleting");}}
> {{ deleteFolder(derbySystemFolder);}}
> {{ }}}
> {{ System.setProperty("derby.system.home",
> derbySystemFolder.getAbsolutePath());}}
> {{ }}}{{ private static void initDerbyDriverInstance() }}
> {{ {}}
> {{ LOGGER.info("Initalising driver");}}
> {{ try }}
> {{ {}}
> {{ Class.forName(DRIVER).newInstance();}}
> {{ }}}
> {{ catch (ClassNotFoundException | InstantiationException |
> IllegalAccessException e) }}
> {{ {}}
> {{ LOGGER.error("Failed to init " + DRIVER + " " + e, e);}}
> {{ }}}
> {{ }}}{{ private static void deleteFolder(}}
> {{ final File folder) }}
> {{ {}}
> {{ LOGGER.debug("Deleting folder " + folder);}}
> {{ File[] files = folder.listFiles();}}
> {{ if (files != null) }}
> {{ {}}
> {{ for (File f : files) }}
> {{ {}}
> {{ if
[jira] [Commented] (DERBY-7150) derby.log locked after database shutdown preventing deletion
[
https://issues.apache.org/jira/browse/DERBY-7150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684211#comment-17684211
]
Richard N. Hillegas commented on DERBY-7150:
The Derby engine writes diagnostic messages to derby.log. As long as the engine
is running, I would expect the engine to maintain a write lock on derby.log. A
single Derby engine can manage connections to many databases. Your shutdown URL
only specified that you wanted to shutdown a single database. The engine is
still running. Try shutting down the engine:
{noformat}
DriverManager.getConnection("jdbc:derby:;shutdown=true");
{noformat}
See https://db.apache.org/derby/docs/10.16/devguide/tdevdvlp20349.html
> derby.log locked after database shutdown preventing deletion
>
>
> Key: DERBY-7150
> URL: https://issues.apache.org/jira/browse/DERBY-7150
> Project: Derby
> Issue Type: Bug
>Affects Versions: 10.16.1.1
> Environment: Windows
>Reporter: Liam Sharp
>Priority: Major
>
> On Windows I'm unable to delete derby.log after shutting down the database.
>
> I've created a demo maven project
> [here|https://github.com/screamingfrog/hello-world-cli/tree/derby-locking-logfile],
> that if run on Windows, produces the following:
>
> {{2023-02-03 13:16:58,070 [main] INFO - derby.system.home will be set to:
> C:\Users\Administrator\derby-test}}
> {{2023-02-03 13:16:58,073 [main] INFO - Folder exists, deleting}}
> {{2023-02-03 13:16:58,073 [main] INFO - Initalising driver}}
> {{2023-02-03 13:16:58,189 [main] INFO - Creating connection
> jdbc:derby:EmbeddedDBAudit;create=true}}
> {{2023-02-03 13:16:58,955 [main] INFO - Shutting down connection
> jdbc:derby:EmbeddedDBAudit;shutdown=true}}
> {{2023-02-03 13:16:58,978 [main] WARN - Failed to delete file
> C:\Users\Administrator\derby-test\derby.log}}
>
> Code inline is here:
>
> {{{}package com.github.screamingfrog;{}}}{{{}import java.io.File;{}}}
> {{import java.sql.DriverManager;}}
> {{{}import java.sql.SQLException;{}}}{{{}import
> org.apache.logging.log4j.LogManager;{}}}
> {{{}import org.apache.logging.log4j.Logger;{}}}{{{}public class App {}}}
> {{{}}{{ private static final Logger LOGGER =
> LogManager.getLogger(App.class);}}
> {{ }}
> {{ private static final String DRIVER =
> "org.apache.derby.jdbc.EmbeddedDriver";}}{{ private static final String
> CONNECTION_URL = "jdbc:derby:EmbeddedDBAudit";}}
> {{ private static final String CREATE_CONNECTION_URL = CONNECTION_URL +
> ";create=true";}}
> {{ private static final String SHUTDOWN_CONNECTION_URL = CONNECTION_URL +
> ";shutdown=true";}}{{ private static File derbySystemFolder;}}{{ public
> static void main(}}
> {{ String[] args) }}
> {{ {}}
> {{ try }}
> {{ {}}
> {{ initDerbyHomeAndDriver();}}
> {{ createConnection();}}
> {{ shutdownConnectionAndCleanup();}}
> {{ }}}
> {{ catch (SQLException e) }}
> {{ {}}
> {{ LOGGER.error("SQLException: " + e, e);}}
> {{ }}}
> {{ }}}{{ private static void initDerbyHomeAndDriver() }}
> {{ {}}
> {{ setDerbyHome();}}
> {{ initDerbyDriverInstance();}}
> {{ }}}{{ private static void createConnection() throws SQLException }}
> {{ {}}
> {{ LOGGER.info("Creating connection " + CREATE_CONNECTION_URL);}}
> {{ DriverManager.getConnection(CREATE_CONNECTION_URL);}}
> {{ }}}{{ private static void shutdownConnectionAndCleanup() }}
> {{ {}}
> {{ LOGGER.info("Shutting down connection " +
> SHUTDOWN_CONNECTION_URL);}}
> {{ try }}
> {{ {}}
> {{ DriverManager.getConnection(SHUTDOWN_CONNECTION_URL);}}
> {{ }}}
> {{ catch (SQLException e) }}
> {{ {}}
> {{ if (!e.getSQLState().equals("08006"))}}
> {{ {}}
> {{ LOGGER.error("Failed to shutdown database " + e, e);}}
> {{ }}}
> {{ }}}{{ deleteFolder(derbySystemFolder);}}
> {{ }}}{{ private static void setDerbyHome() }}
> {{ {}}
> {{ derbySystemFolder = new File (System.getProperty("user.home") +
> File.separator + "derby-test");}}
> {{ LOGGER.info("derby.system.home will be set to: " +
> derbySystemFolder);}}
> {{ }}
> {{ if (derbySystemFolder.exists()) }}
> {{ {}}
> {{ LOGGER.info("Folder exists, deleting");}}
> {{ deleteFolder(derbySystemFolder);}}
> {{ }}}
> {{ System.setProperty("derby.system.home",
> derbySystemFolder.getAbsolutePath());}}
> {{ }}}{{ private static void initDerbyDriverInstance() }}
> {{ {}}
> {{ LOGGER.info("Initalising driver");}}
> {{ try }}
> {{ {}}
> {{ Class.forName(DRIVER).newInstance();}}
> {{
[jira] [Created] (DERBY-7150) derby.log locked after database shutdown preventing deletion
Liam Sharp created DERBY-7150:
-
Summary: derby.log locked after database shutdown preventing
deletion
Key: DERBY-7150
URL: https://issues.apache.org/jira/browse/DERBY-7150
Project: Derby
Issue Type: Bug
Affects Versions: 10.16.1.1
Environment: Windows
Reporter: Liam Sharp
On Windows I'm unable to delete derby.log after shutting down the database.
I've created a demo maven project
[here|https://github.com/screamingfrog/hello-world-cli/tree/derby-locking-logfile],
that if run on Windows, produces the following:
{{2023-02-03 13:16:58,070 [main] INFO - derby.system.home will be set to:
C:\Users\Administrator\derby-test}}
{{2023-02-03 13:16:58,073 [main] INFO - Folder exists, deleting}}
{{2023-02-03 13:16:58,073 [main] INFO - Initalising driver}}
{{2023-02-03 13:16:58,189 [main] INFO - Creating connection
jdbc:derby:EmbeddedDBAudit;create=true}}
{{2023-02-03 13:16:58,955 [main] INFO - Shutting down connection
jdbc:derby:EmbeddedDBAudit;shutdown=true}}
{{2023-02-03 13:16:58,978 [main] WARN - Failed to delete file
C:\Users\Administrator\derby-test\derby.log}}
Code inline is here:
{{{}package com.github.screamingfrog;{}}}{{{}import java.io.File;{}}}
{{import java.sql.DriverManager;}}
{{{}import java.sql.SQLException;{}}}{{{}import
org.apache.logging.log4j.LogManager;{}}}
{{{}import org.apache.logging.log4j.Logger;{}}}{{{}public class App {}}}
{{{}}{{ private static final Logger LOGGER =
LogManager.getLogger(App.class);}}
{{ }}
{{ private static final String DRIVER =
"org.apache.derby.jdbc.EmbeddedDriver";}}{{ private static final String
CONNECTION_URL = "jdbc:derby:EmbeddedDBAudit";}}
{{ private static final String CREATE_CONNECTION_URL = CONNECTION_URL +
";create=true";}}
{{ private static final String SHUTDOWN_CONNECTION_URL = CONNECTION_URL +
";shutdown=true";}}{{ private static File derbySystemFolder;}}{{ public
static void main(}}
{{ String[] args) }}
{{ {}}
{{ try }}
{{ {}}
{{ initDerbyHomeAndDriver();}}
{{ createConnection();}}
{{ shutdownConnectionAndCleanup();}}
{{ }}}
{{ catch (SQLException e) }}
{{ {}}
{{ LOGGER.error("SQLException: " + e, e);}}
{{ }}}
{{ }}}{{ private static void initDerbyHomeAndDriver() }}
{{ {}}
{{ setDerbyHome();}}
{{ initDerbyDriverInstance();}}
{{ }}}{{ private static void createConnection() throws SQLException }}
{{ {}}
{{ LOGGER.info("Creating connection " + CREATE_CONNECTION_URL);}}
{{ DriverManager.getConnection(CREATE_CONNECTION_URL);}}
{{ }}}{{ private static void shutdownConnectionAndCleanup() }}
{{ {}}
{{ LOGGER.info("Shutting down connection " + SHUTDOWN_CONNECTION_URL);}}
{{ try }}
{{ {}}
{{ DriverManager.getConnection(SHUTDOWN_CONNECTION_URL);}}
{{ }}}
{{ catch (SQLException e) }}
{{ {}}
{{ if (!e.getSQLState().equals("08006"))}}
{{ {}}
{{ LOGGER.error("Failed to shutdown database " + e, e);}}
{{ }}}
{{ }}}{{ deleteFolder(derbySystemFolder);}}
{{ }}}{{ private static void setDerbyHome() }}
{{ {}}
{{ derbySystemFolder = new File (System.getProperty("user.home") +
File.separator + "derby-test");}}
{{ LOGGER.info("derby.system.home will be set to: " +
derbySystemFolder);}}
{{ }}
{{ if (derbySystemFolder.exists()) }}
{{ {}}
{{ LOGGER.info("Folder exists, deleting");}}
{{ deleteFolder(derbySystemFolder);}}
{{ }}}
{{ System.setProperty("derby.system.home",
derbySystemFolder.getAbsolutePath());}}
{{ }}}{{ private static void initDerbyDriverInstance() }}
{{ {}}
{{ LOGGER.info("Initalising driver");}}
{{ try }}
{{ {}}
{{ Class.forName(DRIVER).newInstance();}}
{{ }}}
{{ catch (ClassNotFoundException | InstantiationException |
IllegalAccessException e) }}
{{ {}}
{{ LOGGER.error("Failed to init " + DRIVER + " " + e, e);}}
{{ }}}
{{ }}}{{ private static void deleteFolder(}}
{{ final File folder) }}
{{ {}}
{{ LOGGER.debug("Deleting folder " + folder);}}
{{ File[] files = folder.listFiles();}}
{{ if (files != null) }}
{{ {}}
{{ for (File f : files) }}
{{ {}}
{{ if (f.isDirectory()) }}
{{ {}}
{{ deleteFolder(f);}}
{{ } }}
{{ else }}
{{ {}}
{{ LOGGER.debug("Deleting file " + f);}}
{{ if (! f.delete())}}
{{ {}}
{{ LOGGER.warn("Failed to delete file " + f);}}
{{ }}}
{{ }}}
{{ }}}
{{ }}}
{{
Re: [External] : Re: JDK 20 Rampdown Phase 2 & JMX Heads-up
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
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 -
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680831#comment-17680831 ] Richard N. Hillegas commented on DERBY-7149: Derby builds cleanly (including javadoc) and tests cleanly (with both the classpath and modulepath) using Open JDK build 20-ea+32-2328. > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff, > derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff, > derby-7149-03-aa-JMXdocs.tar, > derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff, > derby-7149-05-aa-reenableJMXTest.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
JDK 20 Rampdown Phase 2 & JMX Heads-up
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 - Lifetimes in the Foreign Function & Memory API https://cr.openjdk.java.net/~mcimadamore/panama/why_lifetimes.html - Java's Plans for 2023 - Inside Java
[INFO] DB Report for January, 2023
Below is the quarterly report I submitted to the board. Thank you to all the project communities for the feedback about project status and activities, much appreciated! thanks, 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 (20 years ago) There are currently 47 committers and 44 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: Recent releases: - Derby-10.16.1.1 was released on 2022-06-15. - JDO 3.2.1 was released on 2022-05-25. - JDO 3.2 was released on 2022-02-01. - Torque 5.1 was released on 2022-01-31. - The Derby community received a security vulnerability report and have addressed it; it is tracked as CVE-2022-46337. The fix in already in the source tree and will be delivered with Derby's next release, which is not yet scheduled. - The Derby community have also been testing with new builds of the upcoming JDK 20; Derby's testing processes may have found a bug in one of the JDK 20 features as a result which is good. - The JDO community evaluated the Derby vulnerability report to see if it applied to JDO's use of Derby; no JDO vulnerability was found as a result. - The JDO community are working on moving from JDK 8 to JDK 11, which will be a significant change and require a new 3.3 release, which is not yet scheduled. - The JDO community are working on improving code quality via feedback solicited from a code analysis tool called SonarCloud. SonarCloud itself is not open source but is free to analyze open source projects. A number of issues reported by the tool have been merged to the main branch and several others are currently being worked. - The Torque community have completed source modifications to move from JDK 8 to JDK 11. The changes are anticipated to be delivered as a new release 5.2, which is not yet scheduled. ## Community Health: Community health seems good across the project. All the mailing lists were at typical levels, and source contributions and fixes have been proceeding at a normal pace. All the project repositories are in a development stage trying to work toward future releases.
Re: FW: Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
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?
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
Topics for our January report to the board?
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
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
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17656291#comment-17656291 ] ASF subversion and git services commented on DERBY-7149: Commit 1906522 from Richard N. Hillegas in branch 'code/trunk' [ https://svn.apache.org/r1906522 ] DERBY-7149: Re-enable skipped MBean tests; commit derby-7149-05-aa-reenableJMXTest.diff. > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff, > derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff, > derby-7149-03-aa-JMXdocs.tar, > derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff, > derby-7149-05-aa-reenableJMXTest.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[
https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17656289#comment-17656289
]
Richard N. Hillegas commented on DERBY-7149:
Attaching derby-7149-05-aa-reenableJMXTest.diff. This patch re-enables the
skipped MBean tests and sets the following property on the remote JVM so that
the tests run again:
{noformat}
com.sun.management.jmxremote.serial.filter.pattern=
{noformat}
Full tests ran cleanly for me with the classpath. Based on that evidence, I
didn't bother running the tests with the modulepath.
Touches the following files:
{noformat}
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/management/CacheManagerMBeanTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/management/MBeanTest.java
{noformat}
> Make it possible to build and test Derby cleanly with JDK 20
>
>
> Key: DERBY-7149
> URL: https://issues.apache.org/jira/browse/DERBY-7149
> Project: Derby
> Issue Type: Task
> Components: Build tools
>Affects Versions: 10.17.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7149-01-aa-deprecateURLconstructor.diff,
> derby-7149-01-ac-deprecateURLconstructor.diff,
> derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff,
> derby-7149-03-aa-JMXdocs.tar,
> derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff,
> derby-7149-05-aa-reenableJMXTest.diff
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas updated DERBY-7149: --- Attachment: derby-7149-05-aa-reenableJMXTest.diff > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff, > derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff, > derby-7149-03-aa-JMXdocs.tar, > derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff, > derby-7149-05-aa-reenableJMXTest.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[
https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17656287#comment-17656287
]
Richard N. Hillegas commented on DERBY-7149:
In a private email, Kevin Walls from the Open JDK team reported that he was
able to get CacheManagerMBeanTest to run by setting the following system
property on the remote process:
{noformat}
com.sun.management.jmxremote.serial.filter.pattern=
{noformat}
I don't know why this didn't work for me. Maybe my experiments were setting the
property on the wrong JVM.
> Make it possible to build and test Derby cleanly with JDK 20
>
>
> Key: DERBY-7149
> URL: https://issues.apache.org/jira/browse/DERBY-7149
> Project: Derby
> Issue Type: Task
> Components: Build tools
>Affects Versions: 10.17.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7149-01-aa-deprecateURLconstructor.diff,
> derby-7149-01-ac-deprecateURLconstructor.diff,
> derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff,
> derby-7149-03-aa-JMXdocs.tar,
> derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
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
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 ] --
[jira] [Updated] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas updated DERBY-7147: --- Attachment: releaseNote.html > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Fix For: 10.14.3, 10.15.2.1, 10.16.1.2, 10.17.0.0 > > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar, > derby-7147-03-ab-updateLDAPinstructions.diff, > derby-7147-03-ab-updateLDAPinstructions.tar, > derby-7147-04-aa-pointLDAPTestAtInstructions.diff, releaseNote.html > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas updated DERBY-7147: --- Issue & fix info: Release Note Needed > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Fix For: 10.14.3, 10.15.2.1, 10.16.1.2, 10.17.0.0 > > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar, > derby-7147-03-ab-updateLDAPinstructions.diff, > derby-7147-03-ab-updateLDAPinstructions.tar, > derby-7147-04-aa-pointLDAPTestAtInstructions.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
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
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655068#comment-17655068 ] Richard N. Hillegas commented on DERBY-7149: Derby now builds and tests cleanly after the disruption caused by Open JDK build 20-ea+27-2213. > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff, > derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff, > derby-7149-03-aa-JMXdocs.tar, > derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655067#comment-17655067 ] ASF subversion and git services commented on DERBY-7149: Commit 1906409 from Richard N. Hillegas in branch 'code/trunk' [ https://svn.apache.org/r1906409 ] DERBY-7149: Suppress removal warnings for ThreadDeath, added by Open JDK build 20-ea+27-2213; commit derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff. > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff, > derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff, > derby-7149-03-aa-JMXdocs.tar, > derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655066#comment-17655066 ] Richard N. Hillegas commented on DERBY-7149: Tests passed cleanly on derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff with both the classpath and modulepath. > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff, > derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff, > derby-7149-03-aa-JMXdocs.tar, > derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655064#comment-17655064 ] ASF subversion and git services commented on DERBY-7149: Commit 1906408 from Richard N. Hillegas in branch 'docs/trunk' [ https://svn.apache.org/r1906408 ] DERBY-7149: Update MBeans documentation to mention deserialization filters; commit derby-7149-03-aa-JMXdocs.diff. > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff, > derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff, > derby-7149-03-aa-JMXdocs.tar, > derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
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
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
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[
https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654690#comment-17654690
]
Richard N. Hillegas commented on DERBY-7149:
Attaching derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff. This
patch adds @SuppressWarnings("removal") annotations to several methods in order
to suppress the new removal warnings introduced by the deprecation of
java.lang.ThreadDeath in Open JDK build 20-ea+27-2213.
Touches the following files:
{noformat}
M
java/org.apache.derby.engine/org/apache/derby/iapi/services/context/ContextManager.java
M
java/org.apache.derby.engine/org/apache/derby/iapi/services/context/SystemContext.java
M
java/org.apache.derby.engine/org/apache/derby/impl/services/monitor/BaseMonitor.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/unitTests/harness/BasicUnitTestManager.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/unitTests/harness/T_MultiThreadedIterations.java
M java/org.apache.derby.tools/org/apache/derby/impl/tools/ij/mtTester.java
{noformat}
> Make it possible to build and test Derby cleanly with JDK 20
>
>
> Key: DERBY-7149
> URL: https://issues.apache.org/jira/browse/DERBY-7149
> Project: Derby
> Issue Type: Task
> Components: Build tools
>Affects Versions: 10.17.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7149-01-aa-deprecateURLconstructor.diff,
> derby-7149-01-ac-deprecateURLconstructor.diff,
> derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff,
> derby-7149-03-aa-JMXdocs.tar,
> derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas updated DERBY-7149: --- Attachment: derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff, > derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff, > derby-7149-03-aa-JMXdocs.tar, > derby-7149-04-aa-suppress-ThreadDeath-removalWarnings.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
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
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 --
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[
https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654569#comment-17654569
]
Richard N. Hillegas commented on DERBY-7149:
The remaining disruption caused by Open JDK build 20-ea+27-2213 is some new
warnings introduced by the deprecation of java.lang.ThreadDeath. This includes
warnings in ContextManager, SystemContext, and BaseMonitor. All three classes
are delicate machinery at the foundation of Derby's architecture. I do not want
to touch these classes until we absolutely have to. Hopefully, by the time that
ThreadDeath is removed, there will be well understood best practices for how to
migrate systems software from Java's original thread model to a safer, modern
model.
My plan is simply to add @SuppressWarnings("removal") annotations to the
affected methods.
> Make it possible to build and test Derby cleanly with JDK 20
>
>
> Key: DERBY-7149
> URL: https://issues.apache.org/jira/browse/DERBY-7149
> Project: Derby
> Issue Type: Task
> Components: Build tools
>Affects Versions: 10.17.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7149-01-aa-deprecateURLconstructor.diff,
> derby-7149-01-ac-deprecateURLconstructor.diff,
> derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff,
> derby-7149-03-aa-JMXdocs.tar
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[
https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654539#comment-17654539
]
Richard N. Hillegas commented on DERBY-7149:
Attaching derby-7149-03-aa-JMXdocs.diff and a corresponding tarball of
generated output, derby-7149-03-aa-JMXdocs.tar. This patch adds a note to the
"Introduction to the Derby MBeans" topic of the Admin Guide. The note describes
how to work around the MBeans deserialization issue.
Touches the following file:
{noformat}
M src/adminguide/radminjmxintro.dita
{noformat}
> Make it possible to build and test Derby cleanly with JDK 20
>
>
> Key: DERBY-7149
> URL: https://issues.apache.org/jira/browse/DERBY-7149
> Project: Derby
> Issue Type: Task
> Components: Build tools
>Affects Versions: 10.17.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7149-01-aa-deprecateURLconstructor.diff,
> derby-7149-01-ac-deprecateURLconstructor.diff,
> derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff,
> derby-7149-03-aa-JMXdocs.tar
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas updated DERBY-7149: --- Attachment: derby-7149-03-aa-JMXdocs.diff > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff, > derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff, > derby-7149-03-aa-JMXdocs.tar > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas updated DERBY-7149: --- Attachment: derby-7149-03-aa-JMXdocs.tar > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff, > derby-7149-02-aa-disableJMXtest.diff, derby-7149-03-aa-JMXdocs.diff, > derby-7149-03-aa-JMXdocs.tar > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654506#comment-17654506 ] ASF subversion and git services commented on DERBY-7149: Commit 1906395 from Richard N. Hillegas in branch 'code/trunk' [ https://svn.apache.org/r1906395 ] DERBY-7149: Skip some MBean tests from JDK 20 onward; commit derby-7149-02-aa-disableJMXtest.diff. > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff, > derby-7149-02-aa-disableJMXtest.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[
https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654124#comment-17654124
]
Bryan Pendleton commented on DERBY-7149:
{quote}I intend to modify CacheManagerMBeanTest so that it skips the failing
tests when the default, restrictive filter is in place. I think it would also
be a good idea to modify our MBean documentation to describe this problem and
its workaround.
{quote}
That seems like a great approach. Thanks for taking care of this Rick!
> Make it possible to build and test Derby cleanly with JDK 20
>
>
> Key: DERBY-7149
> URL: https://issues.apache.org/jira/browse/DERBY-7149
> Project: Derby
> Issue Type: Task
> Components: Build tools
>Affects Versions: 10.17.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7149-01-aa-deprecateURLconstructor.diff,
> derby-7149-01-ac-deprecateURLconstructor.diff,
> derby-7149-02-aa-disableJMXtest.diff
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[
https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654119#comment-17654119
]
Richard N. Hillegas commented on DERBY-7149:
Attaching derby-7149-02-aa-disableJMXtest.diff. This patch disables the
testPageCache() and testStatementCache() tests in CacheManagementMBeanTest when
running over RMI with a JVM which has a restrictive deserialization filter.
With this patch, I get clean results from a full test run using both the
classpath and the modulepath.
Touches the following files:
{noformat}
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/management/JMXConnectionDecorator.java
Add some machinery so that the tests can introspect whether MBeans are running
over RMI.
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/management/CacheManagerMBeanTest.java
Skip the tests as described above.
{noformat}
> Make it possible to build and test Derby cleanly with JDK 20
>
>
> Key: DERBY-7149
> URL: https://issues.apache.org/jira/browse/DERBY-7149
> Project: Derby
> Issue Type: Task
> Components: Build tools
>Affects Versions: 10.17.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7149-01-aa-deprecateURLconstructor.diff,
> derby-7149-01-ac-deprecateURLconstructor.diff,
> derby-7149-02-aa-disableJMXtest.diff
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas updated DERBY-7149: --- Attachment: derby-7149-02-aa-disableJMXtest.diff > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff, > derby-7149-02-aa-disableJMXtest.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[
https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654117#comment-17654117
]
Richard N. Hillegas commented on DERBY-7149:
The breakage in CacheManagerMBeanTest is caused by a security enhancement in
the JVM. RMI-initiated deserialization has been locked down. A new filter must
be relaxed in order to deserialize information exposed by our MBeans, when
running the beans remotely over RMI. The filter is declared by the following
Oracle-specific property in $JAVA_HOME/conf/management/management.properties:
{noformat}
com.sun.management.jmxremote.serial.filter.pattern
{noformat}
Open JDK build 20-ea+27-2213 sets this property as follows:
{noformat}
com.sun.management.jmxremote.serial.filter.pattern=java.lang.*;java.math.BigInteger;java.math.BigDecimal;java.util.*;javax.management.openmbean.*;javax.management.ObjectName;java.rmi.MarshalledObject;javax.security.auth.Subject;!*
{noformat}
The filter cannot be overridden on the boot command line via a system property.
The filter can only be relaxed by hacking the JVM, that is, by editing
$JAVA_HOME/conf/management/management.properties.
But this filter must be relaxed in order to use our MBeans over RMI in order to
examine the page and statement caches. The following brute-force, bulk
relaxation works:
{noformat}
com.sun.management.jmxremote.serial.filter.pattern=*
{noformat}
I have not dug further into this to discover whether our MBeans would work with
a narrower filter, tailored to a few specific classes. Our MBeans are not
particularly useful and I don't think many applications use them. I regard our
MBeans as a proof of concept which someone could build on. No-one has done so.
I do not see much value in investing more work in a rarely used feature which
is becoming harder to use.
The following links explain something about this JVM behavior change:
https://bugs.openjdk.org/browse/JDK-8283093
https://bugs.openjdk.org/browse/JDK-8295938
I intend to modify CacheManagerMBeanTest so that it skips the failing tests
when the default, restrictive filter is in place. I think it would also be a
good idea to modify our MBean documentation to describe this problem and its
workaround.
> Make it possible to build and test Derby cleanly with JDK 20
>
>
> Key: DERBY-7149
> URL: https://issues.apache.org/jira/browse/DERBY-7149
> Project: Derby
> Issue Type: Task
> Components: Build tools
>Affects Versions: 10.17.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7149-01-aa-deprecateURLconstructor.diff,
> derby-7149-01-ac-deprecateURLconstructor.diff
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
Thanks for the quick response, David. I'm afraid I'm still confused.
Editing conf/management/management.properties to set
com.sun.management.jmxremote.serial.filter.pattern=*
causes
java junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest
to run cleanly. However, if I add the following debug printout to the
test...
System.out.println("XXX
com.sun.management.jmxremote.serial.filter.pattern = " +
System.getProperty("com.sun.management.jmxremote.serial.filter.pattern"));
System.out.flush();
...then I get the following result:
XXX com.sun.management.jmxremote.serial.filter.pattern = null
If I revert management.properties to the JDK default and then set the
property on the boot command line,
java -Dcom.sun.management.jmxremote.serial.filter.pattern=*
junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest
...the test prints out
XXX com.sun.management.jmxremote.serial.filter.pattern = *
but the test fails. It appears that the property is not a system
property, but is managed somewhere else. Is there a way to override this
property other than by editing conf/management/management.properties? Do
developers have to hack the JDK in order to get MBeans to function?
Thanks,
-Rick
On 12/21/22 10:06 PM, David Delabassee wrote:
Hi Rick,
Just to confirm, the params passed below in your tests are passed to
the JVM that is throwing the exception, right ?
Can you try to comment the filter in
`JDK/conf/management/management.properties` ?
--David
On 21/12/2022 19:25, Rick Hillegas wrote:
Thanks for those pointers, David. I'm afraid that my naive attempts
have failed to circumvent this filtering. All of the following
commands fail with the same "java.io.InvalidClassException: filter
status: REJECTED" error:
java junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest
java -Djdk.serialFilter=* junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest
java -Dcom.sun.management.jmxremote.serial.filter.pattern=*
junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest
Any advice you can give would be appreciated.
-Rick
On 12/21/22 2:27 AM, David Delabassee wrote:
Hi Rick,
There's now a default serialization filter for JMX since 20-EA build
22 (1), see release notes (2) and test (3). To confirm this is
indeed the issue, you can either relax the filter to allow your
target classes to be deserialized, or disable the filter.
(1) https://bugs.openjdk.org/browse/JDK-8283093
(2) https://bugs.openjdk.org/browse/JDK-8295938
(3)
https://urldefense.com/v3/__https://github.com/openjdk/jdk20/commit/628820f47ef9c9ad3cc62e68db9c4dbc7e659154__;!!ACWV5N9M2RV99hQ!NpoMjRUQIuayUbvdDVPAmCP3yMP2w6j3kcsIwQah_EzbUtfJpF6uv2K8AQXJznGfVIVn0pBm3umXdjiqGYyjzdgzGiCc$
Thanks,
--David
On 21/12/2022 02:36, Rick Hillegas wrote:
Hi David,
Open JDK build 20-ea+27-2213 introduces another problem. I see the
following error when unmarshalling an object on behalf of an MBean:
java.io.InvalidClassException: filter status: REJECTED
I do not see this problem under build 19+36-2238.
Can you point me at the experts who can advise me on how to address
this issue?
Thanks,
-Rick
On 12/12/22 2:07 AM, David Delabassee wrote:
Welcome to the final OpenJDK Quality Outreach update for 2022!
JDK 20, scheduled for General Availability on March 21 2023, is
now in Rampdown Phase One (RDP1) [1]. At this point, the overall
JDK 20 [2] feature set is frozen (see below the final list of JEPs
integrated into JDK 20) and only low-risk enhancements might still
be considered. The coming weeks should be used to identify and
resolve as many issues as possible, i.e. before JDK 20 enters the
Release Candidates phase in early February 2023.
## JDK 20 Early-Access builds
The latest Early-Access (builds 27) are available [2] with the
Release Notes here [3]. Those builds are provided under the GNU
GPL v2, with the Classpath Exception.
### JEPs integrated into JDK 20:
JEP 429: Scoped Values (Incubator)
JEP 432: Record Patterns (2nd Preview)
JEP 433: Pattern Matching for switch (4th Preview)
JEP 434: Foreign Function & Memory API (2nd Preview)
JEP 436: Virtual Threads (2nd Preview)
JEP 437: Structured Concurrency (2nd Incubator)
[1]
https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html
[2]
https://urldefense.com/v3/__https://jdk.java.net/20/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTyiVEIUD$
[3]
https://urldefense.com/v3/__https://jdk.java.net/20/release-notes__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTzqxD5c4$
### Changes in recent JDK 20 builds that may be of interest:
Build 27:
- JDK-8297794: Deprecate
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17651455#comment-17651455 ] ASF subversion and git services commented on DERBY-7149: Commit 1906178 from Richard N. Hillegas in branch 'code/trunk' [ https://svn.apache.org/r1906178 ] DERBY-7149: Back out more debug code checked in with revision 1906176. > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17651454#comment-17651454 ] ASF subversion and git services commented on DERBY-7149: Commit 1906177 from Richard N. Hillegas in branch 'code/trunk' [ https://svn.apache.org/r1906177 ] DERBY-7149: Back out debug code checked in by revision 1906176. > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17651447#comment-17651447 ] ASF subversion and git services commented on DERBY-7149: Commit 1906176 from Richard N. Hillegas in branch 'code/trunk' [ https://svn.apache.org/r1906176 ] DERBY-7149: Remove calls to public URL constructors and fix javadoc errors introduced by Open JDK build 20-ea+27-2213; commit derby-7149-01-ac-deprecateURLconstructor.diff. > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
Hi Rick, Just to confirm, the params passed below in your tests are passed to the JVM that is throwing the exception, right ? Can you try to comment the filter in `JDK/conf/management/management.properties` ? --David On 21/12/2022 19:25, Rick Hillegas wrote: Thanks for those pointers, David. I'm afraid that my naive attempts have failed to circumvent this filtering. All of the following commands fail with the same "java.io.InvalidClassException: filter status: REJECTED" error: java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest java -Djdk.serialFilter=* junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest java -Dcom.sun.management.jmxremote.serial.filter.pattern=* junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest Any advice you can give would be appreciated. -Rick On 12/21/22 2:27 AM, David Delabassee wrote: Hi Rick, There's now a default serialization filter for JMX since 20-EA build 22 (1), see release notes (2) and test (3). To confirm this is indeed the issue, you can either relax the filter to allow your target classes to be deserialized, or disable the filter. (1) https://bugs.openjdk.org/browse/JDK-8283093 (2) https://bugs.openjdk.org/browse/JDK-8295938 (3) https://urldefense.com/v3/__https://github.com/openjdk/jdk20/commit/628820f47ef9c9ad3cc62e68db9c4dbc7e659154__;!!ACWV5N9M2RV99hQ!NpoMjRUQIuayUbvdDVPAmCP3yMP2w6j3kcsIwQah_EzbUtfJpF6uv2K8AQXJznGfVIVn0pBm3umXdjiqGYyjzdgzGiCc$ Thanks, --David On 21/12/2022 02:36, Rick Hillegas wrote: Hi David, Open JDK build 20-ea+27-2213 introduces another problem. I see the following error when unmarshalling an object on behalf of an MBean: java.io.InvalidClassException: filter status: REJECTED I do not see this problem under build 19+36-2238. Can you point me at the experts who can advise me on how to address this issue? Thanks, -Rick On 12/12/22 2:07 AM, David Delabassee wrote: Welcome to the final OpenJDK Quality Outreach update for 2022! JDK 20, scheduled for General Availability on March 21 2023, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 20 [2] feature set is frozen (see below the final list of JEPs integrated into JDK 20) and only low-risk enhancements might still be considered. The coming weeks should be used to identify and resolve as many issues as possible, i.e. before JDK 20 enters the Release Candidates phase in early February 2023. ## JDK 20 Early-Access builds The latest Early-Access (builds 27) are available [2] with the Release Notes here [3]. Those builds are provided under the GNU GPL v2, with the Classpath Exception. ### JEPs integrated into JDK 20: JEP 429: Scoped Values (Incubator) JEP 432: Record Patterns (2nd Preview) JEP 433: Pattern Matching for switch (4th Preview) JEP 434: Foreign Function & Memory API (2nd Preview) JEP 436: Virtual Threads (2nd Preview) JEP 437: Structured Concurrency (2nd Incubator) [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html [2] https://urldefense.com/v3/__https://jdk.java.net/20/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTyiVEIUD$ [3] https://urldefense.com/v3/__https://jdk.java.net/20/release-notes__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTzqxD5c4$ ### Changes in recent JDK 20 builds that may be of interest: 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
Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
Thanks for those pointers, David. I'm afraid that my naive attempts have failed to circumvent this filtering. All of the following commands fail with the same "java.io.InvalidClassException: filter status: REJECTED" error: java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest java -Djdk.serialFilter=* junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest java -Dcom.sun.management.jmxremote.serial.filter.pattern=* junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest Any advice you can give would be appreciated. -Rick On 12/21/22 2:27 AM, David Delabassee wrote: Hi Rick, There's now a default serialization filter for JMX since 20-EA build 22 (1), see release notes (2) and test (3). To confirm this is indeed the issue, you can either relax the filter to allow your target classes to be deserialized, or disable the filter. (1) https://bugs.openjdk.org/browse/JDK-8283093 (2) https://bugs.openjdk.org/browse/JDK-8295938 (3) https://github.com/openjdk/jdk20/commit/628820f47ef9c9ad3cc62e68db9c4dbc7e659154 Thanks, --David On 21/12/2022 02:36, Rick Hillegas wrote: Hi David, Open JDK build 20-ea+27-2213 introduces another problem. I see the following error when unmarshalling an object on behalf of an MBean: java.io.InvalidClassException: filter status: REJECTED I do not see this problem under build 19+36-2238. Can you point me at the experts who can advise me on how to address this issue? Thanks, -Rick On 12/12/22 2:07 AM, David Delabassee wrote: Welcome to the final OpenJDK Quality Outreach update for 2022! JDK 20, scheduled for General Availability on March 21 2023, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 20 [2] feature set is frozen (see below the final list of JEPs integrated into JDK 20) and only low-risk enhancements might still be considered. The coming weeks should be used to identify and resolve as many issues as possible, i.e. before JDK 20 enters the Release Candidates phase in early February 2023. ## JDK 20 Early-Access builds The latest Early-Access (builds 27) are available [2] with the Release Notes here [3]. Those builds are provided under the GNU GPL v2, with the Classpath Exception. ### JEPs integrated into JDK 20: JEP 429: Scoped Values (Incubator) JEP 432: Record Patterns (2nd Preview) JEP 433: Pattern Matching for switch (4th Preview) JEP 434: Foreign Function & Memory API (2nd Preview) JEP 436: Virtual Threads (2nd Preview) JEP 437: Structured Concurrency (2nd Incubator) [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html [2] https://urldefense.com/v3/__https://jdk.java.net/20/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTyiVEIUD$ [3] https://urldefense.com/v3/__https://jdk.java.net/20/release-notes__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTzqxD5c4$ ### Changes in recent JDK 20 builds that may be of interest: Build 27: - JDK-8297794: Deprecate JMX Management Applets for Removal - JDK-8297118: Change IncompatibleClassChangeError to MatchException for exhaustive switch statements and switch expressions - JDK-8294047: HttpResponseInputStream swallows interrupts - JDK-8281236: (D)TLS key exchange named groups - JDK-8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification - JDK-8295350: JFR: Add stop methods for recording streams - JDK-8295044: Implementation of Foreign Function and Memory API (2nd Preview) - JDK-8296896: Change virtual Thread.yield to use external submit - JDK-8297804: (tz) Update Timezone Data to 2022g - JDK-8295803: Console should be usable in jshell and other environments - JDK-828: Implementation of Scoped Values (Incubator) - JDK-8296672: Implementation of Virtual Threads (2nd Preview) Build 26: - JDK-8297276: Remove thread text from Subject.current - JDK-8297030: Reduce Default Keep-Alive Timeout Value for httpclient - JDK-8247645: ChaCha20 Intrinsics Build 25: - JDK-8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call - JDK-8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist - JDK-8288717: Add a means to close idle connections in HTTP/2 connection pool - JDK-8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions - JDK-8059632: Method reference compilation uses incorrect qualifying type - JDK-8297161: Add additional Service Attributes to Standard Algorithm Names guide - JDK-8294073: Performance improvement for message digest implementations Build 24: - JDK-8294731: Improve multiplicative inverse for secp256r1 implementation - JDK-8296715: CLDR v42 update for tzdata 2022f - JDK-8296958: [JVMCI] add API for retrieving ConstantValue attributes
Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
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 JDK 20
Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
Hi David, Open JDK build 20-ea+27-2213 introduces another problem. I see the following error when unmarshalling an object on behalf of an MBean: java.io.InvalidClassException: filter status: REJECTED I do not see this problem under build 19+36-2238. Can you point me at the experts who can advise me on how to address this issue? Thanks, -Rick On 12/12/22 2:07 AM, David Delabassee wrote: Welcome to the final OpenJDK Quality Outreach update for 2022! JDK 20, scheduled for General Availability on March 21 2023, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 20 [2] feature set is frozen (see below the final list of JEPs integrated into JDK 20) and only low-risk enhancements might still be considered. The coming weeks should be used to identify and resolve as many issues as possible, i.e. before JDK 20 enters the Release Candidates phase in early February 2023. ## JDK 20 Early-Access builds The latest Early-Access (builds 27) are available [2] with the Release Notes here [3]. Those builds are provided under the GNU GPL v2, with the Classpath Exception. ### JEPs integrated into JDK 20: JEP 429: Scoped Values (Incubator) JEP 432: Record Patterns (2nd Preview) JEP 433: Pattern Matching for switch (4th Preview) JEP 434: Foreign Function & Memory API (2nd Preview) JEP 436: Virtual Threads (2nd Preview) JEP 437: Structured Concurrency (2nd Incubator) [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html [2] https://jdk.java.net/20/ [3] https://jdk.java.net/20/release-notes ### Changes in recent JDK 20 builds that may be of interest: Build 27: - JDK-8297794: Deprecate JMX Management Applets for Removal - JDK-8297118: Change IncompatibleClassChangeError to MatchException for exhaustive switch statements and switch expressions - JDK-8294047: HttpResponseInputStream swallows interrupts - JDK-8281236: (D)TLS key exchange named groups - JDK-8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification - JDK-8295350: JFR: Add stop methods for recording streams - JDK-8295044: Implementation of Foreign Function and Memory API (2nd Preview) - JDK-8296896: Change virtual Thread.yield to use external submit - JDK-8297804: (tz) Update Timezone Data to 2022g - JDK-8295803: Console should be usable in jshell and other environments - JDK-828: Implementation of Scoped Values (Incubator) - JDK-8296672: Implementation of Virtual Threads (2nd Preview) Build 26: - JDK-8297276: Remove thread text from Subject.current - JDK-8297030: Reduce Default Keep-Alive Timeout Value for httpclient - JDK-8247645: ChaCha20 Intrinsics Build 25: - JDK-8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call - JDK-8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist - JDK-8288717: Add a means to close idle connections in HTTP/2 connection pool - JDK-8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions - JDK-8059632: Method reference compilation uses incorrect qualifying type - JDK-8297161: Add additional Service Attributes to Standard Algorithm Names guide - JDK-8294073: Performance improvement for message digest implementations Build 24: - JDK-8294731: Improve multiplicative inverse for secp256r1 implementation - JDK-8296715: CLDR v42 update for tzdata 2022f - JDK-8296958: [JVMCI] add API for retrieving ConstantValue attributes Build 23: - JDK-8296226: Add constructors (String,Throwable) and (Throwable) to InvalidParameterException - JDK-8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders - JDK-8294241: Deprecate URL public constructors - JDK-8289689: (fs) Re-examine the need for normalization to Unicode Normalization Format D (macOS) - JDK-8279164: Disable TLS_ECDH_* cipher suites - JDK-8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V) - JDK-8296108: (tz) Update Timezone Data to 2022f ## Heads-up - JDK 21: First Early-Access Builds When JDK 20 entered RDP1 [4], the JDK mainline [5] was (a) forked into a JDK 20 stabilization repository [6], and (b) set to JDK 21. As a consequence, the first JDK 21 Early-Access builds have been published [7]. [4] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html [5] https://github.com/openjdk/jdk [6] https://github.com/openjdk/jdk20 [7] https://jdk.java.net/21/ ## Heads-up - Valhalla: LW4 Early-Access Builds Valhalla LW4 early-access builds have been published [8], those builds are primarily focused on implementing the Value Objects JEP draft [9]. For additional details on those EA builds, make sure to read these LW4 release notes [10]. For a more hands-on introduction to Value Object, you can watch the latest JEP Café: Java Value Objects in Action [11]. Interested developers are encouraged to explore the performance and migration
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[
https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17650044#comment-17650044
]
Richard N. Hillegas commented on DERBY-7149:
Attaching derby-7149-01-ac-deprecateURLconstructor.diff. This patch addresses
the following issues encountered when building and testing with Open JDK build
20-ea+27-2213:
1) The deprecation of public URL constructors (JDK-8294241).
2) New javadoc warnings.
I fixed the URL-related test problems in the previous patch by adding catch
blocks for IllegalArgumentException. Oddly enough, the 0-arg method URI.toURL()
raises that exception.
I backed out changes related to the deprecation (with intent to remove) of the
java.lang.ThreadDeath class. That, in turn, relates to the deprecation (with
intent to remove) of the Thread.stop() method. I need to ask the experts about
how we should handle the disappearance of Thread.stop().
Tests passed cleanly with this patch with both the classpath and the module
path except for the problems seen in CacheManagerMBeanTest.
Touches the following files:
{noformat}
M
java/build/org/apache/derbyBuild/lastgoodjarcontents/insane.derbyTesting.jar.lastcontents
M
java/build/org/apache/derbyBuild/lastgoodjarcontents/sane.derbyTesting.jar.lastcontents
A
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/harness/jdk120.java
Added a new JVM testing type to represent JDK 20.
M java/build/org/apache/derbyBuild/JiraConnector.java
M java/build/org/apache/derbyBuild/ReleaseNotesGenerator.java
M
java/org.apache.derby.engine/org/apache/derby/iapi/services/io/FileUtil.java
M java/org.apache.derby.engine/org/apache/derby/impl/io/URLFile.java
M
java/org.apache.derby.engine/org/apache/derby/impl/load/ImportReadData.java
M
java/org.apache.derby.engine/org/apache/derby/impl/sql/execute/JarUtil.java
M
java/org.apache.derby.engine/org/apache/derby/impl/store/raw/RawStore.java
M
java/org.apache.derby.engine/org/apache/derby/impl/store/raw/log/LogToFile.java
M java/org.apache.derby.engine/org/apache/derby/vti/XmlVTI.java
M
java/org.apache.derby.optionaltools/org/apache/derby/optional/api/SimpleJsonUtils.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/CallableTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeClassLoader.java
M
java/org.apache.derby.tools/org/apache/derby/impl/tools/sysinfo/Main.java
Changes for (1).
M
java/org.apache.derby.engine/org/apache/derby/iapi/jdbc/InternalDriver.java
M
java/org.apache.derby.engine/org/apache/derby/iapi/security/SecurityUtil.java
M
java/org.apache.derby.engine/org/apache/derby/impl/jdbc/InternalClob.java
M
java/org.apache.derby.engine/org/apache/derby/impl/jdbc/LOBStoredProcedure.java
M
java/org.apache.derby.engine/org/apache/derby/impl/sql/compile/GroupByNode.java
M
java/org.apache.derby.engine/org/apache/derby/impl/sql/compile/UpdateNode.java
M
java/org.apache.derby.engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj
M
java/org.apache.derby.engine/org/apache/derby/impl/sql/execute/GroupedAggregateResultSet.java
M
java/org.apache.derby.engine/org/apache/derby/impl/sql/execute/RowTriggerExecutor.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbc4/Derby3650Test.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbc4/ResultSetTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/BLOBDataModelSetup.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/BlobClob4BlobTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/BlobStoredProcedureTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/ClobStoredProcedureTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/DataSourceReferenceTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/StatementPoolingTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/management/JDBCMBeanTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/managemen/NetworkServerMBeanTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/management/VersionMBeanTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/store/BaseTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/store/OnlineCompressTest.java
M
[jira] [Updated] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas updated DERBY-7149: --- Attachment: derby-7149-01-ac-deprecateURLconstructor.diff > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff, > derby-7149-01-ac-deprecateURLconstructor.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[
https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17650037#comment-17650037
]
Richard N. Hillegas commented on DERBY-7149:
Open JDK build 20-ea+27-2213 introduces another problem. It breaks
CacheManagerMBeanTest. The test runs cleanly on Open JDK build 19+36-2238. But
the test fails with the following two errors on build 20-ea+27-2213:
{noformat}
...E.E
Time: 19.671
There were 2 errors:
1)
testPageCache(org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest)java.io.InvalidClassException:
filter status: REJECTED
at
java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1437)
at
java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2069)
at
java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1925)
at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2248)
at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1760)
at
java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:538)
at
java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:496)
at java.rmi/java.rmi.MarshalledObject.get(MarshalledObject.java:183)
at
java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.unwrap(RMIConnectionImpl.java:1590)
at
java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.unwrap(RMIConnectionImpl.java:1632)
at
java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.setAttribute(RMIConnectionImpl.java:709)
at
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at
java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:360)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:714)
at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:598)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:844)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:721)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:720)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1623)
at
java.rmi/sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:304)
at
java.rmi/sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:280)
at java.rmi/sun.rmi.server.UnicastRef.invoke(UnicastRef.java:166)
at jdk.remoteref/jdk.jmx.remote.internal.rmi.PRef.invoke(Unknown Source)
at
java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl_Stub.setAttribute(RMIConnectionImpl_Stub.java:556)
at
java.management.rmi/javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.setAttribute(RMIConnector.java:960)
at
org.apache.derbyTesting.functionTests.tests.management.MBeanTest.setAttribute(MBeanTest.java:352)
at
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest.testPageCache(CacheManagerMBeanTest.java:171)
at
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:104)
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:440)
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:457)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:45)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:45)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at
Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
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 ## Heads-up -
Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
Thanks for the heads-up, David. I see many deprecation warnings and javadoc warnings when I build Derby with Open JDK build 20-ea+27-2213. Right now, I am trying to track down a fix for the problems introduced by this change: - JDK-8294241: Deprecate URL public constructors My naive attempt to workaround this deprecation was to replace instances of new URL(urlString) with (new URI(urlString)).toURL() Unfortunately, this breaks Derby. I see errors like the following: java.lang.IllegalArgumentException: URI is not absolute at java.base/java.net.URL.of(URL.java:854) at java.base/java.net.URI.toURL(URI.java:1144) at org.apache.derby.impl.store.raw.RawStore.backup(RawStore.java:641) Can you point me at an expert who can advise me on best practices for working around this deprecation? Thanks, -Rick On 12/12/22 2:07 AM, David Delabassee wrote: Welcome to the final OpenJDK Quality Outreach update for 2022! JDK 20, scheduled for General Availability on March 21 2023, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 20 [2] feature set is frozen (see below the final list of JEPs integrated into JDK 20) and only low-risk enhancements might still be considered. The coming weeks should be used to identify and resolve as many issues as possible, i.e. before JDK 20 enters the Release Candidates phase in early February 2023. ## JDK 20 Early-Access builds The latest Early-Access (builds 27) are available [2] with the Release Notes here [3]. Those builds are provided under the GNU GPL v2, with the Classpath Exception. ### JEPs integrated into JDK 20: JEP 429: Scoped Values (Incubator) JEP 432: Record Patterns (2nd Preview) JEP 433: Pattern Matching for switch (4th Preview) JEP 434: Foreign Function & Memory API (2nd Preview) JEP 436: Virtual Threads (2nd Preview) JEP 437: Structured Concurrency (2nd Incubator) [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html [2] https://jdk.java.net/20/ [3] https://jdk.java.net/20/release-notes ### Changes in recent JDK 20 builds that may be of interest: Build 27: - JDK-8297794: Deprecate JMX Management Applets for Removal - JDK-8297118: Change IncompatibleClassChangeError to MatchException for exhaustive switch statements and switch expressions - JDK-8294047: HttpResponseInputStream swallows interrupts - JDK-8281236: (D)TLS key exchange named groups - JDK-8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification - JDK-8295350: JFR: Add stop methods for recording streams - JDK-8295044: Implementation of Foreign Function and Memory API (2nd Preview) - JDK-8296896: Change virtual Thread.yield to use external submit - JDK-8297804: (tz) Update Timezone Data to 2022g - JDK-8295803: Console should be usable in jshell and other environments - JDK-828: Implementation of Scoped Values (Incubator) - JDK-8296672: Implementation of Virtual Threads (2nd Preview) Build 26: - JDK-8297276: Remove thread text from Subject.current - JDK-8297030: Reduce Default Keep-Alive Timeout Value for httpclient - JDK-8247645: ChaCha20 Intrinsics Build 25: - JDK-8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call - JDK-8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist - JDK-8288717: Add a means to close idle connections in HTTP/2 connection pool - JDK-8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions - JDK-8059632: Method reference compilation uses incorrect qualifying type - JDK-8297161: Add additional Service Attributes to Standard Algorithm Names guide - JDK-8294073: Performance improvement for message digest implementations Build 24: - JDK-8294731: Improve multiplicative inverse for secp256r1 implementation - JDK-8296715: CLDR v42 update for tzdata 2022f - JDK-8296958: [JVMCI] add API for retrieving ConstantValue attributes Build 23: - JDK-8296226: Add constructors (String,Throwable) and (Throwable) to InvalidParameterException - JDK-8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders - JDK-8294241: Deprecate URL public constructors - JDK-8289689: (fs) Re-examine the need for normalization to Unicode Normalization Format D (macOS) - JDK-8279164: Disable TLS_ECDH_* cipher suites - JDK-8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V) - JDK-8296108: (tz) Update Timezone Data to 2022f ## Heads-up - JDK 21: First Early-Access Builds When JDK 20 entered RDP1 [4], the JDK mainline [5] was (a) forked into a JDK 20 stabilization repository [6], and (b) set to JDK 21. As a consequence, the first JDK 21 Early-Access builds have been published [7]. [4] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html [5] https://github.com/openjdk/jdk [6] https://github.com/openjdk/jdk20 [7] https://jdk.java.net/21/ ## Heads-up -
[jira] [Updated] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas updated DERBY-7149: --- Attachment: derby-7149-01-aa-deprecateURLconstructor.diff > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7149-01-aa-deprecateURLconstructor.diff > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[
https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17647734#comment-17647734
]
Richard N. Hillegas commented on DERBY-7149:
Attaching derby-7149-01-aa-deprecateURLconstructor.diff. This patch attempts to
fix code and javadoc warnings introduced by Open JDK build 20-ea+27-2213.
Unfortunately, many tests fail. One of the issues which the patch addresses is
the deprecation of URL constructors by
https://bugs.openjdk.org/browse/JDK-8294241. My naive attempt to work around
this was to replace
{noformat}
new URL(urlString)
{noformat}
with
{noformat}
(new URI(urlString)).toURL();
{noformat}
Here is the error I see when I run the old harness RecoveryAfterBackup test:
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)
I will ask the Java team for advice about how to workaround this deprecation in
applications which rely on relative URIs.
Touches the following files:
{noformat}
M java/build/org/apache/derbyBuild/JiraConnector.java
M java/build/org/apache/derbyBuild/ReleaseNotesGenerator.java
M
java/build/org/apache/derbyBuild/lastgoodjarcontents/insane.derbyTesting.jar.lastcontents
M
java/build/org/apache/derbyBuild/lastgoodjarcontents/sane.derbyTesting.jar.lastcontents
M
java/org.apache.derby.engine/org/apache/derby/iapi/jdbc/InternalDriver.java
M
java/org.apache.derby.engine/org/apache/derby/iapi/security/SecurityUtil.java
M
java/org.apache.derby.engine/org/apache/derby/iapi/services/context/ContextManager.java
M
java/org.apache.derby.engine/org/apache/derby/iapi/services/context/SystemContext.java
M
java/org.apache.derby.engine/org/apache/derby/iapi/services/io/FileUtil.java
M java/org.apache.derby.engine/org/apache/derby/impl/io/URLFile.java
M
java/org.apache.derby.engine/org/apache/derby/impl/jdbc/InternalClob.java
M
java/org.apache.derby.engine/org/apache/derby/impl/jdbc/LOBStoredProcedure.java
M
java/org.apache.derby.engine/org/apache/derby/impl/load/ImportReadData.java
M
java/org.apache.derby.engine/org/apache/derby/impl/services/monitor/BaseMonitor.java
M
java/org.apache.derby.engine/org/apache/derby/impl/sql/compile/GroupByNode.java
M
java/org.apache.derby.engine/org/apache/derby/impl/sql/compile/UpdateNode.java
M
java/org.apache.derby.engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj
M
java/org.apache.derby.engine/org/apache/derby/impl/sql/execute/GroupedAggregateResultSet.java
M
java/org.apache.derby.engine/org/apache/derby/impl/sql/execute/JarUtil.java
M
java/org.apache.derby.engine/org/apache/derby/impl/sql/execute/RowTriggerExecutor.java
M
java/org.apache.derby.engine/org/apache/derby/impl/store/raw/RawStore.java
M
java/org.apache.derby.engine/org/apache/derby/impl/store/raw/log/LogToFile.java
M java/org.apache.derby.engine/org/apache/derby/vti/XmlVTI.java
M
java/org.apache.derby.optionaltools/org/apache/derby/optional/api/SimpleJsonUtils.java
A
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/harness/jdk120.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbc4/Derby3650Test.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbc4/ResultSetTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/BLOBDataModelSetup.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/BlobClob4BlobTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/BlobStoredProcedureTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/CallableTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/ClobStoredProcedureTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/DataSourceReferenceTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/StatementPoolingTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/management/JDBCMBeanTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/management/NetworkServerMBeanTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/management/VersionMBeanTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/store/BaseTest.java
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/store/OnlineCompressTest.java
M
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[
https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646349#comment-17646349
]
Richard N. Hillegas commented on DERBY-7149:
And I see the following new warnings when I build the javadoc with Open JDK
build 20-ea+27-2213:
{noformat}
[javadoc]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/store/BaseTest.java:369:
warning: cannot find exception type by name
[javadoc] * @exception StandardException Standard exception policy.
[javadoc]^
[javadoc]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/BlobClob4BlobTest.java:3073:
warning: cannot find exception type by name
[javadoc] * @throws FileNotFoundException
[javadoc]^
[javadoc]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/BLOBDataModelSetup.java:104:
warning: cannot find exception type by name
[javadoc] * @exception Exceptions causes the test to fail with error
[javadoc] ^
[javadoc]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/BlobStoredProcedureTest.java:71:
warning: cannot find exception type by name
[javadoc] * @throws a SQLException.
[javadoc]^
[javadoc]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/BlobStoredProcedureTest.java:116:
warning: cannot find exception type by name
[javadoc] * @throws a SQLException.
[javadoc]^
[javadoc]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/ClobStoredProcedureTest.java:64:
warning: cannot find exception type by name
[javadoc] * @throws a SQLException.
[javadoc]^
[javadoc]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/ClobStoredProcedureTest.java:95:
warning: cannot find exception type by name
[javadoc] * @throws an SQLException.
[javadoc]^
[javadoc]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/DataSourceReferenceTest.java:403:
warning: cannot find exception type by name
[javadoc] * @throws AssertionFailedError if the data sources are not
equal
[javadoc]^
[javadoc]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/DataSourceReferenceTest.java:626:
warning: cannot find exception type by name
[javadoc] * @throws AssertionFailedError if the property name is not
defined by
[javadoc]^
[javadoc]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/DataSourceReferenceTest.java:646:
warning: cannot find exception type by name
[javadoc] * @throws AssertionFailedError if the property name is not
defined by
[javadoc]^
[javadoc]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbc4/Derby3650Test.java:97:
warning: cannot find exception type by name
[javadoc] * @exception StandardException Standard exception policy.
[javadoc]^
[javadoc]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbc4/Derby3650Test.java:126:
warning: cannot find exception type by name
[javadoc] * @exception StandardException Standard exception policy.
[javadoc]^
[javadoc]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbc4/Derby3650Test.java:194:
warning: cannot find exception type by name
[javadoc] * @exception StandardException Standard exception policy.
[javadoc]^
[javadoc]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbc4/Derby3650Test.java:221:
warning: cannot find exception type by name
[javadoc] * @exception StandardException Standard exception policy.
[javadoc]^
[javadoc]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/store/dropcrash.java:130:
warning: cannot find exception type by name
[javadoc] * @exception StandardException Standard exception policy.
[javadoc]^
[javadoc]
[jira] [Commented] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[
https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646293#comment-17646293
]
Richard N. Hillegas commented on DERBY-7149:
I see the following new warnings when I build Derby with Open JDK build
20-ea+27-2213:
{noformat}
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use or override a deprecated API that is
marked for removal.
[javac] Note: Recompile with -Xlint:removal for details.
[javac]
/Users/rhillegas/derby/mainline/trunk/java/build/org/apache/derbyBuild/JiraConnector.java:117:
warning: [deprecation] URL(String) in URL has been deprecated
[javac] URL url= new URL(XMLurl);
[javac] ^
[javac]
/Users/rhillegas/derby/mainline/trunk/java/build/org/apache/derbyBuild/ReleaseNotesGenerator.java:386:
warning: [deprecation] URL(String) in URL has been deprecated
[javac] URL url = new
URL(issue.getReleaseNoteAddress());
[javac] ^
[javac] 2 warnings
[javac]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tools/org/apache/derby/impl/tools/ij/mtTester.java:107:
warning: [removal] ThreadDeath in java.lang has been deprecated and marked for
removal
[javac] throw new ThreadDeath();
[javac] ^
[javac]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tools/org/apache/derby/impl/tools/sysinfo/Main.java:571:
warning: [deprecation] URL(String) in URL has been deprecated
[javac] testJarURL = new URL(successString);
[javac]^
[javac] 2 warnings
[javac]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.optionaltools/org/apache/derby/optional/api/SimpleJsonUtils.java:254:
warning: [deprecation] URL(String) in URL has been deprecated
[javac] URL url = new URL( url_string );
[javac] ^
[javac] 1 warning
[javac]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/CallableTest.java:1159:
warning: [deprecation] URL(String) in URL has been deprecated
[javac] URL domain = new URL("http://www.apache.org;);
[javac] ^
[javac]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeClassLoader.java:173:
warning: [deprecation] URL(String) in URL has been deprecated
[javac] url[i] = new URL(oldURLJarLocation + "/" +
jarFiles[i]);
[javac] ^
[javac]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/unitTests/harness/BasicUnitTestManager.java:185:
warning: [removal] ThreadDeath in java.lang has been deprecated and marked for
removal
[javac] if (t instanceof ThreadDeath)
[javac] ^
[javac]
/Users/rhillegas/derby/mainline/trunk/java/org.apache.derby.tests/org/apache/derbyTesting/unitTests/harness/T_MultiThreadedIterations.java:194:
warning: [removal] ThreadDeath in java.lang has been deprecated and marked for
removal
[javac] catch (ThreadDeath death) // some other thread has died
and want to see my stack
[javac]^
[javac] 4 warnings
{noformat}
> Make it possible to build and test Derby cleanly with JDK 20
>
>
> Key: DERBY-7149
> URL: https://issues.apache.org/jira/browse/DERBY-7149
> Project: Derby
> Issue Type: Task
> Components: Build tools
>Affects Versions: 10.17.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
Richard N. Hillegas created DERBY-7149: -- Summary: Make it possible to build and test Derby cleanly with JDK 20 Key: DERBY-7149 URL: https://issues.apache.org/jira/browse/DERBY-7149 Project: Derby Issue Type: Task Components: Build tools Affects Versions: 10.17.0.0 Reporter: Richard N. Hillegas -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (DERBY-7149) Make it possible to build and test Derby cleanly with JDK 20
[ https://issues.apache.org/jira/browse/DERBY-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas reassigned DERBY-7149: -- Assignee: Richard N. Hillegas > Make it possible to build and test Derby cleanly with JDK 20 > > > Key: DERBY-7149 > URL: https://issues.apache.org/jira/browse/DERBY-7149 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.17.0.0 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas closed DERBY-7147. -- > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Fix For: 10.14.3, 10.15.2.1, 10.16.1.2, 10.17.0.0 > > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar, > derby-7147-03-ab-updateLDAPinstructions.diff, > derby-7147-03-ab-updateLDAPinstructions.tar, > derby-7147-04-aa-pointLDAPTestAtInstructions.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas resolved DERBY-7147. Fix Version/s: 10.14.3 10.15.2.1 10.16.1.2 10.17.0.0 Resolution: Fixed > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Fix For: 10.14.3, 10.15.2.1, 10.16.1.2, 10.17.0.0 > > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar, > derby-7147-03-ab-updateLDAPinstructions.diff, > derby-7147-03-ab-updateLDAPinstructions.tar, > derby-7147-04-aa-pointLDAPTestAtInstructions.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
Welcome to the final OpenJDK Quality Outreach update for 2022! JDK 20, scheduled for General Availability on March 21 2023, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 20 [2] feature set is frozen (see below the final list of JEPs integrated into JDK 20) and only low-risk enhancements might still be considered. The coming weeks should be used to identify and resolve as many issues as possible, i.e. before JDK 20 enters the Release Candidates phase in early February 2023. ## JDK 20 Early-Access builds The latest Early-Access (builds 27) are available [2] with the Release Notes here [3]. Those builds are provided under the GNU GPL v2, with the Classpath Exception. ### JEPs integrated into JDK 20: JEP 429: Scoped Values (Incubator) JEP 432: Record Patterns (2nd Preview) JEP 433: Pattern Matching for switch (4th Preview) JEP 434: Foreign Function & Memory API (2nd Preview) JEP 436: Virtual Threads (2nd Preview) JEP 437: Structured Concurrency (2nd Incubator) [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html [2] https://jdk.java.net/20/ [3] https://jdk.java.net/20/release-notes ### Changes in recent JDK 20 builds that may be of interest: Build 27: - JDK-8297794: Deprecate JMX Management Applets for Removal - JDK-8297118: Change IncompatibleClassChangeError to MatchException for exhaustive switch statements and switch expressions - JDK-8294047: HttpResponseInputStream swallows interrupts - JDK-8281236: (D)TLS key exchange named groups - JDK-8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification - JDK-8295350: JFR: Add stop methods for recording streams - JDK-8295044: Implementation of Foreign Function and Memory API (2nd Preview) - JDK-8296896: Change virtual Thread.yield to use external submit - JDK-8297804: (tz) Update Timezone Data to 2022g - JDK-8295803: Console should be usable in jshell and other environments - JDK-828: Implementation of Scoped Values (Incubator) - JDK-8296672: Implementation of Virtual Threads (2nd Preview) Build 26: - JDK-8297276: Remove thread text from Subject.current - JDK-8297030: Reduce Default Keep-Alive Timeout Value for httpclient - JDK-8247645: ChaCha20 Intrinsics Build 25: - JDK-8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call - JDK-8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist - JDK-8288717: Add a means to close idle connections in HTTP/2 connection pool - JDK-8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions - JDK-8059632: Method reference compilation uses incorrect qualifying type - JDK-8297161: Add additional Service Attributes to Standard Algorithm Names guide - JDK-8294073: Performance improvement for message digest implementations Build 24: - JDK-8294731: Improve multiplicative inverse for secp256r1 implementation - JDK-8296715: CLDR v42 update for tzdata 2022f - JDK-8296958: [JVMCI] add API for retrieving ConstantValue attributes Build 23: - JDK-8296226: Add constructors (String,Throwable) and (Throwable) to InvalidParameterException - JDK-8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders - JDK-8294241: Deprecate URL public constructors - JDK-8289689: (fs) Re-examine the need for normalization to Unicode Normalization Format D (macOS) - JDK-8279164: Disable TLS_ECDH_* cipher suites - JDK-8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V) - JDK-8296108: (tz) Update Timezone Data to 2022f ## Heads-up - JDK 21: First Early-Access Builds When JDK 20 entered RDP1 [4], the JDK mainline [5] was (a) forked into a JDK 20 stabilization repository [6], and (b) set to JDK 21. As a consequence, the first JDK 21 Early-Access builds have been published [7]. [4] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html [5] https://github.com/openjdk/jdk [6] https://github.com/openjdk/jdk20 [7] https://jdk.java.net/21/ ## Heads-up - Valhalla: LW4 Early-Access Builds Valhalla LW4 early-access builds have been published [8], those builds are primarily focused on implementing the Value Objects JEP draft [9]. For additional details on those EA builds, make sure to read these LW4 release notes [10]. For a more hands-on introduction to Value Object, you can watch the latest JEP Café: Java Value Objects in Action [11]. Interested developers are encouraged to explore the performance and migration impact of value objects on their applications, and to provide feedback to the valhalla-dev [12] mailing list. [8] https://jdk.java.net/valhalla/ [9] https://openjdk.org/jeps/8277163 [10] https://openjdk.org/projects/valhalla/early-access [11] https://inside.java/2022/12/06/jepcafe15/ [12] https://mail.openjdk.org/pipermail/valhalla-dev/ ## Heads-up - Generational ZGC: New Early-Access Builds New
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17645003#comment-17645003 ] Richard N. Hillegas commented on DERBY-7147: I'm done with the work I plan to do on this issue. We could work on a 10.16.2 release to publish the fix. But producing a release is a considerable amount of work. In addition, year end is an awkward time to ask the community to vet a new release. Maybe it makes sense to sweep up more fixes first and publish a release in the spring. I don't have a sense of how many Derby installations rely on LDAP. Without an exploit, it's hard to gauge the severity of this bug. The only exploit I can imagine is someone logging onto an LDAP-protected Derby installation with a very strange name, which no one would choose for a real user. I do not see a privacy or data corruption attack if GRANT/REVOKE authorization is turned on. But the fake user would have the ability to create databases and tables. That is, resource-exhaustion and denial-of-service attacks might be possible. What are your thoughts? > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar, > derby-7147-03-ab-updateLDAPinstructions.diff, > derby-7147-03-ab-updateLDAPinstructions.tar, > derby-7147-04-aa-pointLDAPTestAtInstructions.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644419#comment-17644419 ] ASF subversion and git services commented on DERBY-7147: Commit 1905843 from Richard N. Hillegas in branch 'code/trunk' [ https://svn.apache.org/r1905843 ] DERBY-7147: Add comment to LDAPAuthenticationTest, pointing to this issue for instructions on how to run the test; commit derby-7147-04-aa-pointLDAPTestAtInstructions.diff. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar, > derby-7147-03-ab-updateLDAPinstructions.diff, > derby-7147-03-ab-updateLDAPinstructions.tar, > derby-7147-04-aa-pointLDAPTestAtInstructions.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[
https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644418#comment-17644418
]
Richard N. Hillegas commented on DERBY-7147:
Attaching derby-7147-04-aa-pointLDAPTestAtInstructions.diff. This patch adds a
sentence to the header comment on LDAPAuthenticationTest, advising the reader
to consult DERBY-7147 for modern instructions on how to run the test.
Touches the following file:
{noformat}
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbcapi/LDAPAuthenticationTest.java
{noformat}
> LDAP injection vulnerability in LDAPAuthenticationImpl
> --
>
> Key: DERBY-7147
> URL: https://issues.apache.org/jira/browse/DERBY-7147
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.16.1.1
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7147-01-aa-reformatForReadability.diff,
> derby-7147-02-aa-escapeLDAPsearchFilter.diff,
> derby-7147-02-ab-escapeLDAPsearchFilter.diff,
> derby-7147-03-aa-updateLDAPinstructions.diff,
> derby-7147-03-aa-updateLDAPinstructions.tar,
> derby-7147-03-ab-updateLDAPinstructions.diff,
> derby-7147-03-ab-updateLDAPinstructions.tar,
> derby-7147-04-aa-pointLDAPTestAtInstructions.diff
>
>
> An LDAP injection vulnerability has been identified in
> LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been
> provided, but there is a possibility that an intruder could bypass
> authentication checks in Derby-powered applications which rely on external
> LDAP servers.
> For more information on LDAP injection, see
> https://www.synopsys.com/glossary/what-is-ldap-injection.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas updated DERBY-7147: --- Attachment: derby-7147-04-aa-pointLDAPTestAtInstructions.diff > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar, > derby-7147-03-ab-updateLDAPinstructions.diff, > derby-7147-03-ab-updateLDAPinstructions.tar, > derby-7147-04-aa-pointLDAPTestAtInstructions.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644408#comment-17644408 ] ASF subversion and git services commented on DERBY-7147: Commit 1905842 from Richard N. Hillegas in branch 'docs/branches/10.16' [ https://svn.apache.org/r1905842 ] DERBY-7147: Port 1905800 from trunk docs to 10.16 docs. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar, > derby-7147-03-ab-updateLDAPinstructions.diff, > derby-7147-03-ab-updateLDAPinstructions.tar > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17643970#comment-17643970 ] ASF subversion and git services commented on DERBY-7147: Commit 1905800 from Richard N. Hillegas in branch 'docs/trunk' [ https://svn.apache.org/r1905800 ] DERBY-7147: Modernize documentation on LDAP authentication, eliminating dead links; commit derby-7147-03-ab-updateLDAPinstructions.diff. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar, > derby-7147-03-ab-updateLDAPinstructions.diff, > derby-7147-03-ab-updateLDAPinstructions.tar > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17643043#comment-17643043 ] Richard N. Hillegas commented on DERBY-7147: I think that the LDAP provider should take responsibility for supplying full instructions for secure configuration. Anyone who really wants to integrate Derby into an LDAP environment will already have a secure LDAP server up and running. I don't think that Derby should get too far into the weeds here. I recommend committing this patch, maybe with some nod to the complexity of ldaps. The ldap protocol is good enough for LDAPAuthenticationTest. We could improve the header comment on LDAPAuthenticationTest so that it reflects your experience configuring a run with ldap. I may have over-rotated on this issue already. We never field LDAP questions on our mailing lists. -Rick > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar, > derby-7147-03-ab-updateLDAPinstructions.diff, > derby-7147-03-ab-updateLDAPinstructions.tar > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642921#comment-17642921 ] Bryan Pendleton commented on DERBY-7147: Perhaps we can proceed with what we have now, and in a separate Jira we could log the enhancement to have our documentation provide thorough details about how to integrate Derby with LDAP using ldaps: protocol. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar, > derby-7147-03-ab-updateLDAPinstructions.diff, > derby-7147-03-ab-updateLDAPinstructions.tar > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642879#comment-17642879 ] Bryan Pendleton commented on DERBY-7147: Actually, I think I did my ldaps test incorrectly. Configuring ldaps works, but it is a lot more complex (see [https://directory.apache.org/apacheds/basic-ug/3.3-enabling-ssl.html#other-clients-java-programs-using-jndi)] for all the details. Derby has to have the right keystore to trust the self-signed certificate supplied by ApacheDS. Do you think this is important for us to document? If so, we'll probably need a fair bit more documentation to work out the specifics. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar, > derby-7147-03-ab-updateLDAPinstructions.diff, > derby-7147-03-ab-updateLDAPinstructions.tar > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[
https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642863#comment-17642863
]
Richard N. Hillegas commented on DERBY-7147:
Thanks for that feedback, Bryan. Attaching
derby-7147-03-ab-updateLDAPinstructions.diff and a corresponding tarball of
generated output. This patch improves the wording of the boot instructions, as
you recommended. Thanks for verifying that the ldaps protocol works.
I will commit this patch in a couple days if there are no more comments.
Touches the same files:
{noformat}
M src/security/cseccsecure863446.dita
Changes to the "Setting up Derby to use your LDAP directory service" section.
M src/security/csecldapbooting.dita
Changes to the "Booting an LDAP server" section.
{noformat}
> LDAP injection vulnerability in LDAPAuthenticationImpl
> --
>
> Key: DERBY-7147
> URL: https://issues.apache.org/jira/browse/DERBY-7147
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.16.1.1
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7147-01-aa-reformatForReadability.diff,
> derby-7147-02-aa-escapeLDAPsearchFilter.diff,
> derby-7147-02-ab-escapeLDAPsearchFilter.diff,
> derby-7147-03-aa-updateLDAPinstructions.diff,
> derby-7147-03-aa-updateLDAPinstructions.tar,
> derby-7147-03-ab-updateLDAPinstructions.diff,
> derby-7147-03-ab-updateLDAPinstructions.tar
>
>
> An LDAP injection vulnerability has been identified in
> LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been
> provided, but there is a possibility that an intruder could bypass
> authentication checks in Derby-powered applications which rely on external
> LDAP servers.
> For more information on LDAP injection, see
> https://www.synopsys.com/glossary/what-is-ldap-injection.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas updated DERBY-7147: --- Attachment: derby-7147-03-ab-updateLDAPinstructions.diff > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar, > derby-7147-03-ab-updateLDAPinstructions.diff, > derby-7147-03-ab-updateLDAPinstructions.tar > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas updated DERBY-7147: --- Attachment: derby-7147-03-ab-updateLDAPinstructions.tar > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar, > derby-7147-03-ab-updateLDAPinstructions.tar > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17642851#comment-17642851 ] Bryan Pendleton commented on DERBY-7147: Those documentation updates seem like good improvements to me. For csecldapbooting.dita, you could possibly change 'Boot ApacheDS via the following command' to something like 'Boot ApacheDS. On Linux, for example, run the following command' since I believe the precise instructions vary by platform. The 'ldaps' worked fine for me in my toy example, and I have no reason to believe it wouldn't work else. I unfortunately have no input on your much harder second question. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[
https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17640966#comment-17640966
]
Richard N. Hillegas commented on DERBY-7147:
Attaching derby-7147-03-aa-updateLDAPinstructions.diff and a corresponding
tarball of generated output. This patch updates the security guide based on
Bryan's experience. I would appreciate your feedback. It would be helpful if
you could test-drive these instructions to make sure that I haven't garbled
anything.
In particular, I am concerned about the following points in the "Setting up
Derby to use your LDAP directory service" section:
1) For the derby.authentication.server setting, I changed the protocol from
ldap to ldaps. I hope that still works. I removed the line about ldap in the
last paragraph because I don't think that we should even mention an insecure
protocol.
2) The list of properties in "Setting up Derby to use your LDAP directory
service" includes some properties which Bryan's summary doesn't mention:
derby.authentication.ldap.searchAuthPW, derby.authentication.ldap.searchAuthDN,
and derby.authentication.ldap.searchFilter. Are these still needed? If so, is
the example still correct?
Touches the following files:
{noformat}
M src/security/cseccsecure863446.dita
Changes to the "Setting up Derby to use your LDAP directory service" section.
M src/security/csecldapbooting.dita
Changes to the "Booting an LDAP server" section.
{noformat}
> LDAP injection vulnerability in LDAPAuthenticationImpl
> --
>
> Key: DERBY-7147
> URL: https://issues.apache.org/jira/browse/DERBY-7147
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.16.1.1
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7147-01-aa-reformatForReadability.diff,
> derby-7147-02-aa-escapeLDAPsearchFilter.diff,
> derby-7147-02-ab-escapeLDAPsearchFilter.diff,
> derby-7147-03-aa-updateLDAPinstructions.diff,
> derby-7147-03-aa-updateLDAPinstructions.tar
>
>
> An LDAP injection vulnerability has been identified in
> LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been
> provided, but there is a possibility that an intruder could bypass
> authentication checks in Derby-powered applications which rely on external
> LDAP servers.
> For more information on LDAP injection, see
> https://www.synopsys.com/glossary/what-is-ldap-injection.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas updated DERBY-7147: --- Attachment: derby-7147-03-aa-updateLDAPinstructions.diff > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard N. Hillegas updated DERBY-7147: --- Attachment: derby-7147-03-aa-updateLDAPinstructions.tar > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff, > derby-7147-03-aa-updateLDAPinstructions.diff, > derby-7147-03-aa-updateLDAPinstructions.tar > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17640774#comment-17640774 ] Richard N. Hillegas commented on DERBY-7147: I think that we need to update the security guide to reflect your experience in configuring and booting an LDAP server. Might be a minor change. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17640706#comment-17640706 ] Bryan Pendleton commented on DERBY-7147: Fine with me to make just a 10.16.2 release. What in particular did you have in mind for documentation changes? Just a release note, or do you think that the actual documentation is inaccurate w.r.t. these topics? > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17640294#comment-17640294 ] Richard N. Hillegas commented on DERBY-7147: At a minimum, I think that we need to publish this fix in a 10.16.2 release. If we stop there, then users will need to upgrade to Java 17 in order to get the fix. When they do that, they will lose the protections offered by the deprecated Java SecurityManager. We could publish 10.15.3 and 10.14.3 releases also in order to cover users who need to run on Java 8 and Java 11 as well as users who need a SecurityManager. I don't know how many releases our dwindling community will be willing to vet. In any event, doc changes have to be made before we cut any releases. What are your thoughts? > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17640286#comment-17640286 ] ASF subversion and git services commented on DERBY-7147: Commit 1905586 from Richard N. Hillegas in branch 'code/branches/10.14' [ https://svn.apache.org/r1905586 ] DERBY-7147: Port derby-7147-02-ab-escapeLDAPsearchFilter.diff from the trunk to the 10.14 branch. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17640283#comment-17640283 ] ASF subversion and git services commented on DERBY-7147: Commit 1905585 from Richard N. Hillegas in branch 'code/branches/10.15' [ https://svn.apache.org/r1905585 ] DERBY-7147: Port derby-7147-02-ab-escapeLDAPsearchFilter.diff from the trunk to the 10.15 branch. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17639730#comment-17639730 ] ASF subversion and git services commented on DERBY-7147: Commit 1905560 from Richard N. Hillegas in branch 'code/branches/10.16' [ https://svn.apache.org/r1905560 ] DERBY-7147: Port 1905442 and 1905550 from the trunk to the 10.16 branch. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17639555#comment-17639555 ] ASF subversion and git services commented on DERBY-7147: Commit 1905550 from Richard N. Hillegas in branch 'code/trunk' [ https://svn.apache.org/r1905550 ] DERBY-7147: Fix an LDAP injection bug; commit derby-7147-02-ab-escapeLDAPsearchFilter.diff. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[ https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17639554#comment-17639554 ] Richard N. Hillegas commented on DERBY-7147: Thanks for testing the patch, Bryan. Your notes will be very useful when I try my hand at updating the user documentation. I'm afraid I can't shed any light on your questions about LDAPAuthenticationTest. > LDAP injection vulnerability in LDAPAuthenticationImpl > -- > > Key: DERBY-7147 > URL: https://issues.apache.org/jira/browse/DERBY-7147 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.16.1.1 >Reporter: Richard N. Hillegas >Assignee: Richard N. Hillegas >Priority: Major > Attachments: derby-7147-01-aa-reformatForReadability.diff, > derby-7147-02-aa-escapeLDAPsearchFilter.diff, > derby-7147-02-ab-escapeLDAPsearchFilter.diff > > > An LDAP injection vulnerability has been identified in > LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been > provided, but there is a possibility that an intruder could bypass > authentication checks in Derby-powered applications which rely on external > LDAP servers. > For more information on LDAP injection, see > https://www.synopsys.com/glossary/what-is-ldap-injection.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationImpl
[
https://issues.apache.org/jira/browse/DERBY-7147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17639540#comment-17639540
]
Bryan Pendleton commented on DERBY-7147:
Rick, a possible difference between your 'ant junit-single' and mine is that I
was running with *classes* (I did 'ant all', but not 'ant buildJars'), whereas
I think you were running with {*}jars{*}.
> LDAP injection vulnerability in LDAPAuthenticationImpl
> --
>
> Key: DERBY-7147
> URL: https://issues.apache.org/jira/browse/DERBY-7147
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.16.1.1
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7147-01-aa-reformatForReadability.diff,
> derby-7147-02-aa-escapeLDAPsearchFilter.diff,
> derby-7147-02-ab-escapeLDAPsearchFilter.diff
>
>
> An LDAP injection vulnerability has been identified in
> LDAPAuthenticationSchemeImpl.getDNFromUID(). An exploit has not been
> provided, but there is a possibility that an intruder could bypass
> authentication checks in Derby-powered applications which rely on external
> LDAP servers.
> For more information on LDAP injection, see
> https://www.synopsys.com/glossary/what-is-ldap-injection.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
