Derby
  1. Derby
  2. DERBY-453

Create a test wrapper to run tests using BigDecimal in J2ME/CDC/Foundation

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.2.1.6
    • Component/s: Test
    • Labels:
      None
    • Environment:
      J2ME/CDC/Foundation using IBM's WCTME 5.7

      Description

      The following tests are currently excluded in J2ME/CDC/Foundation because they use BigDecimal class.

      I18NImportExport
      batchUpdate
      LOBTest
      parameterMapping
      resultset
      StmtCloseFunTest
      cast
      functions
      outparams
      procedure
      triggerRefClause
      wisconsin
      iepnegativetests
      ieptests
      importExportThruIJ
      importExport

      To run the above tests in this environment, test utility classes have to be written so that the methods using BigDecimal are redirected depending on the VM environment. The initial goal is to submit a patch for the test resultset.java. After this, sub-tasks will be opened if changes are needed to run the other tests.

      1. parameterMetaDataJdbc30-patch.diff
        1 kB
        Deepa Remesh
      2. derby-453.status
        0.3 kB
        Deepa Remesh
      3. derby-453.diff
        10 kB
        Deepa Remesh
      4. derby_453_outparams_patch4.diff
        509 kB
        Deepa Remesh
      5. derby_453_outparams_patch3.diff
        520 kB
        Deepa Remesh
      6. derby_453_outparams_patch2.diff
        527 kB
        Deepa Remesh
      7. derby_453_outparams_patch1.status
        1 kB
      8. derby_453_outparams_patch1.diff
        527 kB

        Issue Links

          Activity

          Gavin made changes -
          Workflow jira [ 12322142 ] Default workflow, editable Closed status [ 12797575 ]
          Deepa Remesh made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Deepa Remesh made changes -
          Fix Version/s 10.2.0.0 [ 11187 ]
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          Hide
          Deepa Remesh added a comment -

          The patches for the above tests have been committed. 12 tests in the list now run with j2me. 3 tests (functions.sql, procedure.java and triggerRefClause.sql) are still excluded with comments why they cannot run in j2me/fp. DERBY-680 is open for 1 test (cast.sql).

          Show
          Deepa Remesh added a comment - The patches for the above tests have been committed. 12 tests in the list now run with j2me. 3 tests (functions.sql, procedure.java and triggerRefClause.sql) are still excluded with comments why they cannot run in j2me/fp. DERBY-680 is open for 1 test (cast.sql).
          Deepa Remesh made changes -
          Attachment parameterMetaDataJdbc30-patch.diff [ 12314528 ]
          Hide
          Deepa Remesh added a comment -

          Attaching a patch for test jdbcapi/parameterMetaDataJdbc30.java. Changed the test to use returnsBigDecimal method from outparams30.java

          Show
          Deepa Remesh added a comment - Attaching a patch for test jdbcapi/parameterMetaDataJdbc30.java. Changed the test to use returnsBigDecimal method from outparams30.java
          Deepa Remesh made changes -
          Attachment derby_453_outparams_patch4.diff [ 12314411 ]
          Hide
          Deepa Remesh added a comment -

          Submitting another patch derby_453_outparams_patch4.diff for Kathey's comments.

          Show
          Deepa Remesh added a comment - Submitting another patch derby_453_outparams_patch4.diff for Kathey's comments.
          Hide
          Deepa Remesh added a comment -

          A small change to the above comment. StmtCloseFunTest.java is changed to use the constructor java.sql.Date(long) because the deprecated constructor (Date(int year, int month, int day) ) is not available in JSR169.

          Show
          Deepa Remesh added a comment - A small change to the above comment. StmtCloseFunTest.java is changed to use the constructor java.sql.Date(long) because the deprecated constructor (Date(int year, int month, int day) ) is not available in JSR169.
          Hide
          Kathey Marsden added a comment -

          Deepa and I spoke briefly about this patch. Here's the summary of my comments.

          • There a couple of uses of Double still that can be removed
            1) in setObject it is used.
            2) new Double() is used in getBigDecimalString() to verify that the value is a number and an exception thrown that matches the server internal message that is thrown if you do getBigDecimal on a non numeric value. This may not work in all cases and seems a bit confusing. Maybe better to just let the caller deal with the value as returned from getString

          I noted that StmtCloseFunTest.java has been changed to use long literal values in the Date Constructor. (The test was using a deprecated constructor.) Deepa said this was because Aparently J2ME doesn't have a Calendar class. so it's not clear how to construct the date except by this method which other tests use.

          Show
          Kathey Marsden added a comment - Deepa and I spoke briefly about this patch. Here's the summary of my comments. There a couple of uses of Double still that can be removed 1) in setObject it is used. 2) new Double() is used in getBigDecimalString() to verify that the value is a number and an exception thrown that matches the server internal message that is thrown if you do getBigDecimal on a non numeric value. This may not work in all cases and seems a bit confusing. Maybe better to just let the caller deal with the value as returned from getString I noted that StmtCloseFunTest.java has been changed to use long literal values in the Date Constructor. (The test was using a deprecated constructor.) Deepa said this was because Aparently J2ME doesn't have a Calendar class. so it's not clear how to construct the date except by this method which other tests use.
          Deepa Remesh made changes -
          Attachment derby_453_outparams_patch3.diff [ 12312845 ]
          Hide
          Deepa Remesh added a comment -

          Submitting another patch derby_453_outparams_patch3.diff. This patch uses setString instead of setDouble in the wrapper method. I have changed the master file for j9_foundation accordingly.

          Show
          Deepa Remesh added a comment - Submitting another patch derby_453_outparams_patch3.diff. This patch uses setString instead of setDouble in the wrapper method. I have changed the master file for j9_foundation accordingly.
          Hide
          Deepa Remesh added a comment -

          In that case, I will change to setString. But I am little confused as to how I should proceed. I see two ways to handle the test:

          1. In callSetObject in outparams.java, I can continue to pass "666.666" to setBigDecimalString. This will give error in setString for short primitive type because the String passed is not convertible to short. This is the expected behaviour. I can update the master file for j9_foundation accordingly.

          2. I can pass "666" to setBigDecimalString. This will work with all the object types for which conversion is valid. But we are not testing a decimal value.

          Please let me know which of these is a good approach or if there is another way of doing this.

          Show
          Deepa Remesh added a comment - In that case, I will change to setString. But I am little confused as to how I should proceed. I see two ways to handle the test: 1. In callSetObject in outparams.java, I can continue to pass "666.666" to setBigDecimalString. This will give error in setString for short primitive type because the String passed is not convertible to short. This is the expected behaviour. I can update the master file for j9_foundation accordingly. 2. I can pass "666" to setBigDecimalString. This will work with all the object types for which conversion is valid. But we are not testing a decimal value. Please let me know which of these is a good approach or if there is another way of doing this.
          Hide
          Daniel John Debrunner added a comment -

          setDouble is not acceptable. DECIMAL types are precise values, whereas doubles are imprecise. If the user/application wants to convert DECIMAL types to imprecise types (double & float) that''s fine, but test code should be ensuring an precise type remains precise.

          Show
          Daniel John Debrunner added a comment - setDouble is not acceptable. DECIMAL types are precise values, whereas doubles are imprecise. If the user/application wants to convert DECIMAL types to imprecise types (double & float) that''s fine, but test code should be ensuring an precise type remains precise.
          Deepa Remesh made changes -
          Attachment derby_453_outparams_patch2.diff [ 12312808 ]
          Hide
          Deepa Remesh added a comment -

          I am re-submitting the patch as derby_453_outparams_patch2.diff. In the new patch, I commented out java.sql.Types.BOOLEAN since it is not available in jdk13.

          I tried changing setString to setDouble in BigDecimalHandler but then, the testcase failed for takesShortPrimitive procedure. It gave a "Invalid character string format exception for SMALLINT". This is because the value used is "666.666". If a String which can be converted to short is used (like "666"), this would not be a problem. On the other hand, if setDouble is used, the conversion to short is taken care of.

          So I am continuing to use setDouble. I agree this will compromise the precision of values. But since this testcase is not dependent on precision, I think it should be okay. If you think of other reasons for this change, please share them.

          Show
          Deepa Remesh added a comment - I am re-submitting the patch as derby_453_outparams_patch2.diff. In the new patch, I commented out java.sql.Types.BOOLEAN since it is not available in jdk13. I tried changing setString to setDouble in BigDecimalHandler but then, the testcase failed for takesShortPrimitive procedure. It gave a "Invalid character string format exception for SMALLINT". This is because the value used is "666.666". If a String which can be converted to short is used (like "666"), this would not be a problem. On the other hand, if setDouble is used, the conversion to short is taken care of. So I am continuing to use setDouble. I agree this will compromise the precision of values. But since this testcase is not dependent on precision, I think it should be okay. If you think of other reasons for this change, please share them.
          Hide
          Deepa Remesh added a comment -

          As you said, setString would be more exact. Also, the method setBigDecimalString takes a String parameter and it would be better to use it directly. I will change setDouble to setString and submit another patch.

          Show
          Deepa Remesh added a comment - As you said, setString would be more exact. Also, the method setBigDecimalString takes a String parameter and it would be better to use it directly. I will change setDouble to setString and submit another patch.
          Hide
          Kathey Marsden added a comment -

          I have a question about the patch.

          In BigDecimalHandler, the string representation uses setDouble(). Wouldn't setString would be more exact?

          For example in setBigDecimalString I see.
          case STRING_REPRESENTATION:
          ps.setDouble(parameterIndex,new Double(bdString).doubleValue());
          break;

          Show
          Kathey Marsden added a comment - I have a question about the patch. In BigDecimalHandler, the string representation uses setDouble(). Wouldn't setString would be more exact? For example in setBigDecimalString I see. case STRING_REPRESENTATION: ps.setDouble(parameterIndex,new Double(bdString).doubleValue()); break;
          Hide
          Deepa Remesh added a comment -

          This patch (derby_453_outparams_patch1.diff) changes tests.

          • It enables the tests which use procedures in outparams.java to run in J2ME/CDC/FP. The following tests have been enabled:
          • lang/lang/outparams.java
          • jdbcapi/batchUpdate.java
          • jdbcapi/StmtCloseFunTest.java
          • It disables the test lang/dbjar.sql from J2ME/FP because it uses java.sql.Driver.

          --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
          Changes to outparams.java:
          --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

          • The methods 'takesBigDecimal' and 'returnsBigDecimal' are moved from outparams.java to a new class outparams30.java. These methods use java.Math.BigDecimal class which is not available in J2ME. This separation is needed because Connection.prepareCall looks at all the public methods available in the specified class. If the class has any public method using BigDecimal, it will fail in J2ME.
          • For procedure names, outparams class will be used for J2ME and outparams30 for non-J2ME.
          • Variables HAVE_BIGDECIMAL and CLASS_NAME are added to outparams.java. Depending on the availability of BigDecimal class in the JVM, CLASS_NAME is initialized to outparams or outparams30. CLASS_NAME is used in the create procedure SQL instead of "org.apache.derbyTesting.functionTests.tests.lang.outparams.".
          • The content of the arrays 'outputMethods' and 'returnMethods' are also decided based on value of HAVE_BIGDECIMAL. For J2ME, takesBigDecimal and returnsBigDecimal are removed from these arrays. To minimize changes to the master file, the order of these arrays is kept same. An if/else loop is used to determine which array will be used.
          • callSetMethod, callSetObject and callGetMethod are changed to use wrapper methods in BigDecimalHandler class. An additional parameter 'int paramType' is passed to callGetMethod. This is needed because ParameterMetaData is not available in JSR19. A new array 'paramJDBCType' with the JDBC types (java.sql.Types) for the corresponding methods is used to get the param type for a method. When creating this array, I noticed that outputMethods and returnMethods do not match. To make them match, a null value has been removed from outputMethods and outProcParam arrays.
          • testMisc method used returnsBigDecimal to check that a set cannot be called on an output param. This check is independent of the type of output param and so returnsString is used intstead.
          • test5116 method uses a procedure with nested connection, which uses java.sql.Driver. This is not available in JSR169. So this test is done only for non-JSR169 environments based on value of HAVE_DRIVER_CLASS.

          --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
          Changes to org.apache.derbyTesting.functionTests.util.BigDecimalHandler.java:
          --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

          • Added wrappers for following methods:
            CallableStatement method getBigDecimal(int parameterIndex)
            PreparedStatement method setBigDecimal(int parameterIndex,BigDecimal x)
            PreparedStatement method setObject(int parameterIndex, Object x)
          • Fixed the type conversions and moved it to an array, which is used in the method canConvertToDecimal.

          --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
          Changes to master files:
          --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

          • The master files for main and j9_13 are modified to use returnsBigDecimal instead of returnsString in output for testMisc method. On comparing the two master files, they are identical. I think the master file for j9_13 can be removed. I have not done it in this patch. Is it okay to do this?
          • Added a master file for j9_foundation. This is needed because of the following:
          • takesBigDecimal and returnsBigDecimal methods are not in outputMethods/returnMehtods.
          • The exception strings for type conversion and invalid character format are different because of use of wrapper methods.

          --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
          Changes to <testname>_app.properties:
          --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

          • Removed excludes for J2ME for following tests:
          • lang/outparams.java
          • jdbcapi/batchUpdate.java
          • jdbcapi/StmtCloseFunTest.java
          • Added exclude for J2ME to following test:
          • lang/dbjar.sql - This test failed when derbyall was run with J2ME. This is a new test and it uses java.sql.Driver. Hence excluded.

          --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
          Changes to tests which use procedures in outparams.java
          --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

          • jdbcapi/batchUpdate.java and jdbcapi/StmtCloseFunTest.java are modified to use outparams/outparams30 depending on value of HAVE_BIG_DECIMAL.
          • jdbcapi/StmtCloseFunTest.java was using a deprecated constructor for java.sql.Date, which is not available in JSR169. So the constructor java.sql.Date(long) is used instead.

          --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
          Tests Run
          --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
          This patch changes tests only. I had run derbyall in J2SE and J2ME. 1 expected failure in J2ME. But I made few changes before submitting this patch. After the changes, I ran the individual tests successfully.

          Please review/commit this patch.

          NOTE: JIRA did not give me an option to add comments when I attached the patch files. So adding it as a separate comment.

          Show
          Deepa Remesh added a comment - This patch (derby_453_outparams_patch1.diff) changes tests. It enables the tests which use procedures in outparams.java to run in J2ME/CDC/FP. The following tests have been enabled: lang/lang/outparams.java jdbcapi/batchUpdate.java jdbcapi/StmtCloseFunTest.java It disables the test lang/dbjar.sql from J2ME/FP because it uses java.sql.Driver. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Changes to outparams.java: -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The methods 'takesBigDecimal' and 'returnsBigDecimal' are moved from outparams.java to a new class outparams30.java. These methods use java.Math.BigDecimal class which is not available in J2ME. This separation is needed because Connection.prepareCall looks at all the public methods available in the specified class. If the class has any public method using BigDecimal, it will fail in J2ME. For procedure names, outparams class will be used for J2ME and outparams30 for non-J2ME. Variables HAVE_BIGDECIMAL and CLASS_NAME are added to outparams.java. Depending on the availability of BigDecimal class in the JVM, CLASS_NAME is initialized to outparams or outparams30. CLASS_NAME is used in the create procedure SQL instead of "org.apache.derbyTesting.functionTests.tests.lang.outparams.". The content of the arrays 'outputMethods' and 'returnMethods' are also decided based on value of HAVE_BIGDECIMAL. For J2ME, takesBigDecimal and returnsBigDecimal are removed from these arrays. To minimize changes to the master file, the order of these arrays is kept same. An if/else loop is used to determine which array will be used. callSetMethod, callSetObject and callGetMethod are changed to use wrapper methods in BigDecimalHandler class. An additional parameter 'int paramType' is passed to callGetMethod. This is needed because ParameterMetaData is not available in JSR19. A new array 'paramJDBCType' with the JDBC types (java.sql.Types) for the corresponding methods is used to get the param type for a method. When creating this array, I noticed that outputMethods and returnMethods do not match. To make them match, a null value has been removed from outputMethods and outProcParam arrays. testMisc method used returnsBigDecimal to check that a set cannot be called on an output param. This check is independent of the type of output param and so returnsString is used intstead. test5116 method uses a procedure with nested connection, which uses java.sql.Driver. This is not available in JSR169. So this test is done only for non-JSR169 environments based on value of HAVE_DRIVER_CLASS. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Changes to org.apache.derbyTesting.functionTests.util.BigDecimalHandler.java: -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Added wrappers for following methods: CallableStatement method getBigDecimal(int parameterIndex) PreparedStatement method setBigDecimal(int parameterIndex,BigDecimal x) PreparedStatement method setObject(int parameterIndex, Object x) Fixed the type conversions and moved it to an array, which is used in the method canConvertToDecimal. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Changes to master files: -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The master files for main and j9_13 are modified to use returnsBigDecimal instead of returnsString in output for testMisc method. On comparing the two master files, they are identical. I think the master file for j9_13 can be removed. I have not done it in this patch. Is it okay to do this? Added a master file for j9_foundation. This is needed because of the following: takesBigDecimal and returnsBigDecimal methods are not in outputMethods/returnMehtods. The exception strings for type conversion and invalid character format are different because of use of wrapper methods. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Changes to <testname>_app.properties: -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Removed excludes for J2ME for following tests: lang/outparams.java jdbcapi/batchUpdate.java jdbcapi/StmtCloseFunTest.java Added exclude for J2ME to following test: lang/dbjar.sql - This test failed when derbyall was run with J2ME. This is a new test and it uses java.sql.Driver. Hence excluded. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Changes to tests which use procedures in outparams.java -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- jdbcapi/batchUpdate.java and jdbcapi/StmtCloseFunTest.java are modified to use outparams/outparams30 depending on value of HAVE_BIG_DECIMAL. jdbcapi/StmtCloseFunTest.java was using a deprecated constructor for java.sql.Date, which is not available in JSR169. So the constructor java.sql.Date(long) is used instead. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Tests Run -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This patch changes tests only. I had run derbyall in J2SE and J2ME. 1 expected failure in J2ME. But I made few changes before submitting this patch. After the changes, I ran the individual tests successfully. Please review/commit this patch. NOTE: JIRA did not give me an option to add comments when I attached the patch files. So adding it as a separate comment.
          made changes -
          Attachment derby_453_outparams_patch1.status [ 12312759 ]
          Attachment derby_453_outparams_patch1.diff [ 12312758 ]
          Kathey Marsden made changes -
          Link This issue depends upon DERBY-518 [ DERBY-518 ]
          Hide
          Kathey Marsden added a comment -

          Part of the resolution for this issue was checked in with DERBY-518

          Show
          Kathey Marsden added a comment - Part of the resolution for this issue was checked in with DERBY-518
          Hide
          Kathey Marsden added a comment -

          replacing my earlier comment due to typo.

          I think the wrapper function for getBigDecimal by columnname, getBigDecimalStringFromName, should take a columnname parameter rather than getting it in the method.

          I think it would be good to have a class comment with the summary of the handling of BigDemcimal values in J2ME and an explanation of how tests that use BigDecimal values should be written so that they work with J2ME.

          I am not really comfortable with the mock up of data conversion exceptions for J2ME but don't really have a better idea #.

          Need to check the types listed in canConvertToDecimal. I think some of them are not quite right.

          Show
          Kathey Marsden added a comment - replacing my earlier comment due to typo. I think the wrapper function for getBigDecimal by columnname, getBigDecimalStringFromName, should take a columnname parameter rather than getting it in the method. I think it would be good to have a class comment with the summary of the handling of BigDemcimal values in J2ME and an explanation of how tests that use BigDecimal values should be written so that they work with J2ME. I am not really comfortable with the mock up of data conversion exceptions for J2ME but don't really have a better idea # . Need to check the types listed in canConvertToDecimal. I think some of them are not quite right.
          Kathey Marsden made changes -
          Comment [ I spoke with Deepa off-line about this and had a few comments on the patch.

          I think the wrapper function for getBigDecimal by columnname,canConvertToDecimal, should take a columnname parameter rather than getting it in the method just for the sake of clarity in the tests.

          I think it would be good to have a class comment with the summary of the handling of BigDemcimal values in J2ME and an explanation of how tests that use BigDecimal values should be written so that they work with J2ME.

          I am not really comfortable with the mock up of data conversion exceptions for J2ME but don't really have a better idea #:).
          Need to check the types listed in canConvertToDecimal. I think some of them are not quite right.

          ]
          Deepa Remesh made changes -
          Attachment derby-453.status [ 12311182 ]
          Attachment derby-453.diff [ 12311181 ]
          Hide
          Deepa Remesh added a comment -

          This patch will allow the test resultset.java to run J2ME/Foundation. The changes are:

          1. Added a new class ResultSet_BD, which provides wrappers for the following ResultSet methods:

          getBigDecimal(int columnIndex) ~ getBigDecimalString(ResultSet rs, int columnIndex)
          getBigDecimal(String columnName) ~ getBigDecimalStringFromName(ResultSet rs, int columnIndex)
          getObject(int columnIndex) ~ getObjectString(ResultSet rs, int columnIndex)
          getObject(String columnName) ~ getObjectStringFromName(ResultSet rs, int columnIndex)

          2 . Modified resultset.java to call methods in ResultSet_BD instead of the above ResultSet methods.

          3. resultset.java was using the following deprecated ResultSet methods:

          getBigDecimal(int columnIndex, int scale)
          getBigDecimal(String columnName, int scale)

          In ResultSet_BD, getBigDecimal(int columnIndex) and getBigDecimal(String columnName) are called instead of the deprecated methods. The master file resultset.out has been changed to match this.

          4. The exclude flag "runwithfoundation=false" has been removed from resultset_app.properties

          I have tested this patch by running resultset.java with Sun Java 1.4.2 and IBM WCTME 5.7 Foundation profile.

          Show
          Deepa Remesh added a comment - This patch will allow the test resultset.java to run J2ME/Foundation. The changes are: 1. Added a new class ResultSet_BD, which provides wrappers for the following ResultSet methods: getBigDecimal(int columnIndex) ~ getBigDecimalString(ResultSet rs, int columnIndex) getBigDecimal(String columnName) ~ getBigDecimalStringFromName(ResultSet rs, int columnIndex) getObject(int columnIndex) ~ getObjectString(ResultSet rs, int columnIndex) getObject(String columnName) ~ getObjectStringFromName(ResultSet rs, int columnIndex) 2 . Modified resultset.java to call methods in ResultSet_BD instead of the above ResultSet methods. 3. resultset.java was using the following deprecated ResultSet methods: getBigDecimal(int columnIndex, int scale) getBigDecimal(String columnName, int scale) In ResultSet_BD, getBigDecimal(int columnIndex) and getBigDecimal(String columnName) are called instead of the deprecated methods. The master file resultset.out has been changed to match this. 4. The exclude flag "runwithfoundation=false" has been removed from resultset_app.properties I have tested this patch by running resultset.java with Sun Java 1.4.2 and IBM WCTME 5.7 Foundation profile.
          Deepa Remesh made changes -
          Field Original Value New Value
          Assignee Deepa Remesh [ deepa ]
          Deepa Remesh created issue -

            People

            • Assignee:
              Deepa Remesh
              Reporter:
              Deepa Remesh
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development