db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1078) Be able to build Derby when JAVA_HOME is set 1.6
Date Wed, 03 May 2006 06:53:47 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1078?page=comments#action_12377524 ] 

Andrew McIntyre commented on DERBY-1078:

Committed revision 399164. This fixes a couple more tests under jdk131, specifically stress.multi
and dataSourcePermissions related tests. This should finally return the jdk131 tests to the
state prior to any DERBY-1078 changes. See:


The testSecMec problem is specific to the test, and it appears we should not run SqlExceptionTest.junit
under jdk131 due to its use of the jdk14-specific initCause() method. I believe the DerbyNetAutoStart.java
test to be instability in the test. See DERBY-803.

BUT, testing with IBM JDK 1.3.1 is showing a huge amount of failures due to a problem with
the ij parser. The problem manifests itself as follows:

*** Start:  big jdk1.3.1 DerbyNet derbynetmats:derbynetmats 2006-04-30 01:04:17 ***
4 del
< 0 rows inserted/updated/deleted
JAVA ERROR: java.lang.NoSuchFieldError: org.apache.derby.tools.ij.ij: field tokenImage not

tokenImage is a String array in the interface ijConstants, which ij.java implements. So, the
ij parser should be able to access the array by virtue of inheritence. It's not clear why
the IBM jdk can't find the tokenImage array in ijConstants. I'm searching for a resolution
to the problem, but if I cannot find one, I may have to back all of these changes out after
we branch 10.2.

> Be able to build Derby when JAVA_HOME is set 1.6
> ------------------------------------------------
>          Key: DERBY-1078
>          URL: http://issues.apache.org/jira/browse/DERBY-1078
>      Project: Derby
>         Type: Improvement

>   Components: Build tools
>     Versions:
>     Reporter: Rick Hillegas
>     Assignee: Andrew McIntyre
>      Fix For:
>  Attachments: derby-1078.diff, derby-1078_part2.diff
> Currently, the 1.4 compiler is used to build most of Derby. We use the 1.6 compiler to
(optionally) build the JDBC4 support. If you try to build Derby in a shell window with a 1.6
JAVA_HOME, the 1.4 bits will fail to build. This is because those bits do not satisfy the
JDBC4 contract. In addition, even if you could build those bits under 1.6, the 1.6 class files
would fail to load on a 1.4 vm.
> We need to be able to use 1.6 as our default build environment but still generate jar
files which run on 1.4 and 1.5. There may be compiler switches which allow this. If not, building
in a 1.6 environment could fault in the 1.4 compiler as necessary.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message