Derby
  1. Derby
  2. DERBY-3697

Compiler exception when invoking a routine with NUMERIC argument on J2ME

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 10.4.1.3
    • Fix Version/s: None
    • Component/s: SQL
    • Environment:
      Operating system = Ubuntu 7.10
      VM = phoneme_advanced_mr2-b34
    • Urgency:
      Normal
    • Issue & fix info:
      Repro attached

      Description

      Derby raises an error during byte-code generation when asked to invoke a routine declared to have a NUMERIC argument and to be bound to a method with a BigDecimal argument. According to the ANSI standard (see DERBY-3652), SQL NUMERIC is supposed to map to Java BigDecimal. This is the experiment I ran:

      1) I built the 10.4 source, including the AnsiSignatures class (I will attach this).

      2) I ran a script which declared a function with a NUMERIC argument bound to a method in AnsiSignatures which has a BigDecimal argument.

      3) When I invoked the function, the byte-code generator raised an exception.

      I am not sure what we want to happen here. The BigDecimal class does exist in Foundation Profile 1.1.2. For small device platforms which support FP 1.1.2, it seems reasonable that NUMERIC should map to BigDecimal as the ANSI spec requires. For small device platforms which don't have a BigDecimal class, I don't know what we should do. In any event, the current behavior seems wrong. Here's what I see:

      ij> create function "numeric_BigDecimal_BigDecimal"
      (
      a_0 numeric
      )
      returns numeric
      language java
      parameter style java
      no sql
      external name 'org.apache.derbyTesting.functionTests.tests.lang.AnsiSignatures.numeric_BigDecimal_BigDecimal'
      ;
      0 rows inserted/updated/deleted
      ij> values ( "numeric_BigDecimal_BigDecimal"( 12345.67 ) );
      java.lang.NoSuchMethodException: getDecimalDataValue
      at java.lang.Class.getMethod0(Native Method)
      at java.lang.Class.getDeclaredMethod(Unknown Source)
      at org.apache.derby.impl.services.bytecode.d_BCValidate.checkMethod(Unknown Source)
      at org.apache.derby.impl.services.bytecode.BCMethod.callMethod(Unknown Source)
      at org.apache.derby.impl.sql.compile.BaseTypeCompiler.generateDataValue(Unknown Source)
      at org.apache.derby.impl.sql.compile.NumericTypeCompiler.generateDataValue(Unknown Source)
      at org.apache.derby.impl.sql.compile.ExpressionClassBuilder.generateDataValue(Unknown Source)
      at org.apache.derby.impl.sql.compile.JavaToSQLValueNode.generateExpression(Unknown Source)
      at org.apache.derby.impl.sql.compile.CastNode.generateExpression(Unknown Source)
      at org.apache.derby.impl.sql.compile.SQLToJavaValueNode.generateSQLValue(Unknown Source)
      at org.apache.derby.impl.sql.compile.SQLToJavaValueNode.generateExpression(Unknown Source)
      at org.apache.derby.impl.sql.compile.JavaToSQLValueNode.generateExpression(Unknown Source)
      at org.apache.derby.impl.sql.compile.ResultColumn.generateExpression(Unknown Source)
      at org.apache.derby.impl.sql.compile.ResultColumnList.generateCore(Unknown Source)
      at org.apache.derby.impl.sql.compile.ResultColumnList.generate(Unknown Source)
      at org.apache.derby.impl.sql.compile.RowResultSetNode.generate(Unknown Source)
      at org.apache.derby.impl.sql.compile.ScrollInsensitiveResultSetNode.generate(Unknown Source)
      at org.apache.derby.impl.sql.compile.CursorNode.generate(Unknown Source)
      at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown Source)
      at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
      at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
      at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
      at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source)
      at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source)
      at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source)
      at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source)
      at org.apache.derby.impl.tools.ij.Main.go(Unknown Source)
      at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
      at org.apache.derby.impl.tools.ij.Main.main(Unknown Source)
      at org.apache.derby.tools.ij.main(Unknown Source)
      at sun.misc.CVM.runMain(Unknown Source)
      Invalid method org.apache.derby.iapi.types.DataValueFactory >> org.apache.derby.iapi.types.NumberDataValue getDecimalDataValue(java.math.BigDecimal, org.apache.derby.iapi.types.NumberDataValue) because java.lang.NoSuchMethodException: getDecimalDataValue
      ERROR XJ001: Java exception: 'ASSERT FAILED Invalid method org.apache.derby.iapi.types.DataValueFactory >> org.apache.derby.iapi.types.NumberDataValue getDecimalDataValue(java.math.BigDecimal, org.apache.derby.iapi.types.NumberDataValue) because java.lang.NoSuchMethodException: getDecimalDataValue: org.apache.derby.shared.common.sanity.AssertFailure'.

      Here is the output of sysinfo on this platform:

      ------------------ Java Information ------------------
      Java Version: phoneme_advanced_mr2-b34
      Java Vendor: Sun Microsystems Inc.
      Java home: /mnt/hgfs/mac_users/rh161140/sw/phoneME/phoneme_advanced_mr2
      Java classpath: /mnt/hgfs/mac_users/rh161140/derby/dummy/trunk/classes:/mnt/hgfs/mac_users/rh161140/src:/mnt/hgfs/mac_users/rh161140/derby/dummy/trunk/tools/java/empty.jar:/mnt/hgfs/mac_users/rh161140/derby/dummy/trunk/tools/java/felix.jar:/mnt/hgfs/mac_users/rh161140/derby/dummy/trunk/tools/java/geronimo-spec-servlet-2.4-rc4.jar:/mnt/hgfs/mac_users/rh161140/derby/dummy/trunk/tools/java/jakarta-oro-2.0.8.jar:/mnt/hgfs/mac_users/rh161140/derby/dummy/trunk/tools/java/javacc.jar:/mnt/hgfs/mac_users/rh161140/derby/dummy/trunk/tools/java/junit.jar:/mnt/hgfs/mac_users/rh161140/derby/dummy/trunk/tools/java/xercesImpl.jar:/mnt/hgfs/mac_users/rh161140/derby/dummy/trunk/tools/java/xml-apis.jar
      OS name: Linux
      OS architecture: x86
      OS version: 2.6.22-14-generic
      Java user name: rhillegas
      Java user home: /home/rhillegas
      Java user dir: /home/rhillegas/zz
      java.specification.name: Personal Basis Profile Specification
      java.specification.version: 1.1
      --------- Derby Information --------
      JRE - JDBC: J2ME - JDBC for CDC/FP 1.1
      [/mnt/hgfs/mac_users/rh161140/derby/dummy/trunk/classes] 10.4.1.3 - (648232:652095)
      ------------------------------------------------------
      ----------------- Locale Information -----------------
      ------------------------------------------------------

        Issue Links

          Activity

          Hide
          Myrna van Lunteren added a comment - - edited

          My 2 cents: I think we decided we'd support J2ME - Foundation 1.1 as of derby 10.4 and thus the BigDecimal class.
          However, that doesn't mean we can use BigDecimal references everywhere, I think JSR169 still doesn't support calls like ResultSet.getBigDecimal().

          Show
          Myrna van Lunteren added a comment - - edited My 2 cents: I think we decided we'd support J2ME - Foundation 1.1 as of derby 10.4 and thus the BigDecimal class. However, that doesn't mean we can use BigDecimal references everywhere, I think JSR169 still doesn't support calls like ResultSet.getBigDecimal().
          Hide
          Rick Hillegas added a comment -

          Thanks, Myrna. I take your comment as a vote for the following:

          When matching SQL routines to Java methods on Java ME platforms, SQL NUMERIC should map to Java BigDecimal per the ANSI standard, just as happens on J2SE platforms.

          Show
          Rick Hillegas added a comment - Thanks, Myrna. I take your comment as a vote for the following: When matching SQL routines to Java methods on Java ME platforms, SQL NUMERIC should map to Java BigDecimal per the ANSI standard, just as happens on J2SE platforms.
          Hide
          Myrna van Lunteren added a comment -

          Assuming it can be done without using JDBC set/get methods for BigDecimal, I think that's right.
          But, because of DERBY-2210, which mentions DECIMAL (which I think in derby is a synonym to NUMERIC?), I think there is a challenge to do this.

          Show
          Myrna van Lunteren added a comment - Assuming it can be done without using JDBC set/get methods for BigDecimal, I think that's right. But, because of DERBY-2210 , which mentions DECIMAL (which I think in derby is a synonym to NUMERIC?), I think there is a challenge to do this.
          Hide
          Rick Hillegas added a comment -

          Thanks, Myrna. I'm linking this issue to DERBY-2210.

          Show
          Rick Hillegas added a comment - Thanks, Myrna. I'm linking this issue to DERBY-2210 .
          Hide
          Knut Anders Hatlen added a comment -

          Triaged for 10.5.2.

          Show
          Knut Anders Hatlen added a comment - Triaged for 10.5.2.
          Hide
          Knut Anders Hatlen added a comment -

          Now that Java ME support has been removed from trunk, I don't expect this bug will be fixed. Rick, would you be OK with closing it as Won't Fix?

          Show
          Knut Anders Hatlen added a comment - Now that Java ME support has been removed from trunk, I don't expect this bug will be fixed. Rick, would you be OK with closing it as Won't Fix?
          Hide
          Rick Hillegas added a comment -

          Thanks for noticing this, Knut. I agree that the probability that someone will fix this bug is now vanishingly small.

          Show
          Rick Hillegas added a comment - Thanks for noticing this, Knut. I agree that the probability that someone will fix this bug is now vanishingly small.

            People

            • Assignee:
              Unassigned
              Reporter:
              Rick Hillegas
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development