[ 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: http://people.apache.org/~fuzzylogic/derby_test_results/main/testlog/jdk131/392471-derbyall_diff.txt 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 4a4 JAVA ERROR: java.lang.NoSuchFieldError: org.apache.derby.tools.ij.ij: field tokenImage not found 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: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Andrew McIntyre > Fix For: 10.2.0.0 > 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
