search

jakartaee / platform-tck

Jakartaee-tck
Other
127 stars 108 forks source link

TCK Challenge for JDBC TCK tests that convert String values like `999999999999999` to Float that fail on Java 21 #1260

Closed scottmarlow closed 2 months ago

scottmarlow commented 6 months ago

https://issues.redhat.com/browse/WFLY-18896 reported the following TCK test failures:

Finished Test: FAILED........com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#testSetObject177_from_appclient
Finished Test: FAILED........com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#testSetObject177_from_ejb
Finished Test: FAILED........com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#testSetObject177_from_jsp
Finished Test: FAILED........com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#testSetObject177_from_servlet
Finished Test: FAILED........com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#testSetObject179_from_appclient
Finished Test: FAILED........com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#testSetObject179_from_ejb
Finished Test: FAILED........com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#testSetObject179_from_jsp
Finished Test: FAILED........com/sun/ts/tests/jdbc/ee/callStmt/callStmt16/callStmtClient16.java#testSetObject179_from_servlet

Which led to issue https://issues.apache.org/jira/browse/DERBY-7160 to be opened and https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/topic/Pass.20Platform.20TCK.20jdbc.2Eee.2EcallStmt.20tests.20on.20Java.2021 chat discussion in which Ladislav Thon pointed to the https://bugs.openjdk.org/browse/JDK-4511638 issue that was fixed for Java 19 which looks like the likely change.

Echoing discussion from https://issues.apache.org/jira/browse/DERBY-7160:


// Test code that reproduces the different String to Float values
class FloatTest {

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

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

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

> Output on Java 17:
> 
>     smaxStringVal = 999999999999999 float = 9.9999999E14
>     smaxStringVal = 999999999999999 float = 9.9999999E14
> 
> Output on Java 21 (also same on Java 19):
> 
>     smaxStringVal = 999999999999999 float = 1.0E15
>     smaxStringVal = 999999999999999 float = 1.0E15
> 

The `jdbc/ee/callStmt/callStmt16/callStmtClient16.java#testSetObject177` test has used the Float value `9.9999999E14` for a long time but on Java 19+ we are seeing `1.0E15` used instead which leads to a test failure:

> \u001b[0m\u001b[0m12:39:19,517 INFO [stdout] (Thread-69) 12-01-2023 12:39:19: ERROR: java.sql.SQLDataException: The resulting value is outside the range for the data type DECIMAL/NUMERIC(30,15).
> \u001b[0m\u001b[0m12:39:19,517 INFO [stdout] (Thread-69) at org.apache.derby.client//org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:76)
> \u001b[0m\u001b[0m12:39:19,517 INFO [stdout] (Thread-69) at org.apache.derby.client//org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:325)
> \u001b[0m\u001b[0m12:39:19,517 INFO [stdout] (Thread-69) at org.apache.derby.client//org.apache.derby.client.am.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:405)
> \u001b[0m\u001b[0m12:39:19,517 INFO [stdout] (Thread-69) at org.jboss.ironjacamar.jdbcadapters@3.0.4.Final//org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537)
> \u001b[0m\u001b[0m12:39:19,518 INFO [stdout] (Thread-69) at deployment.callStmt16_appclient_vehicle.ear.callStmt16_appclient_vehicle_client.jar//com.sun.ts.tests.jdbc.ee.callStmt.callStmt16.callStmtClient16.testSetObject177(callStmtClient16.java:996)
> \u001b[0m\u001b[0m12:39:19,518 INFO [stdout] (Thread-69) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> \u001b[0m\u001b[0m12:39:19,518 INFO [stdout] (Thread-69) at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> \u001b[0m\u001b[0m12:39:19,519 INFO [stdout] (Thread-69) at deployment.callStmt16_appclient_vehicle.ear.callStmt16_appclient_vehicle_client.jar//com.sun.ts.lib.harness.EETest.run(EETest.java:596)
> \u001b[0m\u001b[0m12:39:19,520 INFO [stdout] (Thread-69) at deployment.callStmt16_appclient_vehicle.ear.callStmt16_appclient_vehicle_client.jar//com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:115)
> \u001b[0m\u001b[0m12:39:19,520 INFO [stdout] (Thread-69) at deployment.callStmt16_appclient_vehicle.ear.callStmt16_appclient_vehicle_client.jar//com.sun.ts.tests.common.vehicle.EmptyVehicleRunner.run(EmptyVehicleRunner.java:41)
> \u001b[0m\u001b[0m12:39:19,520 INFO [stdout] (Thread-69) at deployment.callStmt16_appclient_vehicle.ear.callStmt16_appclient_vehicle_client.jar//com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:105)
> \u001b[0m\u001b[0m12:39:19,520 INFO [stdout] (Thread-69) at deployment.callStmt16_appclient_vehicle.ear.callStmt16_appclient_vehicle_client.jar//com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:486)
> \u001b[0m\u001b[0m12:39:19,521 INFO [stdout] (Thread-69) at deployment.callStmt16_appclient_vehicle.ear.callStmt16_appclient_vehicle_client.jar//com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:209)
> \u001b[0m\u001b[0m12:39:19,523 INFO [stdout] (Thread-69) at deployment.callStmt16_appclient_vehicle.ear.callStmt16_appclient_vehicle_client.jar//com.sun.ts.lib.harness.EETest.run(EETest.java:285)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at deployment.callStmt16_appclient_vehicle.ear.callStmt16_appclient_vehicle_client.jar//com.sun.ts.tests.common.vehicle.VehicleClient.main(VehicleClient.java:37)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at org.jboss.as.appclient@30.0.1.Final-SNAPSHOT//org.jboss.as.appclient.service.ApplicationClientStartService$1.run(ApplicationClientStartService.java:89)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) at java.base/java.lang.Thread.run(Thread.java:1583)
> \u001b[0m\u001b[0m12:39:19,524 INFO [stdout] (Thread-69) 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
scottmarlow commented 6 months ago

@LanceAndersen (lead of the JDBC Specification) asked if we tried to modify the Decimal_Tab_Insert in the derby.dml.sql file to a value that works with both Java versions (e.g. 21 + 17/11). If there is such a value, we could change to that value. If there is no value that works with both, we should exclude the tests.

Note that the TCK dml/ddl files are intended to be modified as needed for the backend/platform.

grep -ri Decimal_Tab_Insert --include=*.sql sql/db2/db2.dml.sql:Decimal_Tab_Insert= insert into Decimal_Tab values(99999,0.000000000000001, null) sql/derby/derby.dml.sql:Decimal_Tab_Insert= insert into Decimal_Tab values(999999999999999,0.000000000000001, null) sql/mssqlserver/mssqlserver.dml.sql:Decimal_Tab_Insert= insert into Decimal_Tab values(999999999999999,0.000000000000001, null) sql/mysql/mysql.dml.sql:#Decimal_Tab_Insert= insert into Decimal_Tab values(999999999999999,0.000000000000001, null) sql/mysql/mysql.dml.sql:Decimal_Tab_Insert= insert into Decimal_Tab values(9999999999,0.0000000001, null) sql/oracle/oracle.dml.sql:Decimal_Tab_Insert= insert into Decimal_Tab values(999999999999999,0.000000000000001, null) sql/pointbase/pointbase.dml.sql:Decimal_Tab_Insert= insert into Decimal_Tab values(999999999999999,0.000000000000000, null) sql/postgresql/postgresql.dml.sql:#Decimal_Tab_Insert= insert into Decimal_Tab values(999999999999999,0.0000000001, null) sql/postgresql/postgresql.dml.sql:Decimal_Tab_Insert= insert into Decimal_Tab values(9999999999,0.0000000001, null) sql/sybase/sybase.dml.sql:Decimal_Tab_Insert= insert into Decimal_Tab values(999999999999999,0.000000000000001, null)

scottmarlow commented 5 months ago

I think that we will soon have another EE 10 Platform TCK release to address TCK challenges like this one. I haven't had time to research test changes related to this challenge and I likely will be heads down on EE 11 TCK test refactoring until that is further along (along with others).

So this is looking like something that we will need to exclude the tests for instead of correcting for EE 10. Perhaps the test correction could be made for EE 11 as we will soon hit the same issues there.

brideck commented 5 months ago

Thanks to some investigatory work by @mswatosh, we think that a value of 9999999999 should work with all of the relevant levels of Java. I'll be trying it out locally with Open Liberty at some point today or tomorrow.

scottmarlow commented 5 months ago

@LanceAndersen as per ^ we are trying to test with a change from 999999999999999 to instead use 9999999999 which I think meets the criteria that you mentioned as we think that value would work on different versions of Java. Any concerns with a change like that?

For easier reading, the problematic value is 999,999,999,999,999 and we will instead try using 9,999,999,999.

brideck commented 5 months ago

For the record, both Decimal_Tab (for test 177) and Numeric_Tab (for test 179) need to be updated, but this does seem to work for me with Open Liberty.

Assuming we get agreement from Lance, I can make that change. Both the 10.0.x and the tckrefactor branches?

scottmarlow commented 4 months ago

For the record, both Decimal_Tab (for test 177) and Numeric_Tab (for test 179) need to be updated, but this does seem to work for me with Open Liberty.

Assuming we get agreement from Lance, I can make that change. Both the 10.0.x and the tckrefactor branches?

@brideck

I think it is a Platform concern to deal with at this point based on the feedback that we have already received. Please do create (10.0.x + tckrefactor) pull requests when you have time for changing to 9999999999 (e.g. 9,999,999,999) to address this issue. I think that we will soon have other 10.0.x updates for Java 21 for the jstl tests so would be good to release a new EE 10 platform tck service release that addresses as many of these Java 21 problems as possible, including this TCK challenge. Thank you!

scottmarlow commented 3 months ago

@brideck I'll create a pull request for the JDBC change.

scottmarlow commented 3 months ago

This will be closed when an EE 10 Platform TCK release contains the merged fix.

scottmarlow commented 2 months ago

Addressed via https://download.eclipse.org/jakartaee/platform/10/jakarta-jakartaeetck-10.0.5.zip