subject:""



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

Richard N. Hillegas commented on DERBY-7163:


Attaching derby-7163-01-aa-addJDK23vm.diff. This patch adds a JDK 23 test VM. 
Tests with this patch, using Open JDK build 23-ea+26-2269 passed cleanly using 
both the classpath and the modulepath. Derby builds and tests cleanly with that 
Open JDK build. The javadoc builds cleanly too.

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
M   
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/harness/JavaVersionHolder.java
A   
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/harness/jdk123.java
{noformat}


> Make it possible to build and test Derby with Open JDK 23
> -
>
> Key: DERBY-7163
> URL: https://issues.apache.org/jira/browse/DERBY-7163
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7163-01-aa-addJDK23vm.diff
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (DERBY-7163) Make it possible to build and test Derby with Open JDK 23



 [ 
https://issues.apache.org/jira/browse/DERBY-7163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard N. Hillegas updated DERBY-7163:
---
Attachment: derby-7163-01-aa-addJDK23vm.diff

> Make it possible to build and test Derby with Open JDK 23
> -
>
> Key: DERBY-7163
> URL: https://issues.apache.org/jira/browse/DERBY-7163
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7163-01-aa-addJDK23vm.diff
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes



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

Richard N. Hillegas commented on DERBY-6445:


Linking this issue to DERBY-6834, another discussion about the precision of 
Derby's DATE/TIME/TIMESTAMP types.

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, 
> derby-6445-02-aa-patchExplanation.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes



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

Richard N. Hillegas commented on DERBY-6445:


Thanks for your thoughts, Philippe and Bryan. It seems that there is broad 
agreement that the precision of Derby's TIME datatype is outside the scope of 
this JIRA issue.

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, 
> derby-6445-02-aa-patchExplanation.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

2024-06-10 Thread Bryan Pendleton (Jira)



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

Bryan Pendleton commented on DERBY-6445:


I think your reasoning is quite compelling, thank you for sharing that thought 
process.

I wonder, though: could we perhaps consider that a *different* enhancement, as 
it seems somewhat independent of this work?

That is, perhaps we can declare this work finished and track the sub-second 
behavior of TIME under a separate Jira work item?

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, 
> derby-6445-02-aa-patchExplanation.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

2024-06-10 Thread Philippe Marschall (Jira)



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

Philippe Marschall commented on DERBY-6445:
---

I think there are two different questions:
# Should the code for this JIRA silently truncate {{LocalTime}} to seconds? I 
believe so based on the current behavior of {{java.sql.Time}}. I just wanted to 
bring it up as it may not be immediately obvious.
# Should {{TIME}} in Apache Derby support sub-second precision? If not should 
it silently truncate? This is a much boarder question that I believe goes 
beyond the scope of this JIRA.

Unfortunately I do not have access to the SQL standard. I would like make two 
arguments for {{TIME}} supporting sub-second resolution. The first is a 
conceptual one, if a {{TIMESTAMP}} is an aggregate of a {{DATE}} and a {{TIME}} 
and {{TIMESTAMP}} has a sub-second resolution doesn't that mean that {{TIME}} 
should also have a sub-second resolution? Second a lot of other RDBMS support 
sub-second resolution for {{TIME}}
* PosgreS https://www.postgresql.org/docs/current/datatype-datetime.html
* SQL Server 
https://learn.microsoft.com/en-us/sql/t-sql/data-types/time-transact-sql
* MySQL https://dev.mysql.com/doc/refman/8.4/en/fractional-seconds.html
* H2 http://www.h2database.com/html/datatypes.html#time_type
* HSQLDB 
https://www.hsqldb.org/doc/guide/sqlgeneral-chapt.html#sgc_datetime_types

Oracle does not have a {{TIME}} datatype and DB2 does not support sub-second 
resolution https://www.ibm.com/docs/en/db2-for-zos/13?topic=values-time 
https://www.ibm.com/docs/en/db2/11.5?topic=list-datetime-values

As for Derby itself {{org.apache.derby.iapi.types.SQLTime}} already has a 
{{#encodedTimeFraction}} that is currently always 0 as {{#computeEncodedTime}} 
does not read the milliseconds from the calendar.

The Derby client itself seems to support sub-second resolution for {{Time}} if 
I have a look at {{org.apache.derby.client.am.CrossConverters#setObject(int, 
Timestamp)}} or {{DateTimeValue#DateTimeValue(Time, Calendar)}}.

Whether {{java.sql.Time}} supports sub-second resolution or truncates to 
seconds is a bit more complicated. Unfortunately the class comment is not very 
clear. What speaks for the truncation is that both {{#toString()}} and 
{{#valueOf(LocalTime)}} both truncate to seconds. What speaks against it is 
that it is possible to get the milliseconds out again. If we create a 
{{Calendar}} from the {{Time}} we get the millisecond value.

{{code}}
Calendar creationCalendar = Calendar.getInstance();
creationCalendar.clear();
creationCalendar.set(Calendar.YEAR, 1970);
creationCalendar.set(Calendar.MONTH, Calendar.JANUARY);
creationCalendar.set(Calendar.DAY_OF_MONTH, 1);
creationCalendar.set(Calendar.HOUR_OF_DAY, 1);
creationCalendar.set(Calendar.MINUTE, 2);
creationCalendar.set(Calendar.SECOND, 3);
int millis = 456;
creationCalendar.set(Calendar.MILLISECOND, millis);

Time time = new Time(creationCalendar.getTimeInMillis());
Calendar readBack = Calendar.getInstance();
readBack.setTimeInMillis(time.getTime());
assertEquals(millis, readBack.get(Calendar.MILLISECOND));
{{code}}

However when going through Derby it is always truncated to seconds. I haven't 
debugged it but would assume because 
{{org.apache.derby.iapi.types.SQLTime#encodedTimeFraction}} is always 0.

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, 
> derby-6445-02-aa-patchExplanation.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (DERBY-7163) Make it possible to build and test Derby with Open JDK 23

2024-06-03 Thread ASF subversion and git services (Jira)

Richard N. Hillegas created DERBY-7163:
--

 Summary: Make it possible to build and test Derby with Open JDK 23
 Key: DERBY-7163
 URL: https://issues.apache.org/jira/browse/DERBY-7163
 Project: Derby
  Issue Type: Task
  Components: Build tools
Affects Versions: 10.18.0.0
Reporter: Richard N. Hillegas
Assignee: Richard N. Hillegas






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

JDK 23 Feature Freeze / New Loom EA builds

2024-06-10 Thread David Delabassee

Welcome to the latest OpenJDK Quality Outreach update!

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

This time, we are covering several heads-up related to JDK 23 : Deprecate the 
Memory-Access Methods in sun.misc.Unsafe for Removal and default annotation 
processing policy change. Also, make sure to check the new Loom early-access 
builds which have an improved Java monitors implementation to work better with 
virtual threads.

[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009053.html
[2] https://openjdk.org/projects/jdk/23/


## Heads-Up - JDK 23: Deprecate the Memory-Access Methods in sun.misc.Unsafe 
for Removal

As mentioned in a previous communication [3], there’s a plan to ultimately 
remove the sun.misc.Unsafe memory-access methods as the platform offers safer 
alternatives. JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe 
for Removal) [4] outlines in more detail this plan including the initial step 
which is happening in JDK 23, i.e., all of the sun.misc unsafe memory-access 
methods are now marked as deprecated for removal. This will cause, in JDK 23, 
compile-time deprecation warnings for code that refers to these methods, 
alerting library developers to their forthcoming removal. A new command-line 
option also enables application developers and users to receive runtime 
warnings when those methods are used.

Developers relying on those sun.misc.Unsafe APIs for access memory are strongly 
encouraged to start, if they haven't done so yet, the migration from the 
sun.misc.Unsafe APIs to supported replacements. For more details, make sure to 
read JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for 
Removal).

[3] https://mail.openjdk.org/pipermail/quality-discuss/2024-January/001132.html
[4] https://openjdk.org/jeps/471


## Heads-Up - JDK 23: Changes Default Annotation Processing Policy

Annotation processing is a compile-time feature, where javac scans the 
to-be-compiled source files for annotations and then the class path for 
matching annotation processors, so they can generate source code. Up to JDK 22, 
this feature is enabled by default, which may have been reasonable when it was 
introduced in JDK 6 circa 2006, but from a current perspective, in the interest 
of making build output more robust against annotation processors being placed 
on the class path unintentionally, this is much less reasonable. Hence, 
starting with JDK 23, javac requires an additional command-line option to 
enable annotation processing.

### New `-proc` Value
To that end, the pre-existing option `-proc:$policy` was extended, where 
`$policy` can now have the following values:
- `none`: compilation _without_ annotation processing, this policy exists since 
JDK 6
- `only`: annotation processing _without_ compilation, this policy exists since 
JDK 6
- `full`: annotation processing followed by compilation, this policy is the 
default in JDK ≤22 but the value itself is new (see next section for versions 
that support it)

Up to and including JDK 22, code bases that require annotation processing 
before compilation could rely on javac's default behavior to process 
annotations but that is no longer the case. Starting with JDK 23, at least one 
annotation-processing command line option needs to be present. If neither 
`-processor`, `--processor-path`, now `--processor-module-path` is used, 
`-proc:only` or `-proc:full` has to be provided. In other words, absent other 
command line options, `-proc:none` is the default on JDK 23.

### Migration to `-proc:full`

Several measures were undertaken to help projects prepare for the switch to 
`-proc:full`:
- As of the April 2024 JDK security updates, support for `-proc:full` has been 
backported to 17u (17.0.11) and 11u (11.0.23) for both Oracle JDK and OpenJDK 
distributions. Additionally, Oracle's 8u release (8u411) also supports 
`-proc:full`.
- Starting in JDK 21, javac prints an informative message if implicit usage of 
annotation processing under the default policy is detected.

With `-proc:full` backported, it is possible to configure a build that will 
work the same before and after the change in javac's default policy.

Additional details can be found in the original proposal [5].

[5] https://mail.openjdk.org/pipermail/jdk-dev/2024-May/009028.html


## Heads-up - Loom: New EA builds with improved Java monitors implementation to 
work better with virtual threads

Project Loom published new early-access builds [6]. These builds have an 
improved

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

2024-06-03 Thread Richard N. Hillegas (Jira)



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

Richard N. Hillegas commented on DERBY-6445:


Thanks for that great explanation, Philippe. I have added it to the header 
comment of SQLTimstamp.

I am confused about the subtleties surrounding the precision of the 
java.sql.Time and SQL TIME types. My experiments show that java.sql.Time 
truncates a millisecond-granularity timestamp to seconds, throwing away the 
excess milliseconds, even using the Calendar code you included. The SQL TIME 
datatype has HOUR, MINUTE, and SECONDs parts (no milliseconds), according to 
the SQL Standard, part 2 (Foundation), clause 4.6.2 (Datetimes). So it seems to 
me that the code in the patch is correct as is.

Here is the experiment I ran:

{noformat}
import java.sql.*;
import java.util.Calendar;

public class TimeTest
{
public static void main(String... args) throws Exception {

Connection conn = 
DriverManager.getConnection("jdbc:derby:memory:db;create=true");

prepareStatement(conn, "CREATE TABLE t(a TIME)").execute();

Time time1 = new Time(System.currentTimeMillis());

Calendar calendar = Calendar.getInstance();
calendar.clear();
calendar.set(Calendar.YEAR, 1970);
calendar.set(Calendar.MONTH, Calendar.JANUARY);
calendar.set(Calendar.DAY_OF_MONTH, 1);
calendar.set(Calendar.HOUR_OF_DAY, 1);
calendar.set(Calendar.MINUTE, 2);
calendar.set(Calendar.SECOND, 3);
calendar.set(Calendar.MILLISECOND, 456);
Time time2 = new Time(calendar.getTimeInMillis());

try (PreparedStatement ps = prepareStatement(conn, "INSERT INTO t 
VALUES (?)"))
{
setTime(ps, time1);
ps.execute();

setTime(ps, time2);
ps.execute();
}

try (PreparedStatement ps = prepareStatement(conn, "SELECT * from t"))
{
try (ResultSet rs = ps.executeQuery())
{
while(rs.next())
{
println(rs.getTime(1).toString());
}
}
}

}

private static void setTime(PreparedStatement ps, Time time) throws 
SQLException {
println("Setting time column to " + time.toString());
ps.setTime(1, time);
}

private static PreparedStatement prepareStatement(Connection conn, String 
text) throws SQLException {
println("Preparing '" + text + "' ...");
return conn.prepareStatement(text);
}

private static void println(String text) { System.out.println(text); }
}
{noformat}

Here is the output of that experiment:

{noformat}
Preparing 'CREATE TABLE t(a TIME)' ...
Preparing 'INSERT INTO t VALUES (?)' ...
Setting time column to 12:26:04
Setting time column to 01:02:03
Preparing 'SELECT * from t' ...
12:26:04
01:02:03
{noformat}


> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, 
> derby-6445-02-aa-patchExplanation.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes



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

ASF subversion and git services commented on DERBY-6445:


Commit 1918137 from Richard N. Hillegas in branch 'code/trunk'
[ https://svn.apache.org/r1918137 ]

DERBY-6445: Add the explanation by Philippe to the header comment of 
SQLTimestamp; commit derby-6445-02-aa-patchExplanation.diff.

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, 
> derby-6445-02-aa-patchExplanation.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

2024-06-03 Thread Richard N. Hillegas (Jira)



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

Richard N. Hillegas commented on DERBY-6445:


Attaching derby-6445-02-aa-patchExplanation.diff. This patch adds Philippe's 
explanation to the header comment for SQLTimestamp.

Touches the following files:

{noformat}
M   
java/org.apache.derby.engine/org/apache/derby/iapi/types/SQLTimestamp.java

Philippe's explanation.


M   java/org.apache.derby.engine/org/apache/derby/iapi/types/SQLDate.java
M   java/org.apache.derby.engine/org/apache/derby/iapi/types/SQLTime.java

References to the SQLTimestamp header comment, for people interested in 
following the behavior of
java.time.LocalDate and java.time.LocalTime.
{noformat}


> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, 
> derby-6445-02-aa-patchExplanation.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

2024-06-03 Thread Richard N. Hillegas (Jira)



 [ 
https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard N. Hillegas updated DERBY-6445:
---
Attachment: derby-6445-02-aa-patchExplanation.diff

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, 
> derby-6445-02-aa-patchExplanation.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

2024-06-03 Thread ASF subversion and git services (Jira)



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

ASF subversion and git services commented on DERBY-6445:


Commit 1918136 from Richard N. Hillegas in branch 'code/branches/10.15'
[ https://svn.apache.org/r1918136 ]

DERBY-6445: Port 1918123 from trunk to 10.15 branch.

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

2024-06-03 Thread ASF subversion and git services (Jira)



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

ASF subversion and git services commented on DERBY-6445:


Commit 1918135 from Richard N. Hillegas in branch 'code/branches/10.16'
[ https://svn.apache.org/r1918135 ]

DERBY-6445: Port 1918123 from trunk to 10.16 branch.

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

2024-06-03 Thread ASF subversion and git services (Jira)



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

ASF subversion and git services commented on DERBY-6445:


Commit 1918134 from Richard N. Hillegas in branch 'code/branches/10.17'
[ https://svn.apache.org/r1918134 ]

DERBY-6445: Port 1918123 from trunk to 10.17 branch.

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

2024-06-02 Thread Philippe Marschall (Jira)



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

Philippe Marschall commented on DERBY-6445:
---

I'm probably the worst person to search potential of issues in my code. 
Nevertheless here are some potential issues to consider:

The {{LocalTime}}, {{LocalDate}} and {{LocalDateTime}} abstractions are [very 
simple| 
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/time/package-summary.html]
 and match very well to SQL types {{DATE}}, {{TIME}} and {{TIMESTAMP}}. This is 
by design.

{quote}
 LocalDate stores a date without a time. This stores a date like '2010-12-03' 
and could be used to store a birthday.
LocalTime stores a time without a date. This stores a time like '11:30' and 
could be used to store an opening or closing time.
LocalDateTime stores a date and time. This stores a date-time like 
'2010-12-03T11:30'. 
{quote}

Notice there is no reference to time zones, epochmillis and what not. This is 
reflected in the code, nowhere except for `#updateObject` does the new code 
mess with `Calendar`.

This the first way using the {{java.time}} classes can result in different 
results than using the {{java.sql}} classes. As there is no reference to a time 
zone there are also no time zone artifacts in the behavior. For example you can 
not store a {{Timestamp}} of {{2025-03-30 02:30}} in Derby if you're using the 
default {{Calendar}} and your JVM time zone is Europe/Berlin. This is because 
it falls into a DST transition, on {{2025-03-30 02:00}} the clocks are 
forwarded to {{2025-03-30 03:00}} hence {{2025-03-30 02:30}} "doesn't exist" in 
the JVM default time zone used by {{Timestap}}. Storing a {{LocalDateTime}} of 
{{2025-03-30 02:30}} on the other hand will work independent of the JVM default 
time zone as we bypass {{Calendar}} and therefore time zones. Writing tests for 
this would either require calling {{TimeZone.setDefault}} or relying on the 
test being run in a time zone that has daylight savings time.

The second difference is that the {{java.time}} classes use a [proleptic 
calendar|https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar] meaning 
our current leap year rules are applied "forever" and there is no jump from 4 
October 1582 to 15 October 1582. This is called an ISO calendar and my 
understanding is what the [SQL standard 
intends|https://www.postgresql.org/docs/current/datetime-units-history.html]. 
To give you an example
{code}
DAY(TIMESTAMP('1582-10-10 10:11:12.12345678'))
{code}
will return 20 with Derby, not 10. Using {{java.time}} classes will not fix 
this but will allow storing and retrieving of {{1582-10-10 10:11:12.12345678}}. 
Some tests here may also make sense.

The {{java.time}} classes default to ISO formatting meaning they use {{'T'}} 
instead of {{' '}} as a separator between day and time hence the need for a 
custom {{DateTimeFormatter}}.

The implementation as in the patch silently truncates {{LocalTime}} to seconds. 
{{LocalTime}} supports sub second resolution but the code in the patch ignores 
it. This is similar to the behavior of {{java.sql.Time}}. We can create a 
{{java.sql.Time}} with sub second resolution like so
{{code}}
Calendar calendar = Calendar.getInstance();
calendar.clear();
calendar.set(Calendar.YEAR, 1970);
calendar.set(Calendar.MONTH, Calendar.JANUARY);
calendar.set(Calendar.DAY_OF_MONTH, 1);
calendar.set(Calendar.HOUR_OF_DAY, 1);
calendar.set(Calendar.MINUTE, 2);
calendar.set(Calendar.SECOND, 3);
calendar.set(Calendar.MILLISECOND, 456);
new Time(calendar.getTimeInMillis()));
{{code}}
If there's agreement on the intended behavior then some tests here may also 
make sense.

And finally the {{java.time}} types operate on the [Java 
Time-Scale|https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/time/Instant.html]
 meaning they no not observe leap seconds. It is my understanding {{java.sql}} 
types do [not|https://bugs.openjdk.org/browse/JDK-4272347] support leap seconds 
either.

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
>

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

2024-06-02 Thread ASF subversion and git services (Jira)



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

ASF subversion and git services commented on DERBY-6445:


Commit 1918123 from Richard N. Hillegas in branch 'code/trunk'
[ https://svn.apache.org/r1918123 ]

DERBY-6445: Add JDBC support for new Time types; commit 
derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, the patch contributed by 
Philippe Marschall.

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7114) class org.apache.derby.iapi.store.raw.PageKey cannot be cast to class org.apache.derby.iapi.store.raw.ContainerKey

2024-05-28 Thread Sam Hutchins (Jira)



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

Sam Hutchins commented on DERBY-7114:
-

We still get this from time to time, with Derby 10.17.1.0 and JDK 21.0.2

> class org.apache.derby.iapi.store.raw.PageKey cannot be cast to class 
> org.apache.derby.iapi.store.raw.ContainerKey
> --
>
> Key: DERBY-7114
> URL: https://issues.apache.org/jira/browse/DERBY-7114
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.14.2.0
> Environment: Java 8/11, Windows/macOS
>Reporter: Sam Hutchins
>Priority: Major
>
> Hi,
>  
> We're using the embedded driver, and we sometimes see this exception in the 
> wild:
>  
> {code:java}
> java.lang.RuntimeException: java.sql.SQLException: Java exception: 'class 
> org.apache.derby.iapi.store.raw.PageKey cannot be cast to class 
> org.apache.derby.iapi.store.raw.ContainerKey 
> (org.apache.derby.iapi.store.raw.PageKey and 
> org.apache.derby.iapi.store.raw.ContainerKey are in unnamed module of loader 
> 'app'): java.lang.ClassCastException'.java.lang.RuntimeException: 
> java.sql.SQLException: Java exception: 'class 
> org.apache.derby.iapi.store.raw.PageKey cannot be cast to class 
> org.apache.derby.iapi.store.raw.ContainerKey 
> (org.apache.derby.iapi.store.raw.PageKey and 
> org.apache.derby.iapi.store.raw.ContainerKey are in unnamed module of loader 
> 'app'): java.lang.ClassCastException'. at 
> uk.co.screamingfrog.db.utils.DBHelpers.handleSQLException(SourceFile:68) 
> ~[dbutils-1.0-SNAPSHOT.jar:?] at 
> uk.co.screamingfrog.seospider.db.LinksTableOperations.a(SourceFile:341) 
> ~[ScreamingFrogSEOSpider.jar:?] at 
> uk.co.screamingfrog.seospider.db.LinksTableOperations.b(SourceFile:215) 
> ~[ScreamingFrogSEOSpider.jar:?] at 
> uk.co.screamingfrog.seospider.storage.db.k.c(SourceFile:82) 
> ~[ScreamingFrogSEOSpider.jar:?] at java.util.HashMap.computeIfAbsent(Unknown 
> Source) ~[?:?] at uk.co.screamingfrog.seospider.storage.db.k.b(SourceFile:76) 
> ~[ScreamingFrogSEOSpider.jar:?] at 
> uk.co.screamingfrog.seospider.storage.db.k.a(SourceFile:41) 
> ~[ScreamingFrogSEOSpider.jar:?] at 
> uk.co.screamingfrog.seospider.g.f.b(SourceFile:184) 
> ~[ScreamingFrogSEOSpider.jar:?] at 
> uk.co.screamingfrog.seospider.g.f.a(SourceFile:81) 
> ~[ScreamingFrogSEOSpider.jar:?] at 
> uk.co.screamingfrog.seospider.g.f.f(SourceFile:56) 
> ~[ScreamingFrogSEOSpider.jar:?] at 
> uk.co.screamingfrog.seospider.g.m.h_(SourceFile:58) 
> ~[ScreamingFrogSEOSpider.jar:?] at 
> uk.co.screamingfrog.seospider.h.d.c(SourceFile:22) 
> ~[ScreamingFrogSEOSpider.jar:?] at 
> uk.co.screamingfrog.seospider.h.e.c(SourceFile:66) 
> ~[ScreamingFrogSEOSpider.jar:?] at seo.spider.spider.a.n(SourceFile:114) 
> ~[ScreamingFrogSEOSpider.jar:?] at seo.spider.spider.a.k(SourceFile:91) 
> ~[ScreamingFrogSEOSpider.jar:?] at 
> uk.co.screamingfrog.utils.utils.PriorityRunnable.run(SourceFile:25) 
> ~[utils-1.0-SNAPSHOT.jar:?] at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[?:?] at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[?:?] at 
> java.lang.Thread.run(Unknown Source) [?:?]Caused by: java.sql.SQLException: 
> Java exception: 'class org.apache.derby.iapi.store.raw.PageKey cannot be cast 
> to class org.apache.derby.iapi.store.raw.ContainerKey 
> (org.apache.derby.iapi.store.raw.PageKey and 
> org.apache.derby.iapi.store.raw.ContainerKey are in unnamed module of loader 
> 'app'): java.lang.ClassCastException'. at 
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown 
> Source) ~[derby-10.14.2.0.jar:?] at 
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown 
> Source) ~[derby-10.14.2.0.jar:?] at 
> org.apache.derby.impl.jdbc.Util.seeNextException(Unknown Source) 
> ~[derby-10.14.2.0.jar:?] at 
> org.apache.derby.impl.jdbc.Util.javaException(Unknown Source) 
> ~[derby-10.14.2.0.jar:?] at 
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown 
> Source) ~[derby-10.14.2.0.jar:?] at 
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown 
> Source) ~[derby-10.14.2.0.jar:?] at 
> org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) 
> ~[derby-10.14.2.0.jar:?] at 
> org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) 
> ~[derby-10.14.2.0.jar:?] at 
> org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown 
> Source) ~[derby-10.14.2.0.jar:?] at 
> org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown Source) 
> ~[derby-10.14.2.0.jar:?] at 
> org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source) 
> ~[derby-10.14.2.0.jar:?] at 
>

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

2024-05-26 Thread Richard N. Hillegas (Jira)



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

Richard N. Hillegas commented on DERBY-6445:


Attaching derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff. This adds some 
additional tweaks to the 
derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff patch. Also attaching 
tweaks.diff which shows the difference between 
derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff and 
derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff. The tweaks are:

1) Diagnostic traces were added for entering and exiting some of the methods. 
As Philippe points out, there is no ideal approach to this problem. The 
original tracing was for entering/exiting the JDBC getter and setter methods. 
This breaks down when dealing with get/setObject() because those methods 
forward to more specific getters and setters. I added traces to the new 
forwarding methods.

2) I reduced the visibility of some of the new methods from public to private 
in order to avoid encroaching on public interfaces which may change in future 
revs of the JDBC spec.

3) I changed the data types reported in some error messages.

This patch touches the same files as the previous patches.

I ran full tests using both the classpath and the modulepath. Both runs were 
clean.

I am inclined to commit this patch because, despite my reservations (see 
below), I think that this is a large piece of solid, incremental work. Having 
some support for these data types is better than raising exceptions. Thanks, 
Philippe, for this valuable contribution.

My chief reservations are the following:

A) I am not an expert on the new date/time classes. I can't evaluate whether 
the patch causes these types to serialize and deserialize correctly. These 
classes came out of long, tortured discussions among Java champions and my 
sense is that the experts failed to reach consensus. I have nothing to add to 
those discussions. I am worried that an expert may log a bug saying that Derby 
is not (de)serializing these classes correctly.

B) Therefore, I would like to see some comments which explain the approach 
taken in serializing these objects, that is, for converting between the new 
classes and the JDBC types which Derby already supports. Right now, there are 
very few comments in this large patch. The comments should help us field bug 
reports which may be filed against the correctness of the serialization.

C) I would also like to see comments added to the new test methods, explaining 
what the methods are testing.

Thanks,
-Rick

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

2024-05-26 Thread Richard N. Hillegas (Jira)



 [ 
https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard N. Hillegas updated DERBY-6445:
---
Attachment: tweaks.diff

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff, tweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

2024-05-26 Thread Richard N. Hillegas (Jira)



 [ 
https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard N. Hillegas updated DERBY-6445:
---
Attachment: derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff, 
> derby-6445-01-ab-DERBY-6445.patchPlusPlusTweaks.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes

2024-05-25 Thread Philippe Marschall (Jira)



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

Philippe Marschall commented on DERBY-6445:
---

Thank you. Looking forward to it.

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes



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

Richard N. Hillegas commented on DERBY-6445:


Thanks for your thoughts about diagnostic logging, Philippe. I am going through 
the patch, making additional tweaks, including adding diagnostic logging calls. 
We can discuss this further when I post that revised patch.

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes



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

Philippe Marschall commented on DERBY-6445:
---

About the diagnostic logging, it is not clear to me how this could best be 
implemented. To give you an example:

{{org.apache.derby.client.am.ClientResultSet#getObject(String, Class)}} logs 
method entry, but does not log method exit. It ends up calling 
{{org.apache.derby.client.am.ClientResultSet#getObject(int, Class)}} which 
also logs method entry and not log method exit as well. This can end up calling 
an existing method like 
{{org.apache.derby.client.am.ClientResultSet#getDate(int, Calendar)}} which 
logs method entry and method exit or a new method like 
{{org.apache.derby.impl.jdbc.EmbedResultSet#getLocalDate(int)}} which, as you 
pointed out correctly, does not do any diagnostic logging. My reasoning here is 
this is a {{private}} utility method that can only be called indirectly while 
{{#getDate}} is a {{public}} API method that can be called directly by client 
code. Diagnostic logging currently only seems be done for {{public}} methods 
and very few {{protected}} methods these being four {{finalize}} methods and 
two methods on {{BasicClientDataSource}}. The situation is similar for 
{{org.apache.derby.client.am.ClientPreparedStatement}} and {{#setObject}}.

I see several options and would welcome your guidance:
- I could add diagnostic logging directly to the new {{private}} methods, they 
would become the first {{private}} methods to have diagnostic logging.
- Inline the new {{private}} methods into {{ClientResultSet}}. Not ideal.
- I could extend the diagnostic logging of {{#getObject}} to also log method 
exit. That would still result in different diagnostic logs depending on whether 
{{#getObject}} is called with {{java.sql.Date}} ({{#getObject}} and 
{{#getDate}} are logged) or with {{java.time.LocalTime}} (only {{#getObject}} 
is logged). To avoid this they would have to be split into a {{public}} method 
which performs diagnostic logging and a {{private}} one which contains the rest 
of the implementation. {{#getObject}} would call the latter to avoid logging 
twice.


> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes



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

Richard N. Hillegas commented on DERBY-6445:


Tests passed (with the classpath) on 
derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff.

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes



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

Richard N. Hillegas commented on DERBY-6445:


Attaching derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff. This is 
Philippe's patch plus some fixes for its Javadoc warnings. I will run full 
tests against this patch.

A quick glance at the patch indicates that some methods are missing the 
diagnostic logging which appears in sister methods. At a minimum, the patch 
will need a little more tweaking to bring it into alignment with that 
diagnostic logging pattern.

Touches the following files:

{noformat}
M   
java/org.apache.derby.client/org/apache/derby/client/am/ClientCallableStatement.java
M   
java/org.apache.derby.client/org/apache/derby/client/am/ClientPreparedStatement.java
M   
java/org.apache.derby.client/org/apache/derby/client/am/ClientResultSet.java
M   
java/org.apache.derby.client/org/apache/derby/client/am/CrossConverters.java
M   java/org.apache.derby.client/org/apache/derby/client/am/Cursor.java
M   java/org.apache.derby.client/org/apache/derby/client/am/DateTime.java
M   
java/org.apache.derby.client/org/apache/derby/client/am/DateTimeValue.java
M   java/org.apache.derby.engine/org/apache/derby/iapi/types/DataType.java
M   
java/org.apache.derby.engine/org/apache/derby/iapi/types/DataValueDescriptor.java
M   java/org.apache.derby.engine/org/apache/derby/iapi/types/SQLChar.java
M   java/org.apache.derby.engine/org/apache/derby/iapi/types/SQLClob.java
M   java/org.apache.derby.engine/org/apache/derby/iapi/types/SQLDate.java
M   java/org.apache.derby.engine/org/apache/derby/iapi/types/SQLTime.java
M   
java/org.apache.derby.engine/org/apache/derby/iapi/types/SQLTimestamp.java
M   java/org.apache.derby.engine/org/apache/derby/iapi/types/UserType.java
M   
java/org.apache.derby.engine/org/apache/derby/impl/jdbc/EmbedCallableStatement.java
M   
java/org.apache.derby.engine/org/apache/derby/impl/jdbc/EmbedPreparedStatement.java
M   
java/org.apache.derby.engine/org/apache/derby/impl/jdbc/EmbedResultSet.java
M   
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbc4/CallableStatementTest.java
M   
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbc4/PreparedStatementTest42.java
M   
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/jdbc4/Wrapper41Test.java
{noformat}


> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (DERBY-6445) JDBC 4.2: Add support for new date and time classes



 [ 
https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard N. Hillegas updated DERBY-6445:
---
Attachment: derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html, 
> derby-6445-01-aa-DERBY-6445.patchPlusJavadocCleanup.diff
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes



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

Richard N. Hillegas commented on DERBY-6445:


Thanks, Philippe. I will take a look at this patch.

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-6445) JDBC 4.2: Add support for new date and time classes



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

Philippe Marschall commented on DERBY-6445:
---

I attached a patch.

It contains:

- Support for both embedded and client mode.
- Support for both {{ResultSet}} and {{CallableStatement}}.
- Support for {{#getObject}}, {{#setObject}} and {{#updateObject}}.

The code avoids converting through {{java.sql}} types or {{Calendar}} and 
instead uses {{java.time}} types directly. Care has been taken to not affect 
existing code paths.

Limitations:
- {{#updateObject}} goes through the {{java.sql}} types, meaning to introduces 
the limitations of the {{java.sql}} times. I assume the method is used rarely 
enough so that this is acceptable. If not storing {{DateTimeValue}} instead of 
{{java.sql}} types in {{ClientResultSet.updatedColumns_}} would be an option.
- Java stored procedure implementations do not yet support java.time 
parameters. This would be more involved as method lookup would have to be 
updated and input/output conversion would have to happen.



> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (DERBY-6445) JDBC 4.2: Add support for new date and time classes



 [ 
https://issues.apache.org/jira/browse/DERBY-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Philippe Marschall updated DERBY-6445:
--
Attachment: DERBY-6445.patch

> JDBC 4.2: Add support for new date and time classes
> ---
>
> Key: DERBY-6445
> URL: https://issues.apache.org/jira/browse/DERBY-6445
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.10.1.1
>Reporter: Knut Anders Hatlen
>Priority: Major
> Attachments: DERBY-6445.patch, Derby-6445.html, Derby-6445.html
>
>
> JDBC 4.2 added type mappings for new date and time classes found in Java 8. 
> Derby should support these new mappings.
> This would at least affect Derby's implementation of the various getObject(), 
> setObject() and setNull() methods in ResultSet, PreparedStatement and 
> CallableStatement.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (DERBY-6920) Add input support for new date and time classes

2024-04-25 Thread ASF subversion and git services (Jira)



 [ 
https://issues.apache.org/jira/browse/DERBY-6920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Philippe Marschall closed DERBY-6920.
-
Resolution: Abandoned

I will submit a full input-output patch in DERBY-6445

> Add input support for new date and time classes
> ---
>
> Key: DERBY-6920
> URL: https://issues.apache.org/jira/browse/DERBY-6920
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Reporter: Philippe Marschall
>Priority: Major
> Attachments: jsr-310-input.diff
>
>
> This is the first half of DERBY-6445. The patch adds support for the new date 
> and time classes for input only. I may add output support later but for now 
> splitting it up makes for a smaller, easier to review and implement patch.
> A couple of notes about the implementation:
> * as the project now requires Java 1.8 I added the code directly to the 
> classes
> * the existing tests are expanded
> * I avoided calling the provided #valueOf conversion methods for several 
> reasons:
> ** LocalTime has nanosecond resolution but java.sql.Time only has millisecond 
> resolution
> ** LocalDateTime can represent timestamps that can not be represented by 
> java.sql.Timestamp because they fall into a daylight saving time transition
> ** Performance should be much better since creating a DateTimeValue instance 
> is a simple matter of calling a few getters. No calculation or object 
> creation is involved.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7161) Document the need for client-side applications to vet user-supplied connection directives

2024-04-25 Thread Bryan Pendleton (Jira)



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

Bryan Pendleton commented on DERBY-7161:


Thanks Rick. The doc changes look good to me.

> Document the need for client-side applications to vet user-supplied 
> connection directives
> -
>
> Key: DERBY-7161
> URL: https://issues.apache.org/jira/browse/DERBY-7161
> Project: Derby
>  Issue Type: Task
>  Components: Documentation, Network Client
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7161-01-aa-traceFileAttributes.diff, 
> derby-7161-01-aa-traceFileAttributes.tar
>
>
> Somewhere, we should document the fact that client-side applications should 
> not use user-supplied URLs or Properties objects to connect to remote 
> databases. Those URLs and Properties objects may contain instructions for 
> tracing network traffic. If the client-side application runs from a more 
> privileged account than the user, then this could let the user pollute parts 
> of the directory system to which the user does not normally have 
> write-access. Client-side applications should vet all user-supplied 
> directives before establishing connections.
> A related MySQL problem is described by [1].
> [1] 
> https://github.com/apache/security-site/compare/main...raboof:security-site:mysql



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7161) Document the need for client-side applications to vet user-supplied connection directives



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

ASF subversion and git services commented on DERBY-7161:


Commit 1917343 from Richard N. Hillegas in branch 'docs/branches/10.15'
[ https://svn.apache.org/r1917343 ]

DERBY-7161: Port 1917340 from docs trunk to docs 10.15.

> Document the need for client-side applications to vet user-supplied 
> connection directives
> -
>
> Key: DERBY-7161
> URL: https://issues.apache.org/jira/browse/DERBY-7161
> Project: Derby
>  Issue Type: Task
>  Components: Documentation, Network Client
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7161-01-aa-traceFileAttributes.diff, 
> derby-7161-01-aa-traceFileAttributes.tar
>
>
> Somewhere, we should document the fact that client-side applications should 
> not use user-supplied URLs or Properties objects to connect to remote 
> databases. Those URLs and Properties objects may contain instructions for 
> tracing network traffic. If the client-side application runs from a more 
> privileged account than the user, then this could let the user pollute parts 
> of the directory system to which the user does not normally have 
> write-access. Client-side applications should vet all user-supplied 
> directives before establishing connections.
> A related MySQL problem is described by [1].
> [1] 
> https://github.com/apache/security-site/compare/main...raboof:security-site:mysql



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7161) Document the need for client-side applications to vet user-supplied connection directives

2024-04-25 Thread ASF subversion and git services (Jira)



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

ASF subversion and git services commented on DERBY-7161:


Commit 1917342 from Richard N. Hillegas in branch 'docs/branches/10.16'
[ https://svn.apache.org/r1917342 ]

DERBY-7161: Port 1917340 from docs trunk to docs 10.16.

> Document the need for client-side applications to vet user-supplied 
> connection directives
> -
>
> Key: DERBY-7161
> URL: https://issues.apache.org/jira/browse/DERBY-7161
> Project: Derby
>  Issue Type: Task
>  Components: Documentation, Network Client
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7161-01-aa-traceFileAttributes.diff, 
> derby-7161-01-aa-traceFileAttributes.tar
>
>
> Somewhere, we should document the fact that client-side applications should 
> not use user-supplied URLs or Properties objects to connect to remote 
> databases. Those URLs and Properties objects may contain instructions for 
> tracing network traffic. If the client-side application runs from a more 
> privileged account than the user, then this could let the user pollute parts 
> of the directory system to which the user does not normally have 
> write-access. Client-side applications should vet all user-supplied 
> directives before establishing connections.
> A related MySQL problem is described by [1].
> [1] 
> https://github.com/apache/security-site/compare/main...raboof:security-site:mysql



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7161) Document the need for client-side applications to vet user-supplied connection directives

2024-04-25 Thread ASF subversion and git services (Jira)



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

ASF subversion and git services commented on DERBY-7161:


Commit 1917341 from Richard N. Hillegas in branch 'docs/branches/10.17'
[ https://svn.apache.org/r1917341 ]

DERBY-7161: Port 1917340 from docs trunk to docs 10.17.

> Document the need for client-side applications to vet user-supplied 
> connection directives
> -
>
> Key: DERBY-7161
> URL: https://issues.apache.org/jira/browse/DERBY-7161
> Project: Derby
>  Issue Type: Task
>  Components: Documentation, Network Client
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7161-01-aa-traceFileAttributes.diff, 
> derby-7161-01-aa-traceFileAttributes.tar
>
>
> Somewhere, we should document the fact that client-side applications should 
> not use user-supplied URLs or Properties objects to connect to remote 
> databases. Those URLs and Properties objects may contain instructions for 
> tracing network traffic. If the client-side application runs from a more 
> privileged account than the user, then this could let the user pollute parts 
> of the directory system to which the user does not normally have 
> write-access. Client-side applications should vet all user-supplied 
> directives before establishing connections.
> A related MySQL problem is described by [1].
> [1] 
> https://github.com/apache/security-site/compare/main...raboof:security-site:mysql



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7161) Document the need for client-side applications to vet user-supplied connection directives

2024-04-25 Thread ASF subversion and git services (Jira)



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

ASF subversion and git services commented on DERBY-7161:


Commit 1917340 from Richard N. Hillegas in branch 'docs/trunk'
[ https://svn.apache.org/r1917340 ]

DERBY-7161: Add warnings to documentation, highlighting the security 
implications of the ClientDriver connection tracing attributes; commit 
derby-7161-01-aa-traceFileAttributes.diff.

> Document the need for client-side applications to vet user-supplied 
> connection directives
> -
>
> Key: DERBY-7161
> URL: https://issues.apache.org/jira/browse/DERBY-7161
> Project: Derby
>  Issue Type: Task
>  Components: Documentation, Network Client
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7161-01-aa-traceFileAttributes.diff, 
> derby-7161-01-aa-traceFileAttributes.tar
>
>
> Somewhere, we should document the fact that client-side applications should 
> not use user-supplied URLs or Properties objects to connect to remote 
> databases. Those URLs and Properties objects may contain instructions for 
> tracing network traffic. If the client-side application runs from a more 
> privileged account than the user, then this could let the user pollute parts 
> of the directory system to which the user does not normally have 
> write-access. Client-side applications should vet all user-supplied 
> directives before establishing connections.
> A related MySQL problem is described by [1].
> [1] 
> https://github.com/apache/security-site/compare/main...raboof:security-site:mysql



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (DERBY-7161) Document the need for client-side applications to vet user-supplied connection directives

2024-04-23 Thread Richard N. Hillegas (Jira)



 [ 
https://issues.apache.org/jira/browse/DERBY-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard N. Hillegas updated DERBY-7161:
---
Attachment: derby-7161-01-aa-traceFileAttributes.tar

> Document the need for client-side applications to vet user-supplied 
> connection directives
> -
>
> Key: DERBY-7161
> URL: https://issues.apache.org/jira/browse/DERBY-7161
> Project: Derby
>  Issue Type: Task
>  Components: Documentation, Network Client
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7161-01-aa-traceFileAttributes.diff, 
> derby-7161-01-aa-traceFileAttributes.tar
>
>
> Somewhere, we should document the fact that client-side applications should 
> not use user-supplied URLs or Properties objects to connect to remote 
> databases. Those URLs and Properties objects may contain instructions for 
> tracing network traffic. If the client-side application runs from a more 
> privileged account than the user, then this could let the user pollute parts 
> of the directory system to which the user does not normally have 
> write-access. Client-side applications should vet all user-supplied 
> directives before establishing connections.
> A related MySQL problem is described by [1].
> [1] 
> https://github.com/apache/security-site/compare/main...raboof:security-site:mysql



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7161) Document the need for client-side applications to vet user-supplied connection directives

2024-04-23 Thread Richard N. Hillegas (Jira)



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

Richard N. Hillegas commented on DERBY-7161:


Attaching derby-7161-01-aa-traceFileAttributes.diff. This patch adds some 
documentation which warns users about the security implications of the trace 
file connection attributes. Also attaching 
derby-7161-01-aa-traceFileAttributes.tar, a tarball of corresponding generated 
output.

Touches the following files:

{noformat}
M   src/adminguide/cadminappsclient.dita

Adds a warning to the Admin Guide's "Accessing the Network Server by using the 
network client driver" topic.


M   src/devguide/cdevdvlp51654.dita

Adds a warning to the Developer's Guide's "Working with the database connection 
URL attributes" topic.


M   src/ref/rrefattrib24612.dita

Adds a warning to the Reference Guide's "Setting attributes for the database 
connection URL" topic.


M   src/security/csecintrosafer.dita

Adds a warning to the Security Guide's "Designing safer Derby applications" 
topic.
{noformat}


> Document the need for client-side applications to vet user-supplied 
> connection directives
> -
>
> Key: DERBY-7161
> URL: https://issues.apache.org/jira/browse/DERBY-7161
> Project: Derby
>  Issue Type: Task
>  Components: Documentation, Network Client
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7161-01-aa-traceFileAttributes.diff, 
> derby-7161-01-aa-traceFileAttributes.tar
>
>
> Somewhere, we should document the fact that client-side applications should 
> not use user-supplied URLs or Properties objects to connect to remote 
> databases. Those URLs and Properties objects may contain instructions for 
> tracing network traffic. If the client-side application runs from a more 
> privileged account than the user, then this could let the user pollute parts 
> of the directory system to which the user does not normally have 
> write-access. Client-side applications should vet all user-supplied 
> directives before establishing connections.
> A related MySQL problem is described by [1].
> [1] 
> https://github.com/apache/security-site/compare/main...raboof:security-site:mysql



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (DERBY-7161) Document the need for client-side applications to vet user-supplied connection directives

2024-04-23 Thread Richard N. Hillegas (Jira)



 [ 
https://issues.apache.org/jira/browse/DERBY-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard N. Hillegas updated DERBY-7161:
---
Attachment: derby-7161-01-aa-traceFileAttributes.diff

> Document the need for client-side applications to vet user-supplied 
> connection directives
> -
>
> Key: DERBY-7161
> URL: https://issues.apache.org/jira/browse/DERBY-7161
> Project: Derby
>  Issue Type: Task
>  Components: Documentation, Network Client
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7161-01-aa-traceFileAttributes.diff
>
>
> Somewhere, we should document the fact that client-side applications should 
> not use user-supplied URLs or Properties objects to connect to remote 
> databases. Those URLs and Properties objects may contain instructions for 
> tracing network traffic. If the client-side application runs from a more 
> privileged account than the user, then this could let the user pollute parts 
> of the directory system to which the user does not normally have 
> write-access. Client-side applications should vet all user-supplied 
> directives before establishing connections.
> A related MySQL problem is described by [1].
> [1] 
> https://github.com/apache/security-site/compare/main...raboof:security-site:mysql



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7162) Update Git mirror for db-derby. Current mirror is out of date, hasn't been updated since 2019

2024-04-14 Thread Richard N. Hillegas (Jira)



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

Richard N. Hillegas commented on DERBY-7162:


Can you describe the problem you had when trying to build Derby locally? Maybe 
someone can advise you on how to get over that hurdle.

> Update Git mirror for db-derby. Current mirror is out of date, hasn't been 
> updated since 2019
> -
>
> Key: DERBY-7162
> URL: https://issues.apache.org/jira/browse/DERBY-7162
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Reporter: Bob Neugebauer
>Priority: Major
>
> There is an existing GIT mirror for DB-DERBY available at 
> [https://github.com/apache/derby] however this mirror is out of date. Last 
> commit was Aug 2019. This mirror is missing all branches and tags that the 
> derby SVN repo contains.
> I had opened an INFRA ticket INFRA-25623 to request an update to git but 
> Chris said this had to come from the derby maintainers.
> I have a project that is using derby, in particular 10.17, and I am looking 
> for the best way to avoid having our build servers hit ASF frequently to pull 
> from SVN. Using a git fork would seem the best way to achieve this.
>  
> Thanks, Bob



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7162) Update Git mirror for db-derby. Current mirror is out of date, hasn't been updated since 2019

2024-04-14 Thread Richard N. Hillegas (Jira)



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

Richard N. Hillegas commented on DERBY-7162:


Linking this issue to DERBY-6645, a previous attempt to create a parallel 
maven-based build for Derby. If I remember correctly, that attempt foundered on 
the complexity of message-file generation. Maven-related discussion should be 
moved to DERBY-6645. I am happy to coach you through a follow-on mavenization 
effort there.


> Update Git mirror for db-derby. Current mirror is out of date, hasn't been 
> updated since 2019
> -
>
> Key: DERBY-7162
> URL: https://issues.apache.org/jira/browse/DERBY-7162
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Reporter: Bob Neugebauer
>Priority: Major
>
> There is an existing GIT mirror for DB-DERBY available at 
> [https://github.com/apache/derby] however this mirror is out of date. Last 
> commit was Aug 2019. This mirror is missing all branches and tags that the 
> derby SVN repo contains.
> I had opened an INFRA ticket INFRA-25623 to request an update to git but 
> Chris said this had to come from the derby maintainers.
> I have a project that is using derby, in particular 10.17, and I am looking 
> for the best way to avoid having our build servers hit ASF frequently to pull 
> from SVN. Using a git fork would seem the best way to achieve this.
>  
> Thanks, Bob



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7162) Update Git mirror for db-derby. Current mirror is out of date, hasn't been updated since 2019

2024-04-14 Thread Steinar Bang (Jira)



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

Steinar Bang commented on DERBY-7162:
-

Please note: this isn't a complaint. Maybe a shout of despair, but not a 
complaint.

I could live with subversion (though I don't understand it. I switched from 
subversion to git in 2010 and have never felt the urge to go back. Main reason 
is that branching and merging works. Branching is something I really, really, 
,tried to do in subversion), but I would be really really happy if derby 
switched from ant to maven for the build.

Right now the OSGi support of derby is thoroughly broken (the exported 
package(s) don't match the package names found in the class files, which don't 
match the class files directory structure in the jar files. Also different jars 
contain the same packages) and I looked into providing a patch/pull request.

A pull request is out since derby doesn't use git.

And a patch is out because I can't make derby build locally.

I tried following [Using Eclipse to Build 
Derby|https://cwiki.apache.org/confluence/display/DERBY/BuildingDerby#BuildingDerby-UsingEclipsetoBuildDerby]
 but I couldn't get it to work on eclipse 2024-03 on java 17.

There is both an ant build and a separate maven hierarchy (something I've never 
seen before in the time I've used maven) in the project but I have no idea 
which one is used..

I tried importing the maven project(s) into eclipse but that contained no 
source files.

In my opinion: To make the maven build work right, heavy reorganization would 
be needed: java source should be moved down into the src/main/java directory of 
the projects. Also files should be moved into directories to match their 
package names. Also it would be really, really nice from an OSGi point of view 
if two jar files didn't contain the same packages.

I could contribute to such a reorganization (but if it isn't something anybody 
wants there is no point spending time on it).

> Update Git mirror for db-derby. Current mirror is out of date, hasn't been 
> updated since 2019
> -
>
> Key: DERBY-7162
> URL: https://issues.apache.org/jira/browse/DERBY-7162
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Reporter: Bob Neugebauer
>Priority: Major
>
> There is an existing GIT mirror for DB-DERBY available at 
> [https://github.com/apache/derby] however this mirror is out of date. Last 
> commit was Aug 2019. This mirror is missing all branches and tags that the 
> derby SVN repo contains.
> I had opened an INFRA ticket INFRA-25623 to request an update to git but 
> Chris said this had to come from the derby maintainers.
> I have a project that is using derby, in particular 10.17, and I am looking 
> for the best way to avoid having our build servers hit ASF frequently to pull 
> from SVN. Using a git fork would seem the best way to achieve this.
>  
> Thanks, Bob



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7161) Document the need for client-side applications to vet user-supplied connection directives

2024-04-07 Thread Richard N. Hillegas (Jira)



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

Richard N. Hillegas commented on DERBY-7161:


Those sound like good places to add some verbiage too. Thanks

> Document the need for client-side applications to vet user-supplied 
> connection directives
> -
>
> Key: DERBY-7161
> URL: https://issues.apache.org/jira/browse/DERBY-7161
> Project: Derby
>  Issue Type: Task
>  Components: Documentation, Network Client
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Priority: Major
>
> Somewhere, we should document the fact that client-side applications should 
> not use user-supplied URLs or Properties objects to connect to remote 
> databases. Those URLs and Properties objects may contain instructions for 
> tracing network traffic. If the client-side application runs from a more 
> privileged account than the user, then this could let the user pollute parts 
> of the directory system to which the user does not normally have 
> write-access. Client-side applications should vet all user-supplied 
> directives before establishing connections.
> A related MySQL problem is described by [1].
> [1] 
> https://github.com/apache/security-site/compare/main...raboof:security-site:mysql



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7161) Document the need for client-side applications to vet user-supplied connection directives

2024-04-06 Thread Bryan Pendleton (Jira)



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

Bryan Pendleton commented on DERBY-7161:


Yes, those seem good.

Perhaps also put links to the information in these places?
 * [https://db.apache.org/derby/docs/10.17/ref/rrefattrib24612.html]
 * https://db.apache.org/derby/docs/10.17/devguide/cdevdvlp51654.html

> Document the need for client-side applications to vet user-supplied 
> connection directives
> -
>
> Key: DERBY-7161
> URL: https://issues.apache.org/jira/browse/DERBY-7161
> Project: Derby
>  Issue Type: Task
>  Components: Documentation, Network Client
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Priority: Major
>
> Somewhere, we should document the fact that client-side applications should 
> not use user-supplied URLs or Properties objects to connect to remote 
> databases. Those URLs and Properties objects may contain instructions for 
> tracing network traffic. If the client-side application runs from a more 
> privileged account than the user, then this could let the user pollute parts 
> of the directory system to which the user does not normally have 
> write-access. Client-side applications should vet all user-supplied 
> directives before establishing connections.
> A related MySQL problem is described by [1].
> [1] 
> https://github.com/apache/security-site/compare/main...raboof:security-site:mysql



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7161) Document the need for client-side applications to vet user-supplied connection directives

2024-04-06 Thread Richard N. Hillegas (Jira)



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

Richard N. Hillegas commented on DERBY-7161:


Hi Bryan,

I suppose that something should be said in the Server Guide and the Security 
Guide. What are your thoughts?

> Document the need for client-side applications to vet user-supplied 
> connection directives
> -
>
> Key: DERBY-7161
> URL: https://issues.apache.org/jira/browse/DERBY-7161
> Project: Derby
>  Issue Type: Task
>  Components: Documentation, Network Client
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Priority: Major
>
> Somewhere, we should document the fact that client-side applications should 
> not use user-supplied URLs or Properties objects to connect to remote 
> databases. Those URLs and Properties objects may contain instructions for 
> tracing network traffic. If the client-side application runs from a more 
> privileged account than the user, then this could let the user pollute parts 
> of the directory system to which the user does not normally have 
> write-access. Client-side applications should vet all user-supplied 
> directives before establishing connections.
> A related MySQL problem is described by [1].
> [1] 
> https://github.com/apache/security-site/compare/main...raboof:security-site:mysql



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[INFO] DB Report for April, 2024

2024-04-06 Thread Bryan Pendleton

Hi all, thanks for the project update notes. Below is the
report I submitted to the board. Please let me know
of any errors or missing parts.

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.


## Project Status:
Current project status: Ongoing, with moderate activity
Issues for the board: none

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

Community changes, past quarter:
- No new PMC members. Last addition was Tobias Bouschen on 2023-08-27.
- No new committers. Last addition was Max Philipp Wriedt on 2023-04-14.

## Project Activity:
Several security issues were brought to the DB project's attention
this quarter, and were addressed by various community members:
- JDO community addressed an XSS vulnerability in the project's
  old archived Javadocs by removing the no-longer-required Javadocs
  from the project website.
- DB community addressed an XSS vulnerability in the (retired) ddlutils
  Javadocs by removing the no-longer-required Javadocs from the
  project website.
- Derby community examined an arbitrary file write vulnerability
  in the Derby client libraries and determined that it was best
  addressed via a combination of
  - documentation of the requirement for users to use this
particular log-tracing feature with care,
  - and notice to known clients.

Apache security team assisted with the resolution of these security
issues and we are grateful as always for their prompt and thorough
help!

Torque team are readying a new release and discussing whether it
should be classified as a minor release or a major release based
on its changes. It would probably become either release 5.2 or 6.0,
depending on the outcome of the discussions.

Derby team have been verifying Derby compatibility with JDKs 21
and 22. No new problems have been revealed.

JDO team have been investigating several issues uncovered by
runs of the TCK.

## Community Health:
DB project health was good over the winter. All the project
teams were actively discussing development issues and working
on fixes and enhancements.

[jira] [Commented] (DERBY-7161) Document the need for client-side applications to vet user-supplied connection directives

2024-04-06 Thread Bryan Pendleton (Jira)



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

Bryan Pendleton commented on DERBY-7161:


Hi Rick, have you thought much about where we might best document this?

My thought is that we might put such documentation in multiple places to give 
it the best chance of being seen.

> Document the need for client-side applications to vet user-supplied 
> connection directives
> -
>
> Key: DERBY-7161
> URL: https://issues.apache.org/jira/browse/DERBY-7161
> Project: Derby
>  Issue Type: Task
>  Components: Documentation, Network Client
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Priority: Major
>
> Somewhere, we should document the fact that client-side applications should 
> not use user-supplied URLs or Properties objects to connect to remote 
> databases. Those URLs and Properties objects may contain instructions for 
> tracing network traffic. If the client-side application runs from a more 
> privileged account than the user, then this could let the user pollute parts 
> of the directory system to which the user does not normally have 
> write-access. Client-side applications should vet all user-supplied 
> directives before establishing connections.
> A related MySQL problem is described by [1].
> [1] 
> https://github.com/apache/security-site/compare/main...raboof:security-site:mysql



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Java 22 is GA + Heads-up!

2024-04-02 Thread David Delabassee

Welcome to the latest OpenJDK Quality Outreach update!

Java 22 was just released along with JavaFX 22 [1][2]. Thank you to all the 
projects who contributed to those releases by testing and providing feedback 
using their respective early-access builds. And to celebrate that, the Java 
DevRel Team hosted a +4h live-stream with guests such as Brian Goetz, Viktor 
Klang, Alan Bateman, etc. You can watch the launch stream replay here [3].

The JDK 23 schedule is now known [4] with rampdown starting early June and 
general availability sets for mid-September. So far, 2 JEPs have been targeted 
to JDK 23:
- JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview) [5]
- JEP 466: Class-File API (2nd Preview) [6]

The focus should now be shifted to testing your project(s) on JDK 23. And don't 
forget that the Oracle setup-java github action [7] supports, amongst others, 
the latest OpenJDK 23 Early-Access builds. So, JDK 23 EA testing is literally 
one pipeline away.

[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-March/008827.html
[3] https://jdk.java.net/javafx22/
[3] https://www.youtube.com/live/AjjAZsnRXtE?feature=shared=278
[4] https://openjdk.org/projects/jdk/23/
[5] https://openjdk.org/jeps/455
[6] https://openjdk.org/jeps/466
[7] https://github.com/oracle-actions/setup-java


## Heads-up: JDK 20-23: Support for Unicode CLDR Version 42

The JDK update to CLDR version 42 included a change where regular spaces in 
date/time formats (and some other formatted values) were replaced with (narrow) 
non-breaking spaces. This lead to issues for existing code that relied on 
parsing such strings. To address that, JDK 23 allows loose matching of spaces 
when parsing date/time strings. Loose matching is performed in the lenient 
parsing style for both date/time parsers in `java.time.format` and `java.text` 
packages. In the default strict parsing style, those spaces are considered 
distinct as before.

Please read this updated heads-up [9] for details on how to configure 
strict/lenient parsing in the `java.time.format` (strict by default) and 
`java.text` (lenient by default) packages.

[9] https://inside.java/2024/03/29/quality-heads-up/


## Heads-up: macOS 14 users running on Apple silicon systems should update 
directly to macOS 14.4.1

An issue introduced by macOS 14.4 caused some Java processes, regardless of the 
Java version, to terminate unexpectedly on Apple silicon (AArch64). On March 25 
Apple released macOS 14.4.1 and indicated on their support site that it 
addresses this issue. Oracle can confirm that after applying macOS 14.4.1 we 
are unable to reproduce the problem. So, Java users on macOS 14 running on 
Apple silicon systems should skip macOS 14.4 and update directly to macOS 
14.4.1.

More details can be found on 
https://blogs.oracle.com/java/post/java-on-macos-14-4


## JDK 23 Early-Access Builds

The JDK 23 EA builds 16 are available [10], and are provided under the GNU 
General Public License v2, with the Classpath Exception. The Release Notes [11] 
are also available.

### Changes in recent JDK 23 builds that may be of interest:
- JDK-8324774: Add DejaVu web fonts (reported by AssertJ)
- JDK-8327385: Add JavaDoc option to exclude web fonts from generated 
documentation (reported by AssertJ)
- JDK-8328638: Fallback option for POST-only OCSP requests
- JDK-8320362: Load anchor certificates from Keychain keystore
- JDK-8327875: ChoiceFormat should advise throwing 
UnsupportedOperationException for unused methods
- JDK-8296244: Alternate implementation of user-based authorization Subject 
APIs that doesn’t depend on Security Manager APIs
- JDK-8327818: Implement Kerberos debug with sun.security.util.Debug
- JDK-7036144: GZIPInputStream readTrailer uses faulty available() test for 
end-of-stream
- JDK-8319251: Change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT
- JDK-8327651: Rename DictionaryEntry members related to protection domain
- JDK-8321408: Add Certainly roots R1 and E1
- JDK-8164094: javadoc allows to create a @link to a non-existent method
- JDK-8325496: Make TrimNativeHeapInterval a product switch
- JDK-8174269: Remove COMPAT locale data provider from JDK
- JDK-8322750: Test "api/java_awt/interactive/SystemTrayTests.html" failed 
because …
- JDK-8139457: Relax alignment of array elements
- JDK-8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly
- JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError when pattern is 
empty string
- JDK-8247972: incorrect implementation of JVM TI GetObjectMonitorUsage
- JDK-8325580: Remove "alternatives --remove" call from Java rpm installer
- JDK-8326838: JFR: Native mirror events
- JDK-8326106: Write and clear stack trace table outside of safepoint
- JDK-8323183: ClassFile API performance improvements
- JDK-8324829: Uniform use of synchronizations in NMT
- JDK-8326586: Improve Speed of System.map
- JDK-8318761: MessageFormat pattern support for CompactNumberFormat, 
ListFormat, and DateTimeFormatter

Re: Updates for our April report to the board?

2024-03-31 Thread Rick Hillegas


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

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

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

thanks,

bryan


Hey Bryan,

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

Updates for our April report to the board?

2024-03-31 Thread Bryan Pendleton

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

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

thanks,

bryan

[jira] [Commented] (DERBY-7162) Update Git mirror for db-derby. Current mirror is out of date, hasn't been updated since 2019

2024-03-25 Thread Bob Neugebauer (Jira)



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

Bob Neugebauer commented on DERBY-7162:
---

Thanks [~rhillegas] . For our use of the derby codebase, I am fine with it 
being a read only mirror and you ignoring forks and pull requests

As for your other questions about git mirroring, I cannot answer that myself. I 
don't personally know how frequent git mirroring would occur or if there is any 
involvement from the project team in that process

 

[~cml] This is in relation to the infra ticket I opened INFRA-25623 that you 
responded to, can you let Richard know if there are impacts to the project team 
if the git-mirror is updated?

Thanks

> Update Git mirror for db-derby. Current mirror is out of date, hasn't been 
> updated since 2019
> -
>
> Key: DERBY-7162
> URL: https://issues.apache.org/jira/browse/DERBY-7162
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Reporter: Bob Neugebauer
>Priority: Major
>
> There is an existing GIT mirror for DB-DERBY available at 
> [https://github.com/apache/derby] however this mirror is out of date. Last 
> commit was Aug 2019. This mirror is missing all branches and tags that the 
> derby SVN repo contains.
> I had opened an INFRA ticket INFRA-25623 to request an update to git but 
> Chris said this had to come from the derby maintainers.
> I have a project that is using derby, in particular 10.17, and I am looking 
> for the best way to avoid having our build servers hit ASF frequently to pull 
> from SVN. Using a git fork would seem the best way to achieve this.
>  
> Thanks, Bob



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7162) Update Git mirror for db-derby. Current mirror is out of date, hasn't been updated since 2019

2024-03-22 Thread Richard N. Hillegas (Jira)



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

Richard N. Hillegas commented on DERBY-7162:


Apache Derby is an old project maintained by old engineers who use old tools. 
Our code is maintained in subversion. None of the active committers accept 
contributions via git.

I don't remember who created this git mirror. Clearly no-one volunteered to 
keep it evergreen.

That said, I have no objection to periodic, automatic updates of this git 
mirror provided that

1) I don't have to do anything more than make one request to INFRA to make it 
so.

2) It is understood that the Derby project considers this to be a read-only 
mirror.

3) It is further understood that the Derby project will ignore this mirror and 
all forks from it.

If that is an acceptable situation, then I will need someone to tell me what I 
need to do to enable it.

-Rick

> Update Git mirror for db-derby. Current mirror is out of date, hasn't been 
> updated since 2019
> -
>
> Key: DERBY-7162
> URL: https://issues.apache.org/jira/browse/DERBY-7162
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Reporter: Bob Neugebauer
>Priority: Major
>
> There is an existing GIT mirror for DB-DERBY available at 
> [https://github.com/apache/derby] however this mirror is out of date. Last 
> commit was Aug 2019. This mirror is missing all branches and tags that the 
> derby SVN repo contains.
> I had opened an INFRA ticket INFRA-25623 to request an update to git but 
> Chris said this had to come from the derby maintainers.
> I have a project that is using derby, in particular 10.17, and I am looking 
> for the best way to avoid having our build servers hit ASF frequently to pull 
> from SVN. Using a git fork would seem the best way to achieve this.
>  
> Thanks, Bob



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (DERBY-7162) Update Git mirror for db-derby. Current mirror is out of date, hasn't been updated since 2019

2024-03-22 Thread Bob Neugebauer (Jira)



 [ 
https://issues.apache.org/jira/browse/DERBY-7162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bob Neugebauer updated DERBY-7162:
--
Issue Type: Task  (was: Bug)

> Update Git mirror for db-derby. Current mirror is out of date, hasn't been 
> updated since 2019
> -
>
> Key: DERBY-7162
> URL: https://issues.apache.org/jira/browse/DERBY-7162
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Reporter: Bob Neugebauer
>Priority: Major
>
> There is an existing GIT mirror for DB-DERBY available at 
> [https://github.com/apache/derby] however this mirror is out of date. Last 
> commit was Aug 2019. This mirror is missing all branches and tags that the 
> derby SVN repo contains.
> I had opened an INFRA ticket INFRA-25623 to request an update to git but 
> Chris said this had to come from the derby maintainers.
> I have a project that is using derby, in particular 10.17, and I am looking 
> for the best way to avoid having our build servers hit ASF frequently to pull 
> from SVN. Using a git fork would seem the best way to achieve this.
>  
> Thanks, Bob



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (DERBY-7162) Update Git mirror for db-derby. Current mirror is out of date, hasn't been updated since 2019

2024-03-22 Thread Bob Neugebauer (Jira)

Bob Neugebauer created DERBY-7162:
-

 Summary: Update Git mirror for db-derby. Current mirror is out of 
date, hasn't been updated since 2019
 Key: DERBY-7162
 URL: https://issues.apache.org/jira/browse/DERBY-7162
 Project: Derby
  Issue Type: Bug
  Components: Build tools
Reporter: Bob Neugebauer


There is an existing GIT mirror for DB-DERBY available at 
[https://github.com/apache/derby] however this mirror is out of date. Last 
commit was Aug 2019. This mirror is missing all branches and tags that the 
derby SVN repo contains.

I had opened an INFRA ticket INFRA-25623 to request an update to git but Chris 
said this had to come from the derby maintainers.


I have a project that is using derby, in particular 10.17, and I am looking for 
the best way to avoid having our build servers hit ASF frequently to pull from 
SVN. Using a git fork would seem the best way to achieve this.

 

Thanks, Bob



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (DERBY-7161) Document the need for client-side applications to vet user-supplied connection directives

2024-03-21 Thread Richard N. Hillegas (Jira)



 [ 
https://issues.apache.org/jira/browse/DERBY-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard N. Hillegas updated DERBY-7161:
---
Component/s: Documentation

> Document the need for client-side applications to vet user-supplied 
> connection directives
> -
>
> Key: DERBY-7161
> URL: https://issues.apache.org/jira/browse/DERBY-7161
> Project: Derby
>  Issue Type: Task
>  Components: Documentation, Network Client
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Priority: Major
>
> Somewhere, we should document the fact that client-side applications should 
> not use user-supplied URLs or Properties objects to connect to remote 
> databases. Those URLs and Properties objects may contain instructions for 
> tracing network traffic. If the client-side application runs from a more 
> privileged account than the user, then this could let the user pollute parts 
> of the directory system to which the user does not normally have 
> write-access. Client-side applications should vet all user-supplied 
> directives before establishing connections.
> A related MySQL problem is described by [1].
> [1] 
> https://github.com/apache/security-site/compare/main...raboof:security-site:mysql



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (DERBY-7161) Document the need for client-side applications to vet user-supplied connection directives

2024-03-21 Thread Richard N. Hillegas (Jira)

Richard N. Hillegas created DERBY-7161:
--

 Summary: Document the need for client-side applications to vet 
user-supplied connection directives
 Key: DERBY-7161
 URL: https://issues.apache.org/jira/browse/DERBY-7161
 Project: Derby
  Issue Type: Task
  Components: Network Client
Affects Versions: 10.18.0.0
Reporter: Richard N. Hillegas


Somewhere, we should document the fact that client-side applications should not 
use user-supplied URLs or Properties objects to connect to remote databases. 
Those URLs and Properties objects may contain instructions for tracing network 
traffic. If the client-side application runs from a more privileged account 
than the user, then this could let the user pollute parts of the directory 
system to which the user does not normally have write-access. Client-side 
applications should vet all user-supplied directives before establishing 
connections.

A related MySQL problem is described by [1].

[1] 
https://github.com/apache/security-site/compare/main...raboof:security-site:mysql




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (DERBY-7160) Why do we see test failure/regression cause ERROR 22003: The resulting value is outside the range for the data type DECIMAL/NUMERIC(30,15)



 [ 
https://issues.apache.org/jira/browse/DERBY-7160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard N. Hillegas closed DERBY-7160.
--

> Why do we see test failure/regression cause ERROR 22003: The resulting value 
> is outside the range for the data type DECIMAL/NUMERIC(30,15)
> --
>
> Key: DERBY-7160
> URL: https://issues.apache.org/jira/browse/DERBY-7160
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.17.1.0
>Reporter: Scott Marlow
>Priority: Major
> Fix For: 10.17.1.1
>
> Attachments: DERBY_7160-1.java, DERBY_7160.java
>
>
> This may be a regression or maybe a design change, not sure of which as the 
> same tests pass for us on Java SE 11/17 with 
> https://dlcdn.apache.org//db/derby/db-derby-10.15.2.0/db-derby-10.15.2.0-bin.zip.
> We are seeing a JDBC TCK test failure (Jakarta EE 10 TCK) when testing 
> against [https://db.apache.org/derby/releases/release-10_17_1_0.cgi] on java 
> 21 with the external project [https://github.com/wildfly/wildfly] that I 
> contribute to.
> I marked this issue as a bug but I really have no idea where the bug is.  The 
> JDBC test that is failing is 
> [https://github.com/jakartaee/platform-tck/blob/10.0.x/src/com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#L968]
>  when run on Java 21 with 10.17.1.0.
> The failure is:
> {quote}
> Caused by: ERROR 22003: The resulting value is outside the range for the data 
> type DECIMAL/NUMERIC(30,15).
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.completeExecute(ClientStatement.java:1868)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:323)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:107)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:84)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:193)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.readExecuteCall(ClientStatement.java:1831)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.flowExecute(ClientPreparedStatement.java:2180)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdateX(ClientPreparedStatement.java:410)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:396)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) ... 16 more
> {quote}
>  
> The called stored procedure source is at 
> https://github.com/jakartaee/platform-tck/blob/10.0.x/sql/derby/derby.ddl.sprocs.sql#L224
>  which contains:
> {quote}
> create procedure Decimal_In_Max (in MAX_PARAM DECIMAL(30,15)) language java 
> external name 'com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max' parameter 
> style java;
> {quote}
> The referenced com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max contains:
> {code}
> Connection con = DriverManager.getConnection("jdbc:default:connection");
> PreparedStatement ps = con
> .prepareStatement("update Decimal_Tab set MAX_VAL=?");
> ps.setBigDecimal(1, max_param);
> ps.executeUpdate();
> ps.close();
> ps = null;
> con.close();
> con = null;
>   }
> {code}
> More details are being added soon ...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (DERBY-7160) Why do we see test failure/regression cause ERROR 22003: The resulting value is outside the range for the data type DECIMAL/NUMERIC(30,15)



 [ 
https://issues.apache.org/jira/browse/DERBY-7160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard N. Hillegas resolved DERBY-7160.

Resolution: Not A Problem

Resolving this issue. I see no evidence of a regression in Derby's behavior.

> Why do we see test failure/regression cause ERROR 22003: The resulting value 
> is outside the range for the data type DECIMAL/NUMERIC(30,15)
> --
>
> Key: DERBY-7160
> URL: https://issues.apache.org/jira/browse/DERBY-7160
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.17.1.0
>Reporter: Scott Marlow
>Priority: Major
> Fix For: 10.17.1.1
>
> Attachments: DERBY_7160-1.java, DERBY_7160.java
>
>
> This may be a regression or maybe a design change, not sure of which as the 
> same tests pass for us on Java SE 11/17 with 
> https://dlcdn.apache.org//db/derby/db-derby-10.15.2.0/db-derby-10.15.2.0-bin.zip.
> We are seeing a JDBC TCK test failure (Jakarta EE 10 TCK) when testing 
> against [https://db.apache.org/derby/releases/release-10_17_1_0.cgi] on java 
> 21 with the external project [https://github.com/wildfly/wildfly] that I 
> contribute to.
> I marked this issue as a bug but I really have no idea where the bug is.  The 
> JDBC test that is failing is 
> [https://github.com/jakartaee/platform-tck/blob/10.0.x/src/com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#L968]
>  when run on Java 21 with 10.17.1.0.
> The failure is:
> {quote}
> Caused by: ERROR 22003: The resulting value is outside the range for the data 
> type DECIMAL/NUMERIC(30,15).
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.completeExecute(ClientStatement.java:1868)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:323)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:107)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:84)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:193)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.readExecuteCall(ClientStatement.java:1831)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.flowExecute(ClientPreparedStatement.java:2180)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdateX(ClientPreparedStatement.java:410)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:396)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) ... 16 more
> {quote}
>  
> The called stored procedure source is at 
> https://github.com/jakartaee/platform-tck/blob/10.0.x/sql/derby/derby.ddl.sprocs.sql#L224
>  which contains:
> {quote}
> create procedure Decimal_In_Max (in MAX_PARAM DECIMAL(30,15)) language java 
> external name 'com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max' parameter 
> style java;
> {quote}
> The referenced com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max contains:
> {code}
> Connection con = DriverManager.getConnection("jdbc:default:connection");
> PreparedStatement ps = con
> .prepareStatement("update Decimal_Tab set MAX_VAL=?");
> ps.setBigDecimal(1, max_param);
> ps.executeUpdate();
> ps.close();
> ps = null;
> con.close();
> con = null;
>   }
> {code}
> More details are being added soon ...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7160) Why do we see test failure/regression cause ERROR 22003: The resulting value is outside the range for the data type DECIMAL/NUMERIC(30,15)



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

Richard N. Hillegas commented on DERBY-7160:


I modified DERBY_7160. Now it tests Derby's behavior on the String values 
Float.MAX_VALUE.toString(), 1.0E15, 9.999E14. Here is the program's 
behavior on Java 11, 17, and 21 and Derby 10.15.2.0 and 10.17.1.0:

{noformat}
mainline (21) > . switchVM 11
mainline (11) > runjavaExperimental 
/Users/rhillegas/derby/upgradeReleases/10.15.2.0 DERBY_7160
Java 11, Derby 10.15
Experiment Float.MAX_VALUE : Float = 3.4028235E38...
Caught exception java.sql.SQLDataException with message: The resulting 
value is outside the range for the data type DECIMAL/NUMERIC(30,15).
Experiment 1.0E15 : Float = 9.999E14...
DECIMAL_IN_MAX received value 99986991104.000
Experiment succeeded.
Experiment 9.999E14 : Float = 9.999E14...
DECIMAL_IN_MAX received value 99986991104.000
Experiment succeeded.

mainline (11) > . switchVM 17
mainline (17) > runjavaExperimental 
/Users/rhillegas/derby/upgradeReleases/10.15.2.0 DERBY_7160
Java 17, Derby 10.15
Experiment Float.MAX_VALUE : Float = 3.4028235E38...
Caught exception java.sql.SQLDataException with message: The resulting 
value is outside the range for the data type DECIMAL/NUMERIC(30,15).
Experiment 1.0E15 : Float = 9.999E14...
DECIMAL_IN_MAX received value 99986991104.000
Experiment succeeded.
Experiment 9.999E14 : Float = 9.999E14...
DECIMAL_IN_MAX received value 99986991104.000
Experiment succeeded.

mainline (17) > . switchVM 21
mainline (21) > runjavaExperimental 
/Users/rhillegas/derby/upgradeReleases/10.15.2.0 DERBY_7160
Java 21, Derby 10.15
Experiment Float.MAX_VALUE : Float = 3.4028235E38...
Caught exception java.sql.SQLDataException with message: The resulting 
value is outside the range for the data type DECIMAL/NUMERIC(30,15).
Experiment 1.0E15 : Float = 1.0E15...
DECIMAL_IN_MAX received value 99986991104.000
Experiment succeeded.
Experiment 9.999E14 : Float = 1.0E15...
DECIMAL_IN_MAX received value 99986991104.000
Experiment succeeded.

mainline (21) > runjavaExperimental 
/Users/rhillegas/derby/upgradeReleases/10.17.1.0 DERBY_7160
Java 21, Derby 10.17
Experiment Float.MAX_VALUE : Float = 3.4028235E38...
Caught exception java.sql.SQLDataException with message: The resulting 
value is outside the range for the data type DECIMAL/NUMERIC(30,15).
Experiment 1.0E15 : Float = 1.0E15...
DECIMAL_IN_MAX received value 99986991104.000
Experiment succeeded.
Experiment 9.999E14 : Float = 1.0E15...
DECIMAL_IN_MAX received value 99986991104.000
Experiment succeeded.
{noformat}

Derby's behavior does not change across different JVMs and different Derby 
releases. The only change is the behavior of Float.toString(), which changed in 
Java 21.


> Why do we see test failure/regression cause ERROR 22003: The resulting value 
> is outside the range for the data type DECIMAL/NUMERIC(30,15)
> --
>
> Key: DERBY-7160
> URL: https://issues.apache.org/jira/browse/DERBY-7160
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.17.1.0
>Reporter: Scott Marlow
>Priority: Major
> Fix For: 10.17.1.1
>
> Attachments: DERBY_7160-1.java, DERBY_7160.java
>
>
> This may be a regression or maybe a design change, not sure of which as the 
> same tests pass for us on Java SE 11/17 with 
> https://dlcdn.apache.org//db/derby/db-derby-10.15.2.0/db-derby-10.15.2.0-bin.zip.
> We are seeing a JDBC TCK test failure (Jakarta EE 10 TCK) when testing 
> against [https://db.apache.org/derby/releases/release-10_17_1_0.cgi] on java 
> 21 with the external project [https://github.com/wildfly/wildfly] that I 
> contribute to.
> I marked this issue as a bug but I really have no idea where the bug is.  The 
> JDBC test that is failing is 
> [https://github.com/jakartaee/platform-tck/blob/10.0.x/src/com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#L968]
>  when run on Java 21 with 10.17.1.0.
> The failure is:
> {quote}
> Caused by: ERROR 22003: The resulting value is outside the range for the data 
> type DECIMAL/NUMERIC(30,15).
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.completeExecute(ClientStatement.java:1868)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
>

[jira] [Updated] (DERBY-7160) Why do we see test failure/regression cause ERROR 22003: The resulting value is outside the range for the data type DECIMAL/NUMERIC(30,15)



 [ 
https://issues.apache.org/jira/browse/DERBY-7160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard N. Hillegas updated DERBY-7160:
---
Attachment: DERBY_7160-1.java

> Why do we see test failure/regression cause ERROR 22003: The resulting value 
> is outside the range for the data type DECIMAL/NUMERIC(30,15)
> --
>
> Key: DERBY-7160
> URL: https://issues.apache.org/jira/browse/DERBY-7160
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.17.1.0
>Reporter: Scott Marlow
>Priority: Major
> Fix For: 10.17.1.1
>
> Attachments: DERBY_7160-1.java, DERBY_7160.java
>
>
> This may be a regression or maybe a design change, not sure of which as the 
> same tests pass for us on Java SE 11/17 with 
> https://dlcdn.apache.org//db/derby/db-derby-10.15.2.0/db-derby-10.15.2.0-bin.zip.
> We are seeing a JDBC TCK test failure (Jakarta EE 10 TCK) when testing 
> against [https://db.apache.org/derby/releases/release-10_17_1_0.cgi] on java 
> 21 with the external project [https://github.com/wildfly/wildfly] that I 
> contribute to.
> I marked this issue as a bug but I really have no idea where the bug is.  The 
> JDBC test that is failing is 
> [https://github.com/jakartaee/platform-tck/blob/10.0.x/src/com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#L968]
>  when run on Java 21 with 10.17.1.0.
> The failure is:
> {quote}
> Caused by: ERROR 22003: The resulting value is outside the range for the data 
> type DECIMAL/NUMERIC(30,15).
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.completeExecute(ClientStatement.java:1868)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:323)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:107)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:84)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:193)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.readExecuteCall(ClientStatement.java:1831)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.flowExecute(ClientPreparedStatement.java:2180)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdateX(ClientPreparedStatement.java:410)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:396)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) ... 16 more
> {quote}
>  
> The called stored procedure source is at 
> https://github.com/jakartaee/platform-tck/blob/10.0.x/sql/derby/derby.ddl.sprocs.sql#L224
>  which contains:
> {quote}
> create procedure Decimal_In_Max (in MAX_PARAM DECIMAL(30,15)) language java 
> external name 'com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max' parameter 
> style java;
> {quote}
> The referenced com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max contains:
> {code}
> Connection con = DriverManager.getConnection("jdbc:default:connection");
> PreparedStatement ps = con
> .prepareStatement("update Decimal_Tab set MAX_VAL=?");
> ps.setBigDecimal(1, max_param);
> ps.executeUpdate();
> ps.close();
> ps = null;
> con.close();
> con = null;
>   }
> {code}
> More details are being added soon ...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7160) Why do we see test failure/regression cause ERROR 22003: The resulting value is outside the range for the data type DECIMAL/NUMERIC(30,15)



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

Scott Marlow commented on DERBY-7160:
-

https://github.com/jakartaee/platform-tck/issues/1260 is for challenging the 
failing tests.

[~rhillegas] I think that this issue can be closed now.  Do you agree?

> Why do we see test failure/regression cause ERROR 22003: The resulting value 
> is outside the range for the data type DECIMAL/NUMERIC(30,15)
> --
>
> Key: DERBY-7160
> URL: https://issues.apache.org/jira/browse/DERBY-7160
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.17.1.0
>Reporter: Scott Marlow
>Priority: Major
> Fix For: 10.17.1.1
>
> Attachments: DERBY_7160.java
>
>
> This may be a regression or maybe a design change, not sure of which as the 
> same tests pass for us on Java SE 11/17 with 
> https://dlcdn.apache.org//db/derby/db-derby-10.15.2.0/db-derby-10.15.2.0-bin.zip.
> We are seeing a JDBC TCK test failure (Jakarta EE 10 TCK) when testing 
> against [https://db.apache.org/derby/releases/release-10_17_1_0.cgi] on java 
> 21 with the external project [https://github.com/wildfly/wildfly] that I 
> contribute to.
> I marked this issue as a bug but I really have no idea where the bug is.  The 
> JDBC test that is failing is 
> [https://github.com/jakartaee/platform-tck/blob/10.0.x/src/com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#L968]
>  when run on Java 21 with 10.17.1.0.
> The failure is:
> {quote}
> Caused by: ERROR 22003: The resulting value is outside the range for the data 
> type DECIMAL/NUMERIC(30,15).
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.completeExecute(ClientStatement.java:1868)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:323)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:107)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:84)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:193)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.readExecuteCall(ClientStatement.java:1831)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.flowExecute(ClientPreparedStatement.java:2180)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdateX(ClientPreparedStatement.java:410)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:396)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) ... 16 more
> {quote}
>  
> The called stored procedure source is at 
> https://github.com/jakartaee/platform-tck/blob/10.0.x/sql/derby/derby.ddl.sprocs.sql#L224
>  which contains:
> {quote}
> create procedure Decimal_In_Max (in MAX_PARAM DECIMAL(30,15)) language java 
> external name 'com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max' parameter 
> style java;
> {quote}
> The referenced com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max contains:
> {code}
> Connection con = DriverManager.getConnection("jdbc:default:connection");
> PreparedStatement ps = con
> .prepareStatement("update Decimal_Tab set MAX_VAL=?");
> ps.setBigDecimal(1, max_param);
> ps.executeUpdate();
> ps.close();
> ps = null;
> con.close();
> con = null;
>   }
> {code}
> More details are being added soon ...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7160) Why do we see test failure/regression cause ERROR 22003: The resulting value is outside the range for the data type DECIMAL/NUMERIC(30,15)



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

Scott Marlow commented on DERBY-7160:
-

Possible causes as mentioned in 
https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/topic/Pass.20Platform.20TCK.20jdbc.2Eee.2EcallStmt.20tests.20on.20Java.2021
 discussion (thanks Ladislav Thon!):

https://bugs.openjdk.org/browse/JDK-4511638 
https://github.com/openjdk/jdk/commit/72bcf2aa03d53b0f68eb07a902575b4e8628d859 
(OpenJDK 19 change).



> Why do we see test failure/regression cause ERROR 22003: The resulting value 
> is outside the range for the data type DECIMAL/NUMERIC(30,15)
> --
>
> Key: DERBY-7160
> URL: https://issues.apache.org/jira/browse/DERBY-7160
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.17.1.0
>Reporter: Scott Marlow
>Priority: Major
> Fix For: 10.17.1.1
>
> Attachments: DERBY_7160.java
>
>
> This may be a regression or maybe a design change, not sure of which as the 
> same tests pass for us on Java SE 11/17 with 
> https://dlcdn.apache.org//db/derby/db-derby-10.15.2.0/db-derby-10.15.2.0-bin.zip.
> We are seeing a JDBC TCK test failure (Jakarta EE 10 TCK) when testing 
> against [https://db.apache.org/derby/releases/release-10_17_1_0.cgi] on java 
> 21 with the external project [https://github.com/wildfly/wildfly] that I 
> contribute to.
> I marked this issue as a bug but I really have no idea where the bug is.  The 
> JDBC test that is failing is 
> [https://github.com/jakartaee/platform-tck/blob/10.0.x/src/com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#L968]
>  when run on Java 21 with 10.17.1.0.
> The failure is:
> {quote}
> Caused by: ERROR 22003: The resulting value is outside the range for the data 
> type DECIMAL/NUMERIC(30,15).
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.completeExecute(ClientStatement.java:1868)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:323)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:107)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:84)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:193)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.readExecuteCall(ClientStatement.java:1831)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.flowExecute(ClientPreparedStatement.java:2180)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdateX(ClientPreparedStatement.java:410)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:396)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) ... 16 more
> {quote}
>  
> The called stored procedure source is at 
> https://github.com/jakartaee/platform-tck/blob/10.0.x/sql/derby/derby.ddl.sprocs.sql#L224
>  which contains:
> {quote}
> create procedure Decimal_In_Max (in MAX_PARAM DECIMAL(30,15)) language java 
> external name 'com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max' parameter 
> style java;
> {quote}
> The referenced com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max contains:
> {code}
> Connection con = DriverManager.getConnection("jdbc:default:connection");
> PreparedStatement ps = con
> .prepareStatement("update Decimal_Tab set MAX_VAL=?");
> ps.setBigDecimal(1, max_param);
> ps.executeUpdate();
> ps.close();
> ps = null;
> con.close();
> con = null;
>   }
> {code}
> More details are being added soon ...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7160) Why do we see test failure/regression cause ERROR 22003: The resulting value is outside the range for the data type DECIMAL/NUMERIC(30,15)



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

Scott Marlow commented on DERBY-7160:
-

Updated test:
{code}
class FloatTest {

public static void main(String[] args) {
String smaxStringVal = "999";

System.out.println("  smaxStringVal = " + smaxStringVal + " float = " + 
new Float(smaxStringVal));

System.out.println("  smaxStringVal = " + smaxStringVal + " float = " + 
Float.parseFloat(smaxStringVal));
}
}
{code}

On Java 17:
{quote}
  smaxStringVal = 999 float = 9.999E14
  smaxStringVal = 999 float = 9.999E14
{quote}

On Java 21:
{quote}
smaxStringVal = 999 float = 1.0E15
smaxStringVal = 999 float = 1.0E15
{quote}

> Why do we see test failure/regression cause ERROR 22003: The resulting value 
> is outside the range for the data type DECIMAL/NUMERIC(30,15)
> --
>
> Key: DERBY-7160
> URL: https://issues.apache.org/jira/browse/DERBY-7160
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.17.1.0
>Reporter: Scott Marlow
>Priority: Major
> Fix For: 10.17.1.1
>
> Attachments: DERBY_7160.java
>
>
> This may be a regression or maybe a design change, not sure of which as the 
> same tests pass for us on Java SE 11/17 with 
> https://dlcdn.apache.org//db/derby/db-derby-10.15.2.0/db-derby-10.15.2.0-bin.zip.
> We are seeing a JDBC TCK test failure (Jakarta EE 10 TCK) when testing 
> against [https://db.apache.org/derby/releases/release-10_17_1_0.cgi] on java 
> 21 with the external project [https://github.com/wildfly/wildfly] that I 
> contribute to.
> I marked this issue as a bug but I really have no idea where the bug is.  The 
> JDBC test that is failing is 
> [https://github.com/jakartaee/platform-tck/blob/10.0.x/src/com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#L968]
>  when run on Java 21 with 10.17.1.0.
> The failure is:
> {quote}
> Caused by: ERROR 22003: The resulting value is outside the range for the data 
> type DECIMAL/NUMERIC(30,15).
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.completeExecute(ClientStatement.java:1868)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:323)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:107)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:84)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:193)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.readExecuteCall(ClientStatement.java:1831)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.flowExecute(ClientPreparedStatement.java:2180)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdateX(ClientPreparedStatement.java:410)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:396)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) ... 16 more
> {quote}
>  
> The called stored procedure source is at 
> https://github.com/jakartaee/platform-tck/blob/10.0.x/sql/derby/derby.ddl.sprocs.sql#L224
>  which contains:
> {quote}
> create procedure Decimal_In_Max (in MAX_PARAM DECIMAL(30,15)) language java 
> external name 'com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max' parameter 
> style java;
> {quote}
> The referenced com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max contains:
> {code}
> Connection con = DriverManager.getConnection("jdbc:default:connection");
> PreparedStatement ps = con
> .prepareStatement("update Decimal_Tab set MAX_VAL=?");
> ps.setBigDecimal(1, max_param);
> ps.executeUpdate();
> ps.close();
> ps = null;
> con.close();
> con = null;
>   }
> {code}
> More details are being added soon ...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7160) Why do we see test failure/regression cause ERROR 22003: The resulting value is outside the range for the data type DECIMAL/NUMERIC(30,15)



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

Scott Marlow commented on DERBY-7160:
-

>From 
>https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Float.html#%3Cinit%3E(java.lang.String)
{quote}
Deprecated, for removal: This API element is subject to removal in a future 
version.
It is rarely appropriate to use this constructor. Use parseFloat(String) to 
convert a string to a float primitive, or use valueOf(String) to convert a 
string to a Float object.
{quote}

Also, when running the FloatTest on Java 17, output is:
{quote}
smaxStringVal = 999 float = 9.999E14
{quote}

On Java 21:
{quote}
java FloatTest
  smaxStringVal = 999 float = 1.0E15
{quote}

I get the same results from:
{code}
 System.out.println("  smaxStringVal = " + smaxStringVal + " float = " + 
Float.parseFloat(smaxStringVal))
{code}

  

> Why do we see test failure/regression cause ERROR 22003: The resulting value 
> is outside the range for the data type DECIMAL/NUMERIC(30,15)
> --
>
> Key: DERBY-7160
> URL: https://issues.apache.org/jira/browse/DERBY-7160
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.17.1.0
>Reporter: Scott Marlow
>Priority: Major
> Fix For: 10.17.1.1
>
> Attachments: DERBY_7160.java
>
>
> This may be a regression or maybe a design change, not sure of which as the 
> same tests pass for us on Java SE 11/17 with 
> https://dlcdn.apache.org//db/derby/db-derby-10.15.2.0/db-derby-10.15.2.0-bin.zip.
> We are seeing a JDBC TCK test failure (Jakarta EE 10 TCK) when testing 
> against [https://db.apache.org/derby/releases/release-10_17_1_0.cgi] on java 
> 21 with the external project [https://github.com/wildfly/wildfly] that I 
> contribute to.
> I marked this issue as a bug but I really have no idea where the bug is.  The 
> JDBC test that is failing is 
> [https://github.com/jakartaee/platform-tck/blob/10.0.x/src/com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#L968]
>  when run on Java 21 with 10.17.1.0.
> The failure is:
> {quote}
> Caused by: ERROR 22003: The resulting value is outside the range for the data 
> type DECIMAL/NUMERIC(30,15).
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.completeExecute(ClientStatement.java:1868)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:323)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:107)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:84)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:193)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.readExecuteCall(ClientStatement.java:1831)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.flowExecute(ClientPreparedStatement.java:2180)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdateX(ClientPreparedStatement.java:410)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:396)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) ... 16 more
> {quote}
>  
> The called stored procedure source is at 
> https://github.com/jakartaee/platform-tck/blob/10.0.x/sql/derby/derby.ddl.sprocs.sql#L224
>  which contains:
> {quote}
> create procedure Decimal_In_Max (in MAX_PARAM DECIMAL(30,15)) language java 
> external name 'com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max' parameter 
> style java;
> {quote}
> The referenced com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max contains:
> {code}
> Connection con = DriverManager.getConnection("jdbc:default:connection");
> PreparedStatement ps = con
> .prepareStatement("update Decimal_Tab set MAX_VAL=?");
> ps.setBigDecimal(1, max_param);
> ps.executeUpdate();
> ps.close();
> ps = null;
> con.close();
> con = null;
>   }
> {code}
>

[jira] [Commented] (DERBY-7160) Why do we see test failure/regression cause ERROR 22003: The resulting value is outside the range for the data type DECIMAL/NUMERIC(30,15)



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

Scott Marlow commented on DERBY-7160:
-

Interesting, when I compiled a local test with Java 17 or Java 21 I see:

{quote}
javac FloatTest.java 
FloatTest.java:6: warning: [removal] Float(String) in Float has been deprecated 
and marked for removal
System.out.println("  smaxStringVal = " + smaxStringVal + " float = " + 
new Float(smaxStringVal));
{quote}

{code}
class FloatTest {

public static void main(String[] args) {
String smaxStringVal = "999";

System.out.println("  smaxStringVal = " + smaxStringVal + " float = " + 
new Float(smaxStringVal));
}
}
{code}

I wonder if Java 21 changed something related to the future removal of the 
Float(String) constructor.

> Why do we see test failure/regression cause ERROR 22003: The resulting value 
> is outside the range for the data type DECIMAL/NUMERIC(30,15)
> --
>
> Key: DERBY-7160
> URL: https://issues.apache.org/jira/browse/DERBY-7160
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.17.1.0
>Reporter: Scott Marlow
>Priority: Major
> Fix For: 10.17.1.1
>
> Attachments: DERBY_7160.java
>
>
> This may be a regression or maybe a design change, not sure of which as the 
> same tests pass for us on Java SE 11/17 with 
> https://dlcdn.apache.org//db/derby/db-derby-10.15.2.0/db-derby-10.15.2.0-bin.zip.
> We are seeing a JDBC TCK test failure (Jakarta EE 10 TCK) when testing 
> against [https://db.apache.org/derby/releases/release-10_17_1_0.cgi] on java 
> 21 with the external project [https://github.com/wildfly/wildfly] that I 
> contribute to.
> I marked this issue as a bug but I really have no idea where the bug is.  The 
> JDBC test that is failing is 
> [https://github.com/jakartaee/platform-tck/blob/10.0.x/src/com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#L968]
>  when run on Java 21 with 10.17.1.0.
> The failure is:
> {quote}
> Caused by: ERROR 22003: The resulting value is outside the range for the data 
> type DECIMAL/NUMERIC(30,15).
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.completeExecute(ClientStatement.java:1868)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:323)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:107)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:84)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:193)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.readExecuteCall(ClientStatement.java:1831)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.flowExecute(ClientPreparedStatement.java:2180)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdateX(ClientPreparedStatement.java:410)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:396)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) ... 16 more
> {quote}
>  
> The called stored procedure source is at 
> https://github.com/jakartaee/platform-tck/blob/10.0.x/sql/derby/derby.ddl.sprocs.sql#L224
>  which contains:
> {quote}
> create procedure Decimal_In_Max (in MAX_PARAM DECIMAL(30,15)) language java 
> external name 'com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max' parameter 
> style java;
> {quote}
> The referenced com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max contains:
> {code}
> Connection con = DriverManager.getConnection("jdbc:default:connection");
> PreparedStatement ps = con
> .prepareStatement("update Decimal_Tab set MAX_VAL=?");
> ps.setBigDecimal(1, max_param);
> ps.executeUpdate();
> ps.close();
> ps = null;
> con.close();
> con = null;
>   }
> {code}
> More details are being added soon ...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7160) Why do we see test failure/regression cause ERROR 22003: The resulting value is outside the range for the data type DECIMAL/NUMERIC(30,15)



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

Scott Marlow commented on DERBY-7160:
-

Thanks [~rhillegas], I modified the JDBC TCK test locally to show the value 
used in 
https://github.com/jakartaee/platform-tck/blob/10.0.x/src/com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#L968:
{code}
System.out.println("xxx WFLY-18896 smaxStringVal = " + smaxStringVal + ", 
maxFloatVal = " + maxFloatVal);
{code}

When running on Java 21 with Derby 10.17 ^ shows:
{quote}
xxx WFLY-18896 smaxStringVal = 999, maxFloatVal = 1.0E15
{quote}

When running on Java 17 with Derby 10.15 ^ shows:
{quote}
xxx WFLY-18896 smaxStringVal = 999, maxFloatVal = 9.999E14
{quote}



> Why do we see test failure/regression cause ERROR 22003: The resulting value 
> is outside the range for the data type DECIMAL/NUMERIC(30,15)
> --
>
> Key: DERBY-7160
> URL: https://issues.apache.org/jira/browse/DERBY-7160
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.17.1.0
>Reporter: Scott Marlow
>Priority: Major
> Fix For: 10.17.1.1
>
> Attachments: DERBY_7160.java
>
>
> This may be a regression or maybe a design change, not sure of which as the 
> same tests pass for us on Java SE 11/17 with 
> https://dlcdn.apache.org//db/derby/db-derby-10.15.2.0/db-derby-10.15.2.0-bin.zip.
> We are seeing a JDBC TCK test failure (Jakarta EE 10 TCK) when testing 
> against [https://db.apache.org/derby/releases/release-10_17_1_0.cgi] on java 
> 21 with the external project [https://github.com/wildfly/wildfly] that I 
> contribute to.
> I marked this issue as a bug but I really have no idea where the bug is.  The 
> JDBC test that is failing is 
> [https://github.com/jakartaee/platform-tck/blob/10.0.x/src/com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#L968]
>  when run on Java 21 with 10.17.1.0.
> The failure is:
> {quote}
> Caused by: ERROR 22003: The resulting value is outside the range for the data 
> type DECIMAL/NUMERIC(30,15).
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.completeExecute(ClientStatement.java:1868)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:323)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:107)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:84)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:193)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.readExecuteCall(ClientStatement.java:1831)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.flowExecute(ClientPreparedStatement.java:2180)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdateX(ClientPreparedStatement.java:410)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:396)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) ... 16 more
> {quote}
>  
> The called stored procedure source is at 
> https://github.com/jakartaee/platform-tck/blob/10.0.x/sql/derby/derby.ddl.sprocs.sql#L224
>  which contains:
> {quote}
> create procedure Decimal_In_Max (in MAX_PARAM DECIMAL(30,15)) language java 
> external name 'com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max' parameter 
> style java;
> {quote}
> The referenced com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max contains:
> {code}
> Connection con = DriverManager.getConnection("jdbc:default:connection");
> PreparedStatement ps = con
> .prepareStatement("update Decimal_Tab set MAX_VAL=?");
> ps.setBigDecimal(1, max_param);
> ps.executeUpdate();
> ps.close();
> ps = null;
> con.close();
> con = null;
>   }
> {code}
> More details are being added soon ...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7160) Why do we see test failure/regression cause ERROR 22003: The resulting value is outside the range for the data type DECIMAL/NUMERIC(30,15)

2024-03-18 Thread Richard N. Hillegas (Jira)



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

Richard N. Hillegas commented on DERBY-7160:


I don't know of any changes to Derby which would be responsible for this 
result. It is hard to make much headway on narrowing down the problem until we 
know what the suspect Float value is.

The variable naming in callStmtClient16.testSetObject177() suggests that the 
procedure might be trying to stuff a Float.MAX_VALUE into an input procedure 
argument of type DECIMAL(30,15).

I am attaching a program (DERBY_7160) which runs that experiment. I compiled 
the program with JDK 11. Since Float.MAX_VALUE is outside the range of 
DECIMAL(30,15), the program fails with the following error:

{noformat}
Exception in thread "main" java.sql.SQLDataException: The resulting value is 
outside the range for the data type DECIMAL/NUMERIC(30,15).
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:84)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:230)
at 
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:431)
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.EmbedStatement.executeStatement(EmbedStatement.java:1436)
at 
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1709)
at 
org.apache.derby.impl.jdbc.EmbedCallableStatement.executeStatement(EmbedCallableStatement.java:134)
at 
org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(EmbedPreparedStatement.java:1394)
at DERBY_7160.main(DERBY_7160.java:23)
Caused by: ERROR 22003: The resulting value is outside the range for the data 
type DECIMAL/NUMERIC(30,15).
at 
org.apache.derby.shared.common.error.StandardException.newException(StandardException.java:300)
at 
org.apache.derby.shared.common.error.StandardException.newException(StandardException.java:295)
at org.apache.derby.iapi.types.SQLDecimal.setWidth(SQLDecimal.java:991)
at 
org.apache.derby.exe.ac3ea3c0fbx018ex53bfx4594x075b77200.g0(Unknown Source)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
org.apache.derby.impl.services.reflect.ReflectMethod.invoke(ReflectMethod.java:46)
at 
org.apache.derby.impl.sql.execute.CallStatementResultSet.open(CallStatementResultSet.java:75)
at 
org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:472)
at 
org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:351)
at 
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1344)
... 4 more
{noformat}

The experiment fails on the following platforms:

{noformat}

  JDKDERBY

  11 10.15.2.0
  17 10.15.2.0
  21 10.15.2.0
  21 10.17.1.0
{noformat}


> Why do we see test failure/regression cause ERROR 22003: The resulting value 
> is outside the range for the data type DECIMAL/NUMERIC(30,15)
> --
>
> Key: DERBY-7160
> URL: https://issues.apache.org/jira/browse/DERBY-7160
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.17.1.0
>Reporter: Scott Marlow
>Priority: Major
> Fix For: 10.17.1.1
>
> Attachments: DERBY_7160.java
>
>
> This may be a regression or maybe a design change, not sure of which as the 
> same tests pass for us on Java SE 11/17 with 
> https://dlcdn.apache.org//db/derby/db-derby-10.15.2.0/db-derby-10.15.2.0-bin.zip.
> We are seeing a JDBC TCK test failure (Jakarta EE 10 TCK) when testing 
> against [https://db.apache.org/derby/releases/release-10_17_1_0.cgi] on java 
> 21 with the external project [https://github.com/wildfly/wildfly] that I 
> contribute to.
> I marked this issue as a bug but I really have no idea where the bug is.  The 
> JDBC test that is failing is 
>

[jira] [Updated] (DERBY-7160) Why do we see test failure/regression cause ERROR 22003: The resulting value is outside the range for the data type DECIMAL/NUMERIC(30,15)

2024-03-18 Thread Richard N. Hillegas (Jira)



 [ 
https://issues.apache.org/jira/browse/DERBY-7160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard N. Hillegas updated DERBY-7160:
---
Attachment: DERBY_7160.java

> Why do we see test failure/regression cause ERROR 22003: The resulting value 
> is outside the range for the data type DECIMAL/NUMERIC(30,15)
> --
>
> Key: DERBY-7160
> URL: https://issues.apache.org/jira/browse/DERBY-7160
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.17.1.0
>Reporter: Scott Marlow
>Priority: Major
> Fix For: 10.17.1.1
>
> Attachments: DERBY_7160.java
>
>
> This may be a regression or maybe a design change, not sure of which as the 
> same tests pass for us on Java SE 11/17 with 
> https://dlcdn.apache.org//db/derby/db-derby-10.15.2.0/db-derby-10.15.2.0-bin.zip.
> We are seeing a JDBC TCK test failure (Jakarta EE 10 TCK) when testing 
> against [https://db.apache.org/derby/releases/release-10_17_1_0.cgi] on java 
> 21 with the external project [https://github.com/wildfly/wildfly] that I 
> contribute to.
> I marked this issue as a bug but I really have no idea where the bug is.  The 
> JDBC test that is failing is 
> [https://github.com/jakartaee/platform-tck/blob/10.0.x/src/com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#L968]
>  when run on Java 21 with 10.17.1.0.
> The failure is:
> {quote}
> Caused by: ERROR 22003: The resulting value is outside the range for the data 
> type DECIMAL/NUMERIC(30,15).
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.completeExecute(ClientStatement.java:1868)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:323)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:107)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:84)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:193)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientStatement.readExecuteCall(ClientStatement.java:1831)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.flowExecute(ClientPreparedStatement.java:2180)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdateX(ClientPreparedStatement.java:410)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
> org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:396)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) ... 16 more
> {quote}
>  
> The called stored procedure source is at 
> https://github.com/jakartaee/platform-tck/blob/10.0.x/sql/derby/derby.ddl.sprocs.sql#L224
>  which contains:
> {quote}
> create procedure Decimal_In_Max (in MAX_PARAM DECIMAL(30,15)) language java 
> external name 'com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max' parameter 
> style java;
> {quote}
> The referenced com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max contains:
> {code}
> Connection con = DriverManager.getConnection("jdbc:default:connection");
> PreparedStatement ps = con
> .prepareStatement("update Decimal_Tab set MAX_VAL=?");
> ps.setBigDecimal(1, max_param);
> ps.executeUpdate();
> ps.close();
> ps = null;
> con.close();
> con = null;
>   }
> {code}
> More details are being added soon ...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (DERBY-7160) Why do we see test failure/regression cause ERROR 22003: The resulting value is outside the range for the data type DECIMAL/NUMERIC(30,15)

2024-03-18 Thread Scott Marlow (Jira)



 [ 
https://issues.apache.org/jira/browse/DERBY-7160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Marlow updated DERBY-7160:

Description: 
This may be a regression or maybe a design change, not sure of which as the 
same tests pass for us on Java SE 11/17 with 
https://dlcdn.apache.org//db/derby/db-derby-10.15.2.0/db-derby-10.15.2.0-bin.zip.

We are seeing a JDBC TCK test failure (Jakarta EE 10 TCK) when testing against 
[https://db.apache.org/derby/releases/release-10_17_1_0.cgi] on java 21 with 
the external project [https://github.com/wildfly/wildfly] that I contribute to.

I marked this issue as a bug but I really have no idea where the bug is.  The 
JDBC test that is failing is 
[https://github.com/jakartaee/platform-tck/blob/10.0.x/src/com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#L968]
 when run on Java 21 with 10.17.1.0.

The failure is:

{quote}

Caused by: ERROR 22003: The resulting value is outside the range for the data 
type DECIMAL/NUMERIC(30,15).
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.am.ClientStatement.completeExecute(ClientStatement.java:1868)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:323)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:107)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:84)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:193)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.am.ClientStatement.readExecuteCall(ClientStatement.java:1831)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.flowExecute(ClientPreparedStatement.java:2180)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdateX(ClientPreparedStatement.java:410)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:396)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) ... 16 more

{quote}

 

The called stored procedure source is at 
https://github.com/jakartaee/platform-tck/blob/10.0.x/sql/derby/derby.ddl.sprocs.sql#L224
 which contains:

{quote}
create procedure Decimal_In_Max (in MAX_PARAM DECIMAL(30,15)) language java 
external name 'com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max' parameter 
style java;
{quote}

The referenced com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max contains:
{code}

Connection con = DriverManager.getConnection("jdbc:default:connection");
PreparedStatement ps = con
.prepareStatement("update Decimal_Tab set MAX_VAL=?");

ps.setBigDecimal(1, max_param);
ps.executeUpdate();

ps.close();
ps = null;
con.close();
con = null;
  }
{code}

More details are being added soon ...

  was:
We are seeing a JDBC TCK test failure (Jakarta EE 10 TCK) when testing against 
[https://db.apache.org/derby/releases/release-10_17_1_0.cgi] on java 21 with 
the external project [https://github.com/wildfly/wildfly] that I contribute to.

I marked this issue as a bug but I really have no idea where the bug is.  The 
JDBC test that is failing is 
[https://github.com/jakartaee/platform-tck/blob/10.0.x/src/com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#L968]
 when run on Java 21 with 10.17.1.0.

The failure is:

{quote}

Caused by: ERROR 22003: The resulting value is outside the range for the data 
type DECIMAL/NUMERIC(30,15).
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.am.ClientStatement.completeExecute(ClientStatement.java:1868)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:323)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:107)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:84)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at

[jira] [Created] (DERBY-7160) Why do we see test failure/regression cause ERROR 22003: The resulting value is outside the range for the data type DECIMAL/NUMERIC(30,15)

2024-03-18 Thread Scott Marlow (Jira)

Scott Marlow created DERBY-7160:
---

 Summary: Why do we see test failure/regression cause ERROR 22003: 
The resulting value is outside the range for the data type 
DECIMAL/NUMERIC(30,15)
 Key: DERBY-7160
 URL: https://issues.apache.org/jira/browse/DERBY-7160
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.17.1.0
Reporter: Scott Marlow
 Fix For: 10.17.1.1


We are seeing a JDBC TCK test failure (Jakarta EE 10 TCK) when testing against 
[https://db.apache.org/derby/releases/release-10_17_1_0.cgi] on java 21 with 
the external project [https://github.com/wildfly/wildfly] that I contribute to.

I marked this issue as a bug but I really have no idea where the bug is.  The 
JDBC test that is failing is 
[https://github.com/jakartaee/platform-tck/blob/10.0.x/src/com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#L968]
 when run on Java 21 with 10.17.1.0.

The failure is:

{quote}

Caused by: ERROR 22003: The resulting value is outside the range for the data 
type DECIMAL/NUMERIC(30,15).
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.am.ClientStatement.completeExecute(ClientStatement.java:1868)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:323)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:107)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:84)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:193)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.am.ClientStatement.readExecuteCall(ClientStatement.java:1831)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.flowExecute(ClientPreparedStatement.java:2180)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdateX(ClientPreparedStatement.java:410)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at 
org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:396)
\u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) ... 16 more

{quote}

 

The called stored procedure source is at 
https://github.com/jakartaee/platform-tck/blob/10.0.x/sql/derby/derby.ddl.sprocs.sql#L224
 which contains:

{quote}
create procedure Decimal_In_Max (in MAX_PARAM DECIMAL(30,15)) language java 
external name 'com.sun.ts.lib.tests.jdbc.CS_Procs.Decimal_In_Max' parameter 
style java;
{quote}

The referenced Java code contains:
{code}

Connection con = DriverManager.getConnection("jdbc:default:connection");
PreparedStatement ps = con
.prepareStatement("update Decimal_Tab set MAX_VAL=?");

ps.setBigDecimal(1, max_param);
ps.executeUpdate();

ps.close();
ps = null;
con.close();
con = null;
  }
{code}

This may be a regression or maybe a design change, not sure of which.

More details are being added soon ...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationSchemeImpl

2024-03-02 Thread Richard N. Hillegas (Jira)



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

Richard N. Hillegas commented on DERBY-7147:


"It is showing as affected from "10.1.1.0  Up to (excluding) 10.17.1.0"

This is, technically, an accurate statement about the OFFICIAL derby releases. 
You must build your own UNOFFICIAL release if you need a fix-bearing set of 
Derby jars which run on Java LTS versions 8, 11, or 17. Your processes may need 
some work in order to accommodate unofficial software distributions.


> LDAP injection vulnerability in LDAPAuthenticationSchemeImpl
> 
>
> 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.1.0
>
> Attachments: LDAPauthenticationVulnerability.pdf, 
> 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] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationSchemeImpl

2024-03-01 Thread Mrudula Madiraju (Jira)



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

Mrudula Madiraju commented on DERBY-7147:
-

Hi [~rhillegas]   - I guess our scanners report it because it shows up in the 
NVD [https://nvd.nist.gov/vuln/detail/CVE-2022-46337] 

It is showing as affected from "10.1.1.0  Up to (excluding) 10.17.1.0"

If you are able to correct this as well, I _guess_ our scanners will be happy 

> LDAP injection vulnerability in LDAPAuthenticationSchemeImpl
> 
>
> 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.1.0
>
> Attachments: LDAPauthenticationVulnerability.pdf, 
> 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] [Comment Edited] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationSchemeImpl

2024-03-01 Thread Mrudula Madiraju (Jira)



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

Mrudula Madiraju edited comment on DERBY-7147 at 3/2/24 4:24 AM:
-

Hi [~rhillegas]   - I think our scanners report it because it shows up in the 
NVD [https://nvd.nist.gov/vuln/detail/CVE-2022-46337] 

It is showing as affected from "10.1.1.0  Up to (excluding) 10.17.1.0"

If you are able to correct this as well, I _guess_ our scanners will be happy 


was (Author: mrudulam):
Hi [~rhillegas]   - I guess our scanners report it because it shows up in the 
NVD [https://nvd.nist.gov/vuln/detail/CVE-2022-46337] 

It is showing as affected from "10.1.1.0  Up to (excluding) 10.17.1.0"

If you are able to correct this as well, I _guess_ our scanners will be happy 

> LDAP injection vulnerability in LDAPAuthenticationSchemeImpl
> 
>
> 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.1.0
>
> Attachments: LDAPauthenticationVulnerability.pdf, 
> 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] [Comment Edited] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationSchemeImpl

2024-03-01 Thread Richard N. Hillegas (Jira)



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

Richard N. Hillegas edited comment on DERBY-7147 at 3/1/24 5:52 PM:


I have verified that the fix has been applied to the head of the 10.14 branch: 
https://svn.apache.org/repos/asf/db/derby/code/branches/10.14

You can verify this yourself by looking for the string "7147" in 
https://svn.apache.org/repos/asf/db/derby/code/branches/10.14/java/engine/org/apache/derby/impl/jdbc/authentication/LDAPAuthenticationSchemeImpl.java

There is no branch named 10.14.3. Branch names are two part ids which have the 
form majorNumber.minorNumber.

To build a fix-bearing release off the head of the 10.14 branch, see the 
instructions in my comment dated 2024-01-24. Substitute "10.14" for every 
occurrence of "10.16" in those instructions.



was (Author: rhillegas):
I have verified that the fix has been applied to the head of the 10.14 branch: 
https://svn.apache.org/repos/asf/db/derby/code/branches/10.14

You can verify this yourself by looking for the string "DERBY-7147" in 
https://svn.apache.org/repos/asf/db/derby/code/branches/10.14/java/engine/org/apache/derby/impl/jdbc/authentication/LDAPAuthenticationSchemeImpl.java

There is no branch named 10.14.3. Branch names are two part ids which have the 
form majorNumber.minorNumber.

To build a fix-bearing release off the head of the 10.14 branch, see the 
instructions in my comment dated 2024-01-24. Substitute "10.14" for every 
occurrence of "10.16" in those instructions.


> LDAP injection vulnerability in LDAPAuthenticationSchemeImpl
> 
>
> 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.1.0
>
> Attachments: LDAPauthenticationVulnerability.pdf, 
> 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] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationSchemeImpl

2024-03-01 Thread Richard N. Hillegas (Jira)



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

Richard N. Hillegas commented on DERBY-7147:


I have verified that the fix has been applied to the head of the 10.14 branch: 
https://svn.apache.org/repos/asf/db/derby/code/branches/10.14

You can verify this yourself by looking for the string "DERBY-7147" in 
https://svn.apache.org/repos/asf/db/derby/code/branches/10.14/java/engine/org/apache/derby/impl/jdbc/authentication/LDAPAuthenticationSchemeImpl.java

There is no branch named 10.14.3. Branch names are two part ids which have the 
form majorNumber.minorNumber.

To build a fix-bearing release off the head of the 10.14 branch, see the 
instructions in my comment dated 2024-01-24. Substitute "10.14" for every 
occurrence of "10.16" in those instructions.


> LDAP injection vulnerability in LDAPAuthenticationSchemeImpl
> 
>
> 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.1.0
>
> Attachments: LDAPauthenticationVulnerability.pdf, 
> 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] [Comment Edited] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationSchemeImpl

2024-03-01 Thread ajay kumar (Jira)



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

ajay kumar edited comment on DERBY-7147 at 3/1/24 11:02 AM:


[~rhillegas] /[~julienlau] Can you please point me to the source code branch 
for 10.14.3 , which is having this fix . As this version is not released yet 
but I will build it my own from source code.

The branch url that I could find out is having (10.14.2.1) which does not have 
that fix . [https://svn.apache.org/repos/asf/db/derby/code/branches/10.14/]

 


was (Author: ajayk5):
[~rhillegas] /[~julienlau] Can you please point me to the source code branch 
for 10.14.3 , which is having this fix . As this version is not released yet 
but I will build it my own from source code.

The branch url that I could find out is having (10.14.2.1) which does not have 
that fix . [https://svn.apache.org/repos/asf/db/derby/code/branches/10.14/]

And any idea by when 10.14.3 would be released and available on maven central ?

> LDAP injection vulnerability in LDAPAuthenticationSchemeImpl
> 
>
> 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.1.0
>
> Attachments: LDAPauthenticationVulnerability.pdf, 
> 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] [Commented] (DERBY-7147) LDAP injection vulnerability in LDAPAuthenticationSchemeImpl

2024-03-01 Thread ajay kumar (Jira)



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

ajay kumar commented on DERBY-7147:
---

[~rhillegas] /[~julienlau] Can you please point me to the source code branch 
for 10.14.3 , which is having this fix . As this version is not released yet 
but I will build it my own from source code.

The branch url that I could find out is having (10.14.2.1) which does not have 
that fix . [https://svn.apache.org/repos/asf/db/derby/code/branches/10.14/]

And any idea by when 10.14.3 would be released and available on maven central ?

> LDAP injection vulnerability in LDAPAuthenticationSchemeImpl
> 
>
> 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.1.0
>
> Attachments: LDAPauthenticationVulnerability.pdf, 
> 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)

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

2024-02-28 Thread Rick Hillegas


Hey Craig,

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

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




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

Hi,

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

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

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

Thanks,
Craig


Begin forwarded message:

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

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

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


Craig L Russell
c...@apache.org

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

2024-02-27 Thread Craig Russell

Hi,

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

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

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

Thanks,
Craig

> Begin forwarded message:
> 
> From: "Michael Bouschen (Jira)" 
> Subject: [jira] [Comment Edited] (JDO-836) TCK: QueryCancel Test class fails
> Date: February 27, 2024 at 11:19:00 PST
> To: jdo-...@db.apache.org
> Reply-To: jdo-...@db.apache.org
> 
> I added some lof statement to check that query cancel is called after 
> query.execute has been called:
> 
> 22:14:11,040 (Query Executor) INFO  [org.apache.jdo.tck] - Start query 
> execute 1708809251037
> 22:14:12,038 (ForkJoinPool-1-worker-19) INFO  [org.apache.jdo.tck] - Start 
> query cancel 1708809252038
> 22:14:12,039 (ForkJoinPool-1-worker-19) INFO  [org.apache.jdo.tck] - End 
> query cancel   1708809252039
> 22:15:00,860 (Query Executor) INFO  [org.apache.jdo.tck] - End query execute  
>   1708809300860
> 22:15:00,861 (Query Executor) INFO  [org.apache.jdo.tck] - query execute took 
> 49823ms
> 

Craig L Russell
c...@apache.org

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

2024-02-20 Thread David Delabassee

Thanks for the update !

--David

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

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

On 2/20/24 12:00 AM, David Delabassee wrote:
> Welcome to the latest OpenJDK Quality Outreach update!
>
> The first JDK 22 Release Candidates builds are now available [1]. At this 
> stage, only P1 issues will still be evaluated. And with the JDK 22 General 
> Availability set for March 19th, it is now time to fully focus on JDK 23. At 
> the time of writing, one JEP has already been integrated in JDK 23, i.e., JEP 
> 455: 'Primitive Types in Patterns, instanceof, and switch (Preview)' [2]. But 
> new JEP candidates [3][4] have recently been announced, so things should 
> evolve rapidly.
>
> I'd like to thank those of you who have already provided feedback on the JDK 
> 22 EA builds. Feedback is always extremely useful, even more, when it comes 
> early in the development cycle. Another area where we need your help is Loom. 
> So, please make sure to check the heads-up below that discusses the so-called 
> Virtual Threads "pinning" issue.
>
> [1] https://openjdk.org/projects/jdk/22/
> [2] https://openjdk.org/jeps/455
> [3] https://openjdk.org/jeps/465
> [4] https://openjdk.org/jeps/466
>
>
> ## Heads-up: Virtual Threads “Pinning” Issue
>
> Virtual threads became a permanent feature in JDK 21. This feature has been 
> extremely well received by the Java ecosystem but there are still a few pain 
> points. Much has been written about the so-called "pinning" issue that arises 
> with synchronized methods or synchronized statements. The two most common 
> cases are (a) a virtual thread parks (ex. doing socket I/O) while in a 
> synchronized method, and (b) a virtual thread blocks entering a synchronized 
> method because the object's associated monitor is held by another thread. In 
> both cases, the underlying carrier/native thread is not "released" to do 
> other work. Performance and scalability may suffer and in some cases, 
> starvation and deadlock might happen. This recent "Virtual Threads Next 
> Steps" video [5] explains in more details the why's and discusses some 
> potential solutions.
>
> New Loom early-access builds haven been recently published [6]. Those Loom EA 
> builds have changes to the object monitor implementation that do not pin for 
> these two common cases. The Loom team needs your help to test these updated 
> object monitors with code that you know is using virtual threads and with 
> libraries that are heavily synchronized. The goal is to gauge both 
> reliability and performance.
>
> The simplest way to report an issue or feedback is to use the Loom mailing 
> list [7]. For the VM savvy, testing with both `-XX:LockingMode=1` (current 
> default) and `-XX:LockingMode=2` would be extremely helpful as that would 
> exercise the two locking modes currently implemented by the HotSpot VM.
>
> [5] 
> https://urldefense.com/v3/__https://inside.java/2024/02/17/virtual-threads-next-steps/__;!!ACWV5N9M2RV99hQ!NiRSpNaVWJPRXz_9xYmBgaBecMh8TpG-Zc-v_cNJfgb6XebXiveBTs8VWTXKaN00KMFmVIyLSbmICoWVD-UZsxUtvLKd$
> [6] 
> https://urldefense.com/v3/__https://jdk.java.net/loom/__;!!ACWV5N9M2RV99hQ!NiRSpNaVWJPRXz_9xYmBgaBecMh8TpG-Zc-v_cNJfgb6XebXiveBTs8VWTXKaN00KMFmVIyLSbmICoWVD-UZs2hd_OBY$
> [7] https://mail.openjdk.org/pipermail/loom-dev/
>
>
> ## JDK 22 Release Candidates
>
> The JDK 22 Release Candidate builds (builds 36) are available [8] and are 
> provided under the GNU General Public License v2, with the Classpath 
> Exception. The Release Notes are available here [9], and the javadocs here 
> [10].
>
> [8] 
> https://urldefense.com/v3/__https://jdk.java.net/22/__;!!ACWV5N9M2RV99hQ!NiRSpNaVWJPRXz_9xYmBgaBecMh8TpG-Zc-v_cNJfgb6XebXiveBTs8VWTXKaN00KMFmVIyLSbmICoWVD-UZsyPEpb4d$
> [9] 
>

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

2024-02-20 Thread Rick Hillegas

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

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

Welcome to the latest OpenJDK Quality Outreach update!

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

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

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

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

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

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

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

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

## JDK 22 Release Candidates

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

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

## JDK 23 Early-Access Builds

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

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

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

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

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

[jira] [Commented] (DERBY-7159) Make it possible to build and test Derby with Open JDK 22

2024-02-20 Thread Richard N. Hillegas (Jira)



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

Richard N. Hillegas commented on DERBY-7159:


Derby built cleanly (including javadoc) with the first release candidate for 
Open JDK 22 (build 22+36-2370). The tests ran cleanly with both the classpath 
and modulepath.

> Make it possible to build and test Derby with Open JDK 22
> -
>
> Key: DERBY-7159
> URL: https://issues.apache.org/jira/browse/DERBY-7159
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Affects Versions: 10.18.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7159-01-aa-addJdk22VM.diff
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

JDK 22 Release Candidates & Virtual Threads pinning heads-up

2024-02-20 Thread David Delabassee

Welcome to the latest OpenJDK Quality Outreach update!

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

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

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


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

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

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

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

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


## JDK 22 Release Candidates

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

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


## JDK 23 Early-Access Builds

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

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

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

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

[11] https://jdk.java.net/23/
[12] https://jdk.java.net/23/release-notes
[13] https://github.com/openjdk/jdk/compare/jdk-23+6...jdk-23+10


## JavaFX Early-Access Builds:

These are early access builds of the JavaFX 22 & 23 Runtime

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

2024-02-01 Thread Bart van der Bilt




On 2/1/24 00:51, Rick Hillegas wrote:
When I run fxmovierentals6-all.sql, I get a violation of a different 
foreign key than the one mentioned in the comment at the end of the 
script. I get this error:


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


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


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

TALENT_ID
---
0
1
2

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


No need for special tricks during data import now.

Thanks again for your help.

Best regards, Bart

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


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



It appears that you need to fix your data.

Hope this helps,
-Rick

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


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

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

Hi,

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


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




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


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


Import flow is (in ij):

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

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


Any help for a workaround or fix is highly appreciated.


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


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


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


Best regards, Bart



-Rick



Best regards,

Bart

[jira] [Commented] (DERBY-6303) Add ability to defer enforcement of unique indexes until transaction end.



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

Bart van der Bilt commented on DERBY-6303:
--

After fixing the data this works great :). Create schema, add foreign keys and 
import data last. Re-attached the corrected SQL files.

Not sure how to reproduce this.

> Add ability to defer enforcement of unique indexes until transaction end.
> -
>
> Key: DERBY-6303
> URL: https://issues.apache.org/jira/browse/DERBY-6303
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 10.11.1.1
>Reporter: Richard N. Hillegas
>Priority: Major
> Attachments: movierentals26.sql, movies_insert_fk7.sql
>
>
> Applications may need to defer the enforcement of unique indexes for the same 
> reasons that they need to defer the enforcement of unique constraints. See 
> DERBY-532.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (DERBY-6303) Add ability to defer enforcement of unique indexes until transaction end.



 [ 
https://issues.apache.org/jira/browse/DERBY-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bart van der Bilt updated DERBY-6303:
-
Attachment: (was: fxmovierentals6-all.sql)

> Add ability to defer enforcement of unique indexes until transaction end.
> -
>
> Key: DERBY-6303
> URL: https://issues.apache.org/jira/browse/DERBY-6303
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 10.11.1.1
>Reporter: Richard N. Hillegas
>Priority: Major
> Attachments: movierentals26.sql, movies_insert_fk7.sql
>
>
> Applications may need to defer the enforcement of unique indexes for the same 
> reasons that they need to defer the enforcement of unique constraints. See 
> DERBY-532.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (DERBY-6303) Add ability to defer enforcement of unique indexes until transaction end.



 [ 
https://issues.apache.org/jira/browse/DERBY-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bart van der Bilt updated DERBY-6303:
-
Attachment: movies_insert_fk7.sql

> Add ability to defer enforcement of unique indexes until transaction end.
> -
>
> Key: DERBY-6303
> URL: https://issues.apache.org/jira/browse/DERBY-6303
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 10.11.1.1
>Reporter: Richard N. Hillegas
>Priority: Major
> Attachments: movierentals26.sql, movies_insert_fk7.sql
>
>
> Applications may need to defer the enforcement of unique indexes for the same 
> reasons that they need to defer the enforcement of unique constraints. See 
> DERBY-532.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (DERBY-6303) Add ability to defer enforcement of unique indexes until transaction end.



 [ 
https://issues.apache.org/jira/browse/DERBY-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bart van der Bilt updated DERBY-6303:
-
Attachment: movierentals26.sql

> Add ability to defer enforcement of unique indexes until transaction end.
> -
>
> Key: DERBY-6303
> URL: https://issues.apache.org/jira/browse/DERBY-6303
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 10.11.1.1
>Reporter: Richard N. Hillegas
>Priority: Major
> Attachments: movierentals26.sql, movies_insert_fk7.sql
>
>
> Applications may need to defer the enforcement of unique indexes for the same 
> reasons that they need to defer the enforcement of unique constraints. See 
> DERBY-532.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (DERBY-6303) Add ability to defer enforcement of unique indexes until transaction end.