[
https://issues.apache.org/jira/browse/DERBY-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463641
]
Myrna van Lunteren commented on DERBY-2224:
-------------------------------------------
Thx for the review!
re I18NImportExport.sql - the .tmp file shows why there is different behavior:
....
ij> LOCALIZEDDISPLAY ON;
ij> select * from tab1;
C1 |C2 |C3
-----------------------------------------------
JAVA ERROR: java.lang.NoSuchMethodError:
java/sql/ResultSet.getBigDecimal(II)Ljava/math/BigDecimal;
...
(twice).
re parameterMapping.java - the test does use the BigDecimalHandler utility
already, however, it ran into this:
---------
....
For setXXX() methods that pass an object, a null and valid values are checked
setByte() getBigDecimal=98.00000 was null false JDBC MATCH(OK)
setByte() as batch java.lang.NoSuchMethodError:
java/sql/PreparedStatement.setBigDecimal(ILjava/math/BigDecimal;)V
at org.apache.derby.iapi.types.SQLDecimal.setInto(SQLDecimal.java:600)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeBatchElement(EmbedPreparedStatement.java:1007)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeBatch(EmbedStatement.java:924)
at
org.apache.derbyTesting.functionTests.tests.jdbcapi.parameterMapping.setXXX(parameterMapping.java:1197)
at
org.apache.derbyTesting.functionTests.tests.jdbcapi.parameterMapping.main(parameterMapping.java:459)
-------------
So, the engine code calls some set/getBigDecimal methods.
re grantRevokeDDL.sql:
A while ago I created the original master-canon for j9_foundation because of
the failure, because (as was pointed out to me) triggers are not supported with
CDC/JSR169/j2ME, according to the documentation. I concluded at the time (based
on stack traces and watching the debugger) that this was because the engine
code for triggers uses a BigDecimal call (somewhere. If you want details, I can
backtrack, but it would take some time). Now that there is a
java.math.BigDecimal, apparently, that piece of code passes; and so it fails a
little further in the test.
In short, I was trying to get the tests to run cleanly even though there is
really a bit of an engine issue here.
> Test harness should support J2ME 1.1
> ------------------------------------
>
> Key: DERBY-2224
> URL: https://issues.apache.org/jira/browse/DERBY-2224
> Project: Derby
> Issue Type: Test
> Components: Test
> Affects Versions: 10.2.2.0, 10.3.0.0
> Reporter: Myrna van Lunteren
> Assigned To: Myrna van Lunteren
> Priority: Minor
> Attachments: DERBY_2224_harness.diff, DERBY_2224_tests.diff
>
>
> I would like to enable the 'old' test harness to support the new version of
> IBM's j2ME implementation, which is based on j2ME jdk spec version 1.1. This
> is available with a product named Websphere Everyplace Micro Edition 6.1.
> from IBM.
> We already support j9_foundation, which matches to j2ME jdk spec 1.0. I'd
> like to add j9_foundation11, which then matches to j2ME jdk spec 1.1.
> I'm proposing to switch my automated tests over to the newer version going
> forward, and to minimize complexity of the change, I'd like to make the
> canons reflect behavior of the new version. The differences are minimal.
> However, I want to be able to still run with the old (except where the
> results differ, failures would occur with the old version).
> One of the reasons for moving to the new version is that there is a bug with
> the older version in regards to security manager, preventing a smooth run of
> the junit tests, and I'd like to run all short-running tests (suites.All and
> derbyall) with at least one of the versions. Another reason is that the j2ME
> spec 1.0 is really old.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
