Separate out the small number of build targets which really require JDK1.4 features from the bulk of the targets which ought to compile cleanly against small device libraries

• Key: DERBY-3984
• Type: Improvement
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Rick Hillegas
• Reporter: Rick Hillegas
• Component/s: Build tools
• Affects Version/s: 10.5.1.1
• Fix Version/s: 10.5.1.1

Description

It would be good to make jsr169 the default platform for most Derby build targets. This will allow the build to raise compile-time errors when a checkin violates the small-device contract. Only a small number of features (listed in DERBY-3966) really require JDK1.4. Something like the following may work:

1) Finish up DERBY-3966 so that java4compile.classpath defaults to an approximation of ${jdk14xmlSupport}: ${java15compile.classpath}

2) Make compile.classpath default to jsr169compile.classpath

3) Fortunately, jsr169compile.classpath itself already defaults to ${jsr169stubs}:${java14compile.classpath}

4) Change a (hopefully) small number of targets to use java14compile.classpath rather than compile.classpath

Comments

[Rick Hillegas]

Attaching derby-3984-01-aa-defaultToJsr169.diff. This patch makes the changes described above, defaulting most build targets to use the classpath for small device platforms.

The practical consequence of applying this patch is this: When someone checks in a change which violates the small device contract, the build will break for developers who have wired the small device jars into their build environment. (Developers do that by setting the jsr169compile.classpath variable in ant.properties.) This will give us early warning when the small device contract has been broken, prompting us to fix these problems quickly.

Some build targets had to be changed to explicitly keep using the JDK 1.4 classpath as they do today. I suspect that we would prefer that some of these targets defaulted to the small device classpath. Fixing the code to make that possible is not part of this JIRA. Follow-on JIRAs can be filed to fix these targets. In particular, you will notice the following:

1) The tools are built against the JDK 1.4 classpath.

2) So is the OSGI support.

3) So are a lot of tests.



Touches the following files:

M build.xml
M tools/ant/properties/compilepath.properties

Sets the default compiler classpath to be the small device classpath. Fixes up the stub compilers to use the appropriate classpaths.


M java/stubs/jsr169/javax/sql/RowSet.java

Removes some useless imports which were breaking the build.


M java/demo/toursdb/build.xml

Compiles toursdb against the JDK 1.4 libraries.


M java/tools/org/apache/derby/impl/tools/build.xml

Compiles the tools against the JDK 1.4 libraries.


M java/engine/org/apache/derby/osgi/build.xml

Compiles the OSGI support against the JDK 1.4 libraries.


M java/engine/org/apache/derby/iapi/jdbc/build.xml

Moves the compilation of an XA support class into a target which uses the JDK 1.4 libraries.


M java/testing/org/apache/derbyTesting/unitTests/build.xml
M java/testing/org/apache/derbyTesting/functionTests/tests/i18n/build.xml
M java/testing/org/apache/derbyTesting/functionTests/tests/lang/build.xml
M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/build.xml
M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/build.xml
M java/testing/org/apache/derbyTesting/functionTests/tests/perf/build.xml
M java/testing/org/apache/derbyTesting/functionTests/tests/store/build.xml
M java/testing/org/apache/derbyTesting/functionTests/tests/tools/build.xml
M java/testing/org/apache/derbyTesting/functionTests/tests/memory/build.xml
M java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/build.xml
M java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/build.xml
M java/testing/org/apache/derbyTesting/functionTests/harness/build.xml
M java/testing/org/apache/derbyTesting/functionTests/util/build.xml
M java/testing/org/apache/derbyTesting/junit/build.xml
M java/testing/org/apache/derbyTesting/perf/build.xml

Compiles a lot of test classes against the JDK 1.4 libraries.

[Rick Hillegas]

Tests ran cleanly for me against the derby-3984-01-aa-defaultToJsr169.diff patch except for the following error in the NetworkServerMBeanTest. I re-ran that test standalone and it passed cleanly.

There was 1 error:
1) testAttributeAccumulatedConnectionCount(org.apache.derbyTesting.functionTests.tests.management.NetworkServerMBeanTest)java.security.PrivilegedActionException: javax.management.InstanceNotFoundException: org.apache.derby:type=NetworkServer,system=c013800d-011e-5fa5-98ef-ffffe1d7aa3e
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getAttribute(MBeanTest.java:379)
at org.apache.derbyTesting.functionTests.tests.management.NetworkServerMBeanTest.testAttributeAccumulatedConnectionCount(NetworkServerMBeanTest.java:93)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:105)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
Caused by: javax.management.InstanceNotFoundException: org.apache.derby:type=NetworkServer,system=c013800d-011e-5fa5-98ef-ffffe1d7aa3e
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1010)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:627)
at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:659)
at org.apache.derbyTesting.functionTests.tests.management.MBeanTest$4.run(MBeanTest.java:382)
... 41 more

FAILURES!!!
Tests run: 9406, Failures: 0, Errors: 1

[Myrna van Lunteren]

This patch is based on the first attempt at check-in for DERBY-3988...Could you please update it ?
The patch didn't apply cleanly to the current trunk (although it only had a problem with trunk/build.xml...and I was able to change that quite easily manually, or I could apply to revision 727106, but I'd like us to be on the same level).

[Rick Hillegas]

Thanks for catching that, Myrna. Could you try derby-3984-01-ab-defaultToJsr169.diff, which I've just attached? Thanks!

[Myrna van Lunteren]

Thanks Rick, the patch applied cleanly now. I'll try some builds and run some tests...

I did start with a verification pass (compare my svn diff result with your patch) and it appears the java files in <trunk>/java/stubs/jsr169/*/* do not have svn:eol-style native set, which causes my svn diff to look quite different for RowSet.java.
When you get ready to commit, perhaps you can switch on the native property. Or we could do it for all stubs/jsr169 files some other time.

[Rick Hillegas]

Thanks, Myrna. I think that we should treat the svn:eol-style issue as a separate JIRA. Probably all of the source files under java/stubs will need this improvement.

[Myrna van Lunteren]

Actually, looks like the props are in place for the jdbc3 and jdbc4 stubs. But yeah, we should deal with that separately.

I did some experiments, and added a silly method to the Driver169 class:
   public void bla() {
        java.sql.Driver dr = null;
    }
As expected based on the (description of the) patch, the build with this passed when $HOME/ant.properties did not have jsr169compile.classpath set and failed when it *was* set.

testAttributeAccumulatedConnectionCount has failed like that for you before, and I think it's probably DERBY-3689.
I've not run any specific tests.

Based on this, I say +1 on the change.

Maybe we should have require committers to build with jsr169? Or is that too big a requirement? Or at least add a comment to the wiki (I think there is an area for committers somewhere).

[Rick Hillegas]

Hi Myrna,

Thanks for the review and for running those experiments.

I agree that it would be worthwhile to add a comment to the wiki, advising committers that they should configure their build environment so that they get compile-time checks for all of our platforms. The instructions for how to do this are in the new BUILDING.html attached to DERBY-3985.

[Rick Hillegas]

Committed derby-3984-01-ab-defaultToJsr169.diff at subversion revision 728965.

[Rick Hillegas]

Attaching derby-3984-02-aa-CallableStatement.diff. This removes a useless import of BigDecimal from the jsr169 stub for CallableStatement. This import broke Ole's continuous integration build. Committed at subversion revision 728990.

[Rick Hillegas]

Attaching derby-3984-03-aa-securityBuild.diff. This converts the security build target to use the jdk 1.4 libraries. There is a reference to Throwable.getCause() in one of the classes compiled by this target:

M java/engine/org/apache/derby/security/build.xml

Committed at subversion revision 729007.

[Rick Hillegas]

Attaching derby-3984-04-aa-mbeansBuild.diff. The mbeans support also references Throwable.initCause() and getCause(), meaning that we need to use the 1.4 libraries to compile the mbeans support. Committed the following at subversion revision 729014:

M java/engine/org/apache/derby/mbeans/build.xml

[Knut Anders Hatlen]

I was under the impression that initCause() and getCause() were part of the Foundation 1.1 API (see http://java.sun.com/javame/reference/apis/jsr219/java/lang/Throwable.html). Could it be that the Tinderbox compiles against Foundation 1.0 instead of 1.1?

[Rick Hillegas]

Another target converted to use the 1.4 libraries because the code references Throwable.initCause():

M java/engine/org/apache/derby/iapi/reference/build.xml

Committed at subversion revision 729017.

[Rick Hillegas]

Knut, you're right. I'm going to back out the previous string of patches (including derby-3984-01-ab-defaultToJsr169.diff) until the tinderbox has been fixed to use CDC/FP 1.1.

[Rick Hillegas]

Reverted 728990, 729014, 729017, and 729007 at revision revision 729032.

[Rick Hillegas]

Reverted 728965 at subversion revision 729033.

[Rick Hillegas]

Reapplying derby-3984-02-aa-CallableStatement.diff. The import of BigDecimal is useless. Committed at subversion revision 729034.

[Rick Hillegas]

Thanks to Ole for adjusting the tinderbox tests to use the CDC/FP 1.1 libraries rather than the 1.0 libraries (DERBY-3995). I have re-committed derby-3984-01-ab-defaultToJsr169.diff at subversion revision 731603.