[
http://issues.apache.org/jira/browse/DERBY-1079?page=comments#action_12374223 ]
Rick Hillegas commented on DERBY-1079:
--------------------------------------
As a first step, I would like to check in the latest version of JavaCC (4.0).
This involves making the following change to
trunk/java/tools/org/apache/derby/impl/tools/build.xml. For some reason, two
generated grammars (ij and mtGrammar) are currently compiled against the jdk1.3
libraries; the new JavaCC generates code which invokes a RuntimeException
constructor not available in 1.3. This change moves that grammar compilation to
the corresponding jdk14 build target:
< <exclude name="${derby.dir}/impl/tools/ij/ij.java"/>
< <exclude name="${derby.dir}/impl/tools/ij/mtGrammar.java"/>
78,79d75
< <include name="${derby.dir}/impl/tools/ij/ij.java"/>
< <include name="${derby.dir}/impl/tools/ij/mtGrammar.java"/>
The new JavaCC does not generate code using the "enum" keyword for variable
names. These illegal variable names choked the jdk1.6 javadoc tool. Using the
new JavaCC, I am able to build javadoc under 1.6.
I will run derbyall before proceeding with this patch. Does anyone know why I
should not make this change and upgrade our checked-in version of JavaCC to the
latest 4.0 version?
> Build javadoc under jdk 1.6
> ----------------------------
>
> Key: DERBY-1079
> URL: http://issues.apache.org/jira/browse/DERBY-1079
> Project: Derby
> Type: Bug
> Components: Build tools
> Versions: 10.2.0.0
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
> Fix For: 10.2.0.0
>
> We would like to build the javadoc under 1.6 so that all of the classes
> (including the JDBC 3 and JDBC 4 support) end up in the same directory tree.
> This is particularly important for the published API which we expose to
> end-users.
> Right now you can do the following:
> 1) Build the whole codeline using the 1.4 compiler for most classes and the
> 1.6 compiler for the JDBC4 support.
> 2) Build javadoc in a 1.4 environment (with JAVA_HOME set to 1.4). This runs
> step (1) if it has not already happened. This javadoc excludes the JDBC4
> support because generics-laden JDBC4 signatures choke the 1.4 compiler.
> 3) Build the javadoc in a 1.6 environment (with JAVA_HOME set to 1.6). This
> will fail if you have not run step (1); this is because you can't build Derby
> in a 1.6 environment yet. This also generates a number of warnings because
> the 1.6 javadoc tool objects to code generated by the JAVACC grammar tool;
> JAVACC turns out code with loop variables distastefully named "enum". In
> addition, today, the 1.6 javadoc excludes the JDBC4 support.
> We would like to end up with the following situation:
> a) If your ant.properties points at a 1.6 installation, then the javadoc
> targets will use the 1.6 javadoc tool and will include Derby's JDBC4 support.
> This will work regardless of whether you have already built the class tree.
> If you have not already built the class tree, then we will compile it under
> scenario (1) above.
> b) If, however, your ant.properties does not point at a 1.6 installation,
> then the javadocs target will continue to use the 1.4 javadoc tool to build
> only the classes built today. The JDBC4 support will be excluded from this
> javadoc.
> c) As part of releasing 10.2, we will build the javadoc under scenario (a).
> d) Once 1.6 exits beta and becomes a production vm, the community can debate
> when we want to fix DERBY-1078 and require 1.6 in the build environment.
--
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
