Ability to compile under JDK1.5

• Key: DERBY-73
• Type: Improvement
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Andrew McIntyre
• Reporter: Jeremy Boynes
• Component/s: Build tools

Description

Compilation fails when using JDK1.5 due to
1) no specification of language level
2) use of "enum" as identifier

The language issue results in the use of the new StringBuilder class for string concatenation resulting in code that will not run on earlier JVMs.

Dropping the langauge level will allow it to compile but warnings are generated due to the use of "enum" as an identifier; with 1.5 this becomes a reserved word

Comments

[Jeremy Boynes]

Adds derby.compile.source and derby.compile.target parameters to force the language level used by javac
These can be specified in ${user.home}/ant.properties

Changes the name of "enum" variables to "e"

[Daniel John Debrunner]

Applied the part of the patch that fixed the enum name use.

Had trouble applying all the portions of the patch related to the build.xml files. Managed to patch most of the build.xml files, but then my build seemed to fail because, derby.compile.source and derby.compile.target were not set. Might need to ensure these are set by default otherwise applying this patch will break everyone's build. Maybe I just missed something obvious?


Sending java\engine\org\apache\derby\iapi\store\access\RowUtil.java
Sending java\engine\org\apache\derby\impl\sql\catalog\DataDictionaryImpl.java
Sending java\engine\org\apache\derby\impl\sql\compile\FromBaseTable.java
Sending java\engine\org\apache\derby\impl\sql\compile\FromList.java
Sending java\engine\org\apache\derby\impl\sql\compile\FromTable.java
Sending java\engine\org\apache\derby\impl\sql\depend\BasicDependencyManager.java
Sending java\engine\org\apache\derby\impl\sql\execute\InternalTriggerExecutionContext.java
Sending java\engine\org\apache\derby\impl\sql\execute\rts\RealBasicNoPutResultSetStatistics.java
Sending java\engine\org\apache\derby\jdbc\EmbedPooledConnection.java
Sending java\tools\org\apache\derby\impl\tools\ij\AttributeHolder.java
Sending java\tools\org\apache\derby\impl\tools\ij\ConnectionEnv.java
Sending java\tools\org\apache\derby\tools\URLCheck.java
Transmitting file data ............
Committed revision 122617.

[Jeremy Boynes]

I was originally concerned about defaulting the code version levels and thought it would be better set in ~/ant.propeties.

Attached is a patch that sets the versions in modern.properties and reapplies the build.xml changes. I am not able to test with Jikes.

[Andrew McIntyre]

DERBY-112 is probably a duplicate of this issue. Please comment if there is additional work to be done on this issue.

[Heikki Linnakangas]

JavaCC version 3.2 changes the variable name from "enum" to "e". It's The javacc.jar in tools/java should be upgraded.

[Andrew McIntyre]

JavaCC 3.2 has an issue with lookahead that causes a failure in the test lang/db2compatibility.sql.

However, I have tried the recently released JavaCC 4.0, and it fixes that issue and all tests passed cleanly, so at some point we will likely upgrade to that version.

[Andrew McIntyre]

Patch with necessary changes for building with JavaCC 4.0. OPTIMIZE_TOKEN_MANAGER is no longer a supported option, and the generated code for mtGrammar includes a catch block for RuntimeException which uses a new method in RuntimeException introduced in JDK 1.4, so it became necessary to move the compilation of mtGrammar.java into the impl_tools_jdk14 target.

[Andrew McIntyre]

Linking this issue to DERBY-73. The code generated by javacc 3.1 uses enumerations called "enum" which is now a keyword in Java 1.5/5.0. This is probably a duplicate of DERBY-73, but I'm leaving this open until there is time to investigate further.

[Andrew McIntyre]

FYI, I've attached a patch to DERBY-73 that allows updating to JavaCC 4.0, which does not generate code with variables named 'enum'. Linking that issue to this. I ran all tests with JavaCC 4.0 and saw no failures. 4.0 also does not contain a bug in JavaCC 3.2 that caused an exception in a rare case involving lookahead.

[Andrew McIntyre]

Fixed by changes to DERBY-1078