You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Stan Bradbury (JIRA)" <ji...@apache.org> on 2008/08/02 02:47:31 UTC
[jira] Created: (DERBY-3813) Derby tests for the existance of
BigDecimal methods toPlainString and bdPrecison but does not check if they
were found before using them.
Derby tests for the existance of BigDecimal methods toPlainString and bdPrecison but does not check if they were found before using them.
-----------------------------------------------------------------------------------------------------------------------------------------
Key: DERBY-3813
URL: https://issues.apache.org/jira/browse/DERBY-3813
Project: Derby
Issue Type: Bug
Affects Versions: 10.3.3.0
Environment: Using a VM that is a subset of Java 5 without full BigDecimal support
Reporter: Stan Bradbury
I received the following problem report:
Having failures running with our VM that is a subset of Java 5. Failure is with the handling of the BigDecimal class in the org.apache.derby.iapi.types.SQLDecimal class.
The SQLDecimal class does reflection to determine if the methods toPlainString and bdPrecison are present or not
private static final Method toPlainString;
private static final Method bdPrecision;
static {
Method m;
try {
m = BigDecimal.class.getMethod("toPlainString", null);
} catch (NoSuchMethodException e) {
m = null;
}
toPlainString = m;
try {
m = BigDecimal.class.getMethod("precision", null);
} catch (NoSuchMethodException e) {
m = null;
}
bdPrecision = m;
}
however, when it comes time to use them, it does not check whether it found the methods, but rather the JVM level, equating JVM specification level with method existence
public String getString()
{
BigDecimal localValue = getBigDecimal();
if (localValue == null)
return null;
else if (JVMInfo.JDK_ID < JVMInfo.J2SE_15)
return localValue.toString();
else
{
// use reflection so we can still compile using JDK1.4
// if we are prepared to require 1.5 to compile then this can be a direct call
try {
return (String) toPlainString.invoke(localValue, null);
} catch (IllegalAccessException e) {
and
private static int getWholeDigits(BigDecimal decimalValue)
{
/**
* if ONE > abs(value) then the number of whole digits is 0
*/
decimalValue = decimalValue.abs();
if (ONE.compareTo(decimalValue) == 1)
{
return 0;
}
if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
{
// use reflection so we can still compile using JDK1.4
// if we are prepared to require 1.5 to compile then this can be a
// direct call
try {
// precision is the number of digits in the unscaled value,
// subtracting the scale (positive or negative) will give the
// number of whole digits.
int precision = ((Integer) bdPrecision.invoke(decimalValue,
null)).intValue();
return precision - decimalValue.scale();
Since the JVM is claiming 1.5 specification, the code assumes the methods exist, and result in NullPointerExceptions at the low level Derby class, resulting in SQLExceptions thrown to the caller.
>>>> ***Created table: dish
***Created table: VNMEDICALRECORD
Fail to make the query to database:
java.lang.NullPointerException
at org.apache.derby.iapi.types.SQLDecimal.getString(Unknown Source)
at org.apache.derby.iapi.types.DataType.getTraceString(Unknown Source)
at org.apache.derby.impl.sql.GenericParameter.toString(Unknown Source)
at org.apache.derby.impl.sql.GenericParameterValueSet.toString(Unknown Source)
at org.apache.derby.impl.sql.conn.GenericStatementContext.appendErrorInfo(Unknown Source)
at org.apache.derby.iapi.services.context.ContextManager.cleanupOnError(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:175)
at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
at java.lang.Thread.run(Unknown Source)
Fail to close:
java.sql.SQLException: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:258)
at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
at java.lang.Thread.run(Unknown Source)
Caused by: ERROR X0Y67: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doRollback(Unknown Source)
at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userRollback(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.rollback(Unknown Source)
... 5 more
Making the following change would fix the problem of running on our VM
Instead of this test
if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
test if (toPlainString == null), or if (bdPrecision == null) or equivalent, this should achieved the same results
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3813) Derby tests for the existance of
BigDecimal methods toPlainString and bdPrecison but does not check if they
were found before using them.
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620315#action_12620315 ]
Kathey Marsden commented on DERBY-3813:
---------------------------------------
I plan to go ahead and check this in and backport to 10.4 and 10.3. I ran suites.All and derbyall with weme 6.1, jdk142, and jdk 1.6. I ran the repro with the jvm in question and saw the NullPointerException and saw it run clean with the fix, so this is likely to fix the problem for this particular case. That doesn't say anything for how Derby will run in general against a 1.5 subset.
> Derby tests for the existance of BigDecimal methods toPlainString and bdPrecison but does not check if they were found before using them.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3813
> URL: https://issues.apache.org/jira/browse/DERBY-3813
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.3.0
> Environment: Using a VM that is a subset of Java 5 without full BigDecimal support
> Reporter: Stan Bradbury
> Assignee: Kathey Marsden
> Attachments: DERBY-3813_diff.txt
>
>
> I received the following problem report:
> Having failures running with our VM that is a subset of Java 5. Failure is with the handling of the BigDecimal class in the org.apache.derby.iapi.types.SQLDecimal class.
> The SQLDecimal class does reflection to determine if the methods toPlainString and bdPrecison are present or not
> private static final Method toPlainString;
> private static final Method bdPrecision;
> static {
> Method m;
> try {
> m = BigDecimal.class.getMethod("toPlainString", null);
> } catch (NoSuchMethodException e) {
> m = null;
> }
> toPlainString = m;
> try {
> m = BigDecimal.class.getMethod("precision", null);
> } catch (NoSuchMethodException e) {
> m = null;
> }
> bdPrecision = m;
> }
> however, when it comes time to use them, it does not check whether it found the methods, but rather the JVM level, equating JVM specification level with method existence
> public String getString()
> {
> BigDecimal localValue = getBigDecimal();
> if (localValue == null)
> return null;
> else if (JVMInfo.JDK_ID < JVMInfo.J2SE_15)
> return localValue.toString();
> else
> {
> // use reflection so we can still compile using JDK1.4
> // if we are prepared to require 1.5 to compile then this can be a direct call
> try {
> return (String) toPlainString.invoke(localValue, null);
> } catch (IllegalAccessException e) {
> and
> private static int getWholeDigits(BigDecimal decimalValue)
> {
> /**
> * if ONE > abs(value) then the number of whole digits is 0
> */
> decimalValue = decimalValue.abs();
> if (ONE.compareTo(decimalValue) == 1)
> {
> return 0;
> }
>
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
> {
> // use reflection so we can still compile using JDK1.4
> // if we are prepared to require 1.5 to compile then this can be a
> // direct call
> try {
> // precision is the number of digits in the unscaled value,
> // subtracting the scale (positive or negative) will give the
> // number of whole digits.
> int precision = ((Integer) bdPrecision.invoke(decimalValue,
> null)).intValue();
> return precision - decimalValue.scale();
> Since the JVM is claiming 1.5 specification, the code assumes the methods exist, and result in NullPointerExceptions at the low level Derby class, resulting in SQLExceptions thrown to the caller.
> >>>> ***Created table: dish
> ***Created table: VNMEDICALRECORD
> Fail to make the query to database:
> java.lang.NullPointerException
> at org.apache.derby.iapi.types.SQLDecimal.getString(Unknown Source)
> at org.apache.derby.iapi.types.DataType.getTraceString(Unknown Source)
> at org.apache.derby.impl.sql.GenericParameter.toString(Unknown Source)
> at org.apache.derby.impl.sql.GenericParameterValueSet.toString(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericStatementContext.appendErrorInfo(Unknown Source)
> at org.apache.derby.iapi.services.context.ContextManager.cleanupOnError(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
> at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:175)
> at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
> at java.lang.Thread.run(Unknown Source)
> Fail to close:
> java.sql.SQLException: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
> at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
> at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:258)
> at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
> at java.lang.Thread.run(Unknown Source)
> Caused by: ERROR X0Y67: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doRollback(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userRollback(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.rollback(Unknown Source)
> ... 5 more
> Making the following change would fix the problem of running on our VM
> Instead of this test
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
> test if (toPlainString == null), or if (bdPrecision == null) or equivalent, this should achieved the same results
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3813) Derby tests for the existance of
BigDecimal methods toPlainString and bdPrecison but does not check if they
were found before using them.
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620964#action_12620964 ]
Daniel John Debrunner commented on DERBY-3813:
----------------------------------------------
The issue is that the format of the value issued by toString() changed from Java 1.4 to 1.5, an unusual incompatibility introduced into java.
Thus the code to determine precision from toString() works in 1.4 but will not work in 1.5, would have to use toPlainString() instead, but since 1.5 introduced a precision() method it makes most sense to use that in 1.5.
> Derby tests for the existance of BigDecimal methods toPlainString and bdPrecison but does not check if they were found before using them.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3813
> URL: https://issues.apache.org/jira/browse/DERBY-3813
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.3.0
> Environment: Using a VM that is a subset of Java 5 without full BigDecimal support
> Reporter: Stan Bradbury
> Assignee: Kathey Marsden
> Fix For: 10.3.3.1, 10.4.2.0, 10.5.0.0
>
> Attachments: DERBY-3813_diff.txt
>
>
> I received the following problem report:
> Having failures running with our VM that is a subset of Java 5. Failure is with the handling of the BigDecimal class in the org.apache.derby.iapi.types.SQLDecimal class.
> The SQLDecimal class does reflection to determine if the methods toPlainString and bdPrecison are present or not
> private static final Method toPlainString;
> private static final Method bdPrecision;
> static {
> Method m;
> try {
> m = BigDecimal.class.getMethod("toPlainString", null);
> } catch (NoSuchMethodException e) {
> m = null;
> }
> toPlainString = m;
> try {
> m = BigDecimal.class.getMethod("precision", null);
> } catch (NoSuchMethodException e) {
> m = null;
> }
> bdPrecision = m;
> }
> however, when it comes time to use them, it does not check whether it found the methods, but rather the JVM level, equating JVM specification level with method existence
> public String getString()
> {
> BigDecimal localValue = getBigDecimal();
> if (localValue == null)
> return null;
> else if (JVMInfo.JDK_ID < JVMInfo.J2SE_15)
> return localValue.toString();
> else
> {
> // use reflection so we can still compile using JDK1.4
> // if we are prepared to require 1.5 to compile then this can be a direct call
> try {
> return (String) toPlainString.invoke(localValue, null);
> } catch (IllegalAccessException e) {
> and
> private static int getWholeDigits(BigDecimal decimalValue)
> {
> /**
> * if ONE > abs(value) then the number of whole digits is 0
> */
> decimalValue = decimalValue.abs();
> if (ONE.compareTo(decimalValue) == 1)
> {
> return 0;
> }
>
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
> {
> // use reflection so we can still compile using JDK1.4
> // if we are prepared to require 1.5 to compile then this can be a
> // direct call
> try {
> // precision is the number of digits in the unscaled value,
> // subtracting the scale (positive or negative) will give the
> // number of whole digits.
> int precision = ((Integer) bdPrecision.invoke(decimalValue,
> null)).intValue();
> return precision - decimalValue.scale();
> Since the JVM is claiming 1.5 specification, the code assumes the methods exist, and result in NullPointerExceptions at the low level Derby class, resulting in SQLExceptions thrown to the caller.
> >>>> ***Created table: dish
> ***Created table: VNMEDICALRECORD
> Fail to make the query to database:
> java.lang.NullPointerException
> at org.apache.derby.iapi.types.SQLDecimal.getString(Unknown Source)
> at org.apache.derby.iapi.types.DataType.getTraceString(Unknown Source)
> at org.apache.derby.impl.sql.GenericParameter.toString(Unknown Source)
> at org.apache.derby.impl.sql.GenericParameterValueSet.toString(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericStatementContext.appendErrorInfo(Unknown Source)
> at org.apache.derby.iapi.services.context.ContextManager.cleanupOnError(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
> at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:175)
> at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
> at java.lang.Thread.run(Unknown Source)
> Fail to close:
> java.sql.SQLException: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
> at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
> at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:258)
> at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
> at java.lang.Thread.run(Unknown Source)
> Caused by: ERROR X0Y67: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doRollback(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userRollback(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.rollback(Unknown Source)
> ... 5 more
> Making the following change would fix the problem of running on our VM
> Instead of this test
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
> test if (toPlainString == null), or if (bdPrecision == null) or equivalent, this should achieved the same results
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3813) Derby tests for the existance of
BigDecimal methods toPlainString and bdPrecison but does not check if they
were found before using them.
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-3813:
----------------------------------
Attachment: DERBY-3813_diff.txt
Here is a patch to correct this issue. I reproduced the NPE with the JVM in question and verified that this fixes it. I ran suites.All and derbyall on weme 6.1, suites.All on jdk142. Still need to run more tests, but here is the patch for review.
> Derby tests for the existance of BigDecimal methods toPlainString and bdPrecison but does not check if they were found before using them.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3813
> URL: https://issues.apache.org/jira/browse/DERBY-3813
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.3.0
> Environment: Using a VM that is a subset of Java 5 without full BigDecimal support
> Reporter: Stan Bradbury
> Assignee: Kathey Marsden
> Attachments: DERBY-3813_diff.txt
>
>
> I received the following problem report:
> Having failures running with our VM that is a subset of Java 5. Failure is with the handling of the BigDecimal class in the org.apache.derby.iapi.types.SQLDecimal class.
> The SQLDecimal class does reflection to determine if the methods toPlainString and bdPrecison are present or not
> private static final Method toPlainString;
> private static final Method bdPrecision;
> static {
> Method m;
> try {
> m = BigDecimal.class.getMethod("toPlainString", null);
> } catch (NoSuchMethodException e) {
> m = null;
> }
> toPlainString = m;
> try {
> m = BigDecimal.class.getMethod("precision", null);
> } catch (NoSuchMethodException e) {
> m = null;
> }
> bdPrecision = m;
> }
> however, when it comes time to use them, it does not check whether it found the methods, but rather the JVM level, equating JVM specification level with method existence
> public String getString()
> {
> BigDecimal localValue = getBigDecimal();
> if (localValue == null)
> return null;
> else if (JVMInfo.JDK_ID < JVMInfo.J2SE_15)
> return localValue.toString();
> else
> {
> // use reflection so we can still compile using JDK1.4
> // if we are prepared to require 1.5 to compile then this can be a direct call
> try {
> return (String) toPlainString.invoke(localValue, null);
> } catch (IllegalAccessException e) {
> and
> private static int getWholeDigits(BigDecimal decimalValue)
> {
> /**
> * if ONE > abs(value) then the number of whole digits is 0
> */
> decimalValue = decimalValue.abs();
> if (ONE.compareTo(decimalValue) == 1)
> {
> return 0;
> }
>
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
> {
> // use reflection so we can still compile using JDK1.4
> // if we are prepared to require 1.5 to compile then this can be a
> // direct call
> try {
> // precision is the number of digits in the unscaled value,
> // subtracting the scale (positive or negative) will give the
> // number of whole digits.
> int precision = ((Integer) bdPrecision.invoke(decimalValue,
> null)).intValue();
> return precision - decimalValue.scale();
> Since the JVM is claiming 1.5 specification, the code assumes the methods exist, and result in NullPointerExceptions at the low level Derby class, resulting in SQLExceptions thrown to the caller.
> >>>> ***Created table: dish
> ***Created table: VNMEDICALRECORD
> Fail to make the query to database:
> java.lang.NullPointerException
> at org.apache.derby.iapi.types.SQLDecimal.getString(Unknown Source)
> at org.apache.derby.iapi.types.DataType.getTraceString(Unknown Source)
> at org.apache.derby.impl.sql.GenericParameter.toString(Unknown Source)
> at org.apache.derby.impl.sql.GenericParameterValueSet.toString(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericStatementContext.appendErrorInfo(Unknown Source)
> at org.apache.derby.iapi.services.context.ContextManager.cleanupOnError(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
> at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:175)
> at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
> at java.lang.Thread.run(Unknown Source)
> Fail to close:
> java.sql.SQLException: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
> at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
> at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:258)
> at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
> at java.lang.Thread.run(Unknown Source)
> Caused by: ERROR X0Y67: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doRollback(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userRollback(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.rollback(Unknown Source)
> ... 5 more
> Making the following change would fix the problem of running on our VM
> Instead of this test
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
> test if (toPlainString == null), or if (bdPrecision == null) or equivalent, this should achieved the same results
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3813) Derby tests for the existance of
BigDecimal methods toPlainString and bdPrecison but does not check if they
were found before using them.
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden resolved DERBY-3813.
-----------------------------------
Resolution: Fixed
Fix Version/s: 10.5.0.0
10.4.2.0
10.3.3.1
Committed fix to trunk, 10.4 and 10.5 codeline. Dan do you know the answer to Berthold's question?
> Derby tests for the existance of BigDecimal methods toPlainString and bdPrecison but does not check if they were found before using them.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3813
> URL: https://issues.apache.org/jira/browse/DERBY-3813
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.3.0
> Environment: Using a VM that is a subset of Java 5 without full BigDecimal support
> Reporter: Stan Bradbury
> Assignee: Kathey Marsden
> Fix For: 10.3.3.1, 10.4.2.0, 10.5.0.0
>
> Attachments: DERBY-3813_diff.txt
>
>
> I received the following problem report:
> Having failures running with our VM that is a subset of Java 5. Failure is with the handling of the BigDecimal class in the org.apache.derby.iapi.types.SQLDecimal class.
> The SQLDecimal class does reflection to determine if the methods toPlainString and bdPrecison are present or not
> private static final Method toPlainString;
> private static final Method bdPrecision;
> static {
> Method m;
> try {
> m = BigDecimal.class.getMethod("toPlainString", null);
> } catch (NoSuchMethodException e) {
> m = null;
> }
> toPlainString = m;
> try {
> m = BigDecimal.class.getMethod("precision", null);
> } catch (NoSuchMethodException e) {
> m = null;
> }
> bdPrecision = m;
> }
> however, when it comes time to use them, it does not check whether it found the methods, but rather the JVM level, equating JVM specification level with method existence
> public String getString()
> {
> BigDecimal localValue = getBigDecimal();
> if (localValue == null)
> return null;
> else if (JVMInfo.JDK_ID < JVMInfo.J2SE_15)
> return localValue.toString();
> else
> {
> // use reflection so we can still compile using JDK1.4
> // if we are prepared to require 1.5 to compile then this can be a direct call
> try {
> return (String) toPlainString.invoke(localValue, null);
> } catch (IllegalAccessException e) {
> and
> private static int getWholeDigits(BigDecimal decimalValue)
> {
> /**
> * if ONE > abs(value) then the number of whole digits is 0
> */
> decimalValue = decimalValue.abs();
> if (ONE.compareTo(decimalValue) == 1)
> {
> return 0;
> }
>
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
> {
> // use reflection so we can still compile using JDK1.4
> // if we are prepared to require 1.5 to compile then this can be a
> // direct call
> try {
> // precision is the number of digits in the unscaled value,
> // subtracting the scale (positive or negative) will give the
> // number of whole digits.
> int precision = ((Integer) bdPrecision.invoke(decimalValue,
> null)).intValue();
> return precision - decimalValue.scale();
> Since the JVM is claiming 1.5 specification, the code assumes the methods exist, and result in NullPointerExceptions at the low level Derby class, resulting in SQLExceptions thrown to the caller.
> >>>> ***Created table: dish
> ***Created table: VNMEDICALRECORD
> Fail to make the query to database:
> java.lang.NullPointerException
> at org.apache.derby.iapi.types.SQLDecimal.getString(Unknown Source)
> at org.apache.derby.iapi.types.DataType.getTraceString(Unknown Source)
> at org.apache.derby.impl.sql.GenericParameter.toString(Unknown Source)
> at org.apache.derby.impl.sql.GenericParameterValueSet.toString(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericStatementContext.appendErrorInfo(Unknown Source)
> at org.apache.derby.iapi.services.context.ContextManager.cleanupOnError(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
> at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:175)
> at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
> at java.lang.Thread.run(Unknown Source)
> Fail to close:
> java.sql.SQLException: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
> at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
> at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:258)
> at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
> at java.lang.Thread.run(Unknown Source)
> Caused by: ERROR X0Y67: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doRollback(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userRollback(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.rollback(Unknown Source)
> ... 5 more
> Making the following change would fix the problem of running on our VM
> Instead of this test
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
> test if (toPlainString == null), or if (bdPrecision == null) or equivalent, this should achieved the same results
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3813) Derby tests for the existance of
BigDecimal methods toPlainString and bdPrecison but does not check if they
were found before using them.
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden reassigned DERBY-3813:
-------------------------------------
Assignee: Kathey Marsden
> Derby tests for the existance of BigDecimal methods toPlainString and bdPrecison but does not check if they were found before using them.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3813
> URL: https://issues.apache.org/jira/browse/DERBY-3813
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.3.0
> Environment: Using a VM that is a subset of Java 5 without full BigDecimal support
> Reporter: Stan Bradbury
> Assignee: Kathey Marsden
>
> I received the following problem report:
> Having failures running with our VM that is a subset of Java 5. Failure is with the handling of the BigDecimal class in the org.apache.derby.iapi.types.SQLDecimal class.
> The SQLDecimal class does reflection to determine if the methods toPlainString and bdPrecison are present or not
> private static final Method toPlainString;
> private static final Method bdPrecision;
> static {
> Method m;
> try {
> m = BigDecimal.class.getMethod("toPlainString", null);
> } catch (NoSuchMethodException e) {
> m = null;
> }
> toPlainString = m;
> try {
> m = BigDecimal.class.getMethod("precision", null);
> } catch (NoSuchMethodException e) {
> m = null;
> }
> bdPrecision = m;
> }
> however, when it comes time to use them, it does not check whether it found the methods, but rather the JVM level, equating JVM specification level with method existence
> public String getString()
> {
> BigDecimal localValue = getBigDecimal();
> if (localValue == null)
> return null;
> else if (JVMInfo.JDK_ID < JVMInfo.J2SE_15)
> return localValue.toString();
> else
> {
> // use reflection so we can still compile using JDK1.4
> // if we are prepared to require 1.5 to compile then this can be a direct call
> try {
> return (String) toPlainString.invoke(localValue, null);
> } catch (IllegalAccessException e) {
> and
> private static int getWholeDigits(BigDecimal decimalValue)
> {
> /**
> * if ONE > abs(value) then the number of whole digits is 0
> */
> decimalValue = decimalValue.abs();
> if (ONE.compareTo(decimalValue) == 1)
> {
> return 0;
> }
>
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
> {
> // use reflection so we can still compile using JDK1.4
> // if we are prepared to require 1.5 to compile then this can be a
> // direct call
> try {
> // precision is the number of digits in the unscaled value,
> // subtracting the scale (positive or negative) will give the
> // number of whole digits.
> int precision = ((Integer) bdPrecision.invoke(decimalValue,
> null)).intValue();
> return precision - decimalValue.scale();
> Since the JVM is claiming 1.5 specification, the code assumes the methods exist, and result in NullPointerExceptions at the low level Derby class, resulting in SQLExceptions thrown to the caller.
> >>>> ***Created table: dish
> ***Created table: VNMEDICALRECORD
> Fail to make the query to database:
> java.lang.NullPointerException
> at org.apache.derby.iapi.types.SQLDecimal.getString(Unknown Source)
> at org.apache.derby.iapi.types.DataType.getTraceString(Unknown Source)
> at org.apache.derby.impl.sql.GenericParameter.toString(Unknown Source)
> at org.apache.derby.impl.sql.GenericParameterValueSet.toString(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericStatementContext.appendErrorInfo(Unknown Source)
> at org.apache.derby.iapi.services.context.ContextManager.cleanupOnError(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
> at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:175)
> at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
> at java.lang.Thread.run(Unknown Source)
> Fail to close:
> java.sql.SQLException: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
> at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
> at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:258)
> at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
> at java.lang.Thread.run(Unknown Source)
> Caused by: ERROR X0Y67: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doRollback(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userRollback(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.rollback(Unknown Source)
> ... 5 more
> Making the following change would fix the problem of running on our VM
> Instead of this test
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
> test if (toPlainString == null), or if (bdPrecision == null) or equivalent, this should achieved the same results
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3813) Derby tests for the existance of
BigDecimal methods toPlainString and bdPrecison but does not check if they
were found before using them.
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-3813:
----------------------------------
Component/s: SQL
> Derby tests for the existance of BigDecimal methods toPlainString and bdPrecison but does not check if they were found before using them.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3813
> URL: https://issues.apache.org/jira/browse/DERBY-3813
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.3.0
> Environment: Using a VM that is a subset of Java 5 without full BigDecimal support
> Reporter: Stan Bradbury
> Assignee: Kathey Marsden
> Fix For: 10.3.3.1, 10.4.2.0, 10.5.0.0
>
> Attachments: DERBY-3813_diff.txt
>
>
> I received the following problem report:
> Having failures running with our VM that is a subset of Java 5. Failure is with the handling of the BigDecimal class in the org.apache.derby.iapi.types.SQLDecimal class.
> The SQLDecimal class does reflection to determine if the methods toPlainString and bdPrecison are present or not
> private static final Method toPlainString;
> private static final Method bdPrecision;
> static {
> Method m;
> try {
> m = BigDecimal.class.getMethod("toPlainString", null);
> } catch (NoSuchMethodException e) {
> m = null;
> }
> toPlainString = m;
> try {
> m = BigDecimal.class.getMethod("precision", null);
> } catch (NoSuchMethodException e) {
> m = null;
> }
> bdPrecision = m;
> }
> however, when it comes time to use them, it does not check whether it found the methods, but rather the JVM level, equating JVM specification level with method existence
> public String getString()
> {
> BigDecimal localValue = getBigDecimal();
> if (localValue == null)
> return null;
> else if (JVMInfo.JDK_ID < JVMInfo.J2SE_15)
> return localValue.toString();
> else
> {
> // use reflection so we can still compile using JDK1.4
> // if we are prepared to require 1.5 to compile then this can be a direct call
> try {
> return (String) toPlainString.invoke(localValue, null);
> } catch (IllegalAccessException e) {
> and
> private static int getWholeDigits(BigDecimal decimalValue)
> {
> /**
> * if ONE > abs(value) then the number of whole digits is 0
> */
> decimalValue = decimalValue.abs();
> if (ONE.compareTo(decimalValue) == 1)
> {
> return 0;
> }
>
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
> {
> // use reflection so we can still compile using JDK1.4
> // if we are prepared to require 1.5 to compile then this can be a
> // direct call
> try {
> // precision is the number of digits in the unscaled value,
> // subtracting the scale (positive or negative) will give the
> // number of whole digits.
> int precision = ((Integer) bdPrecision.invoke(decimalValue,
> null)).intValue();
> return precision - decimalValue.scale();
> Since the JVM is claiming 1.5 specification, the code assumes the methods exist, and result in NullPointerExceptions at the low level Derby class, resulting in SQLExceptions thrown to the caller.
> >>>> ***Created table: dish
> ***Created table: VNMEDICALRECORD
> Fail to make the query to database:
> java.lang.NullPointerException
> at org.apache.derby.iapi.types.SQLDecimal.getString(Unknown Source)
> at org.apache.derby.iapi.types.DataType.getTraceString(Unknown Source)
> at org.apache.derby.impl.sql.GenericParameter.toString(Unknown Source)
> at org.apache.derby.impl.sql.GenericParameterValueSet.toString(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericStatementContext.appendErrorInfo(Unknown Source)
> at org.apache.derby.iapi.services.context.ContextManager.cleanupOnError(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
> at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:175)
> at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
> at java.lang.Thread.run(Unknown Source)
> Fail to close:
> java.sql.SQLException: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
> at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
> at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:258)
> at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
> at java.lang.Thread.run(Unknown Source)
> Caused by: ERROR X0Y67: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doRollback(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userRollback(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.rollback(Unknown Source)
> ... 5 more
> Making the following change would fix the problem of running on our VM
> Instead of this test
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
> test if (toPlainString == null), or if (bdPrecision == null) or equivalent, this should achieved the same results
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3813) Derby tests for the existance of
BigDecimal methods toPlainString and bdPrecison but does not check if they
were found before using them.
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619709#action_12619709 ]
Kathey Marsden commented on DERBY-3813:
---------------------------------------
Here is some links with info on the jvm in question.
Understanding the jclDekstop JRE: http://publib.boulder.ibm.com/infocenter/ledoc/v6r11/topic/com.ibm.rcp.tools.doc.appdev/devapps_understandingthejcldesktopjre.html
Javadoc - overview: http://publib.boulder.ibm.com/infocenter/ledoc/v6r11/topic/com.ibm.rcp.jcl.desktop.javadoc/doc/overview-summary.html
Javadoc - differences between jclDesktop and Java 5.0: http://publib.boulder.ibm.com/infocenter/ledoc/v6r11/topic/com.ibm.rcp.jcl.desktop.javadoc/jclDesktop-J2SE50-Differences.html
I'll download the trial version and see if I can reproduce the problem.
> Derby tests for the existance of BigDecimal methods toPlainString and bdPrecison but does not check if they were found before using them.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3813
> URL: https://issues.apache.org/jira/browse/DERBY-3813
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.3.0
> Environment: Using a VM that is a subset of Java 5 without full BigDecimal support
> Reporter: Stan Bradbury
> Assignee: Kathey Marsden
>
> I received the following problem report:
> Having failures running with our VM that is a subset of Java 5. Failure is with the handling of the BigDecimal class in the org.apache.derby.iapi.types.SQLDecimal class.
> The SQLDecimal class does reflection to determine if the methods toPlainString and bdPrecison are present or not
> private static final Method toPlainString;
> private static final Method bdPrecision;
> static {
> Method m;
> try {
> m = BigDecimal.class.getMethod("toPlainString", null);
> } catch (NoSuchMethodException e) {
> m = null;
> }
> toPlainString = m;
> try {
> m = BigDecimal.class.getMethod("precision", null);
> } catch (NoSuchMethodException e) {
> m = null;
> }
> bdPrecision = m;
> }
> however, when it comes time to use them, it does not check whether it found the methods, but rather the JVM level, equating JVM specification level with method existence
> public String getString()
> {
> BigDecimal localValue = getBigDecimal();
> if (localValue == null)
> return null;
> else if (JVMInfo.JDK_ID < JVMInfo.J2SE_15)
> return localValue.toString();
> else
> {
> // use reflection so we can still compile using JDK1.4
> // if we are prepared to require 1.5 to compile then this can be a direct call
> try {
> return (String) toPlainString.invoke(localValue, null);
> } catch (IllegalAccessException e) {
> and
> private static int getWholeDigits(BigDecimal decimalValue)
> {
> /**
> * if ONE > abs(value) then the number of whole digits is 0
> */
> decimalValue = decimalValue.abs();
> if (ONE.compareTo(decimalValue) == 1)
> {
> return 0;
> }
>
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
> {
> // use reflection so we can still compile using JDK1.4
> // if we are prepared to require 1.5 to compile then this can be a
> // direct call
> try {
> // precision is the number of digits in the unscaled value,
> // subtracting the scale (positive or negative) will give the
> // number of whole digits.
> int precision = ((Integer) bdPrecision.invoke(decimalValue,
> null)).intValue();
> return precision - decimalValue.scale();
> Since the JVM is claiming 1.5 specification, the code assumes the methods exist, and result in NullPointerExceptions at the low level Derby class, resulting in SQLExceptions thrown to the caller.
> >>>> ***Created table: dish
> ***Created table: VNMEDICALRECORD
> Fail to make the query to database:
> java.lang.NullPointerException
> at org.apache.derby.iapi.types.SQLDecimal.getString(Unknown Source)
> at org.apache.derby.iapi.types.DataType.getTraceString(Unknown Source)
> at org.apache.derby.impl.sql.GenericParameter.toString(Unknown Source)
> at org.apache.derby.impl.sql.GenericParameterValueSet.toString(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericStatementContext.appendErrorInfo(Unknown Source)
> at org.apache.derby.iapi.services.context.ContextManager.cleanupOnError(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
> at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:175)
> at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
> at java.lang.Thread.run(Unknown Source)
> Fail to close:
> java.sql.SQLException: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
> at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
> at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:258)
> at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
> at java.lang.Thread.run(Unknown Source)
> Caused by: ERROR X0Y67: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doRollback(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userRollback(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.rollback(Unknown Source)
> ... 5 more
> Making the following change would fix the problem of running on our VM
> Instead of this test
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
> test if (toPlainString == null), or if (bdPrecision == null) or equivalent, this should achieved the same results
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3813) Derby tests for the existance of
BigDecimal methods toPlainString and bdPrecison but does not check if they
were found before using them.
Posted by "Berthold Lebert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620789#action_12620789 ]
Berthold Lebert commented on DERBY-3813:
----------------------------------------
What are the reasons you go through reflection to use toPlainString() and precision() if in the Java 1.4 case toString() and your code to determine the precision seem to be just fine?
> Derby tests for the existance of BigDecimal methods toPlainString and bdPrecison but does not check if they were found before using them.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3813
> URL: https://issues.apache.org/jira/browse/DERBY-3813
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.3.0
> Environment: Using a VM that is a subset of Java 5 without full BigDecimal support
> Reporter: Stan Bradbury
> Assignee: Kathey Marsden
> Attachments: DERBY-3813_diff.txt
>
>
> I received the following problem report:
> Having failures running with our VM that is a subset of Java 5. Failure is with the handling of the BigDecimal class in the org.apache.derby.iapi.types.SQLDecimal class.
> The SQLDecimal class does reflection to determine if the methods toPlainString and bdPrecison are present or not
> private static final Method toPlainString;
> private static final Method bdPrecision;
> static {
> Method m;
> try {
> m = BigDecimal.class.getMethod("toPlainString", null);
> } catch (NoSuchMethodException e) {
> m = null;
> }
> toPlainString = m;
> try {
> m = BigDecimal.class.getMethod("precision", null);
> } catch (NoSuchMethodException e) {
> m = null;
> }
> bdPrecision = m;
> }
> however, when it comes time to use them, it does not check whether it found the methods, but rather the JVM level, equating JVM specification level with method existence
> public String getString()
> {
> BigDecimal localValue = getBigDecimal();
> if (localValue == null)
> return null;
> else if (JVMInfo.JDK_ID < JVMInfo.J2SE_15)
> return localValue.toString();
> else
> {
> // use reflection so we can still compile using JDK1.4
> // if we are prepared to require 1.5 to compile then this can be a direct call
> try {
> return (String) toPlainString.invoke(localValue, null);
> } catch (IllegalAccessException e) {
> and
> private static int getWholeDigits(BigDecimal decimalValue)
> {
> /**
> * if ONE > abs(value) then the number of whole digits is 0
> */
> decimalValue = decimalValue.abs();
> if (ONE.compareTo(decimalValue) == 1)
> {
> return 0;
> }
>
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
> {
> // use reflection so we can still compile using JDK1.4
> // if we are prepared to require 1.5 to compile then this can be a
> // direct call
> try {
> // precision is the number of digits in the unscaled value,
> // subtracting the scale (positive or negative) will give the
> // number of whole digits.
> int precision = ((Integer) bdPrecision.invoke(decimalValue,
> null)).intValue();
> return precision - decimalValue.scale();
> Since the JVM is claiming 1.5 specification, the code assumes the methods exist, and result in NullPointerExceptions at the low level Derby class, resulting in SQLExceptions thrown to the caller.
> >>>> ***Created table: dish
> ***Created table: VNMEDICALRECORD
> Fail to make the query to database:
> java.lang.NullPointerException
> at org.apache.derby.iapi.types.SQLDecimal.getString(Unknown Source)
> at org.apache.derby.iapi.types.DataType.getTraceString(Unknown Source)
> at org.apache.derby.impl.sql.GenericParameter.toString(Unknown Source)
> at org.apache.derby.impl.sql.GenericParameterValueSet.toString(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericStatementContext.appendErrorInfo(Unknown Source)
> at org.apache.derby.iapi.services.context.ContextManager.cleanupOnError(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
> at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:175)
> at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
> at java.lang.Thread.run(Unknown Source)
> Fail to close:
> java.sql.SQLException: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
> at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.close(Unknown Source)
> at com.ibm.rcp.samples.derby.Derby.updateDB(Derby.java:258)
> at com.ibm.rcp.samples.derby.Derby.run(Derby.java:89)
> at java.lang.Thread.run(Unknown Source)
> Caused by: ERROR X0Y67: Cannot issue rollback in a nested connection when there is a pending operation in the parent connection.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doRollback(Unknown Source)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userRollback(Unknown Source)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.rollback(Unknown Source)
> ... 5 more
> Making the following change would fix the problem of running on our VM
> Instead of this test
> if (JVMInfo.JDK_ID >= JVMInfo.J2SE_15)
> test if (toPlainString == null), or if (bdPrecision == null) or equivalent, this should achieved the same results
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.