You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Myrna van Lunteren <m....@gmail.com> on 2013/02/11 21:06:15 UTC
odd javadoc output since Friday, Feb 7, 2013
Hi,
Since Friday, I see some unusual output in the javadoc, it doesn't
seem to be flagging as a warning or error...Does anyone recognize
this?
------------------
...
[javadoc] Loading source files for package org.apache.derby.impl.jdbc...
[javadoc] Constructing Javadoc information...
[javadoc] C:\derby\trunk\java\testing\org\apache\derbyTesting\functionTests\tests\jdbc4\PreparedStatementTest42.java:28:
cannot find symbol
[javadoc] symbol : class JDBCType
[javadoc] location: package java.sql
[javadoc] import java.sql.JDBCType;
[javadoc] ^
[javadoc] C:\derby\trunk\java\testing\org\apache\derbyTesting\functionTests\tests\jdbc4\PreparedStatementTest42.java:59:
cannot find symbol
[javadoc] symbol : class JDBCType
[javadoc] location: class
org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest42
[javadoc] private static final JDBCType[] ILLEGAL_JDBC_TYPES
= new JDBCType[]
[javadoc] ^
(there's more like this)
This started with build at revision level 1443825, and includes the
following changes:
========================
r1443812 | myrnavl | 2013-02-07 16:51:09 -0800 (Thu, 07 Feb 2013) | 9 lines
DERBY-5977; Run storemore and possibly other store .sql tests in junit
harness using ScriptTest mechanism
Committing patch DERBY-5977_2, which:
- adds the StoreScriptsTest, and adds it to store._Suite
- modifies the .sql scripts run in it to have fully qualified resources
- modifies the canons affected to adjust for running them through the
ScriptTest mechanism
- removes the now unused properties files
- removes the .sql scripts run this way from derbyall's storemore suite.
------------------------------------------------------------------------
r1443712 | rhillegas | 2013-02-07 12:39:35 -0800 (Thu, 07 Feb 2013) | 1 line
DERBY-6000: Rename DatabaseMetaData.getMaxLogicalLOBSize() to
getMaxLogicalLobSize().
------------------------------------------------------------------------
r1443697 | rhillegas | 2013-02-07 12:17:08 -0800 (Thu, 07 Feb 2013) | 1 line
DERBY-6000: Add new PreparedStatement.setObject() overloads introduced
by JDBC 4.2.
------------------------------------------------------------------------
r1443599 | mamta | 2013-02-07 08:42:55 -0800 (Thu, 07 Feb 2013) | 7 lines
DERBY-6053 (Client should use a prepared statement rather than regular
statement for Connection.setTransactionIsolation)
Sinnce Connection object is already synchronized, no need to use
synchronized Hashtable, instead us HashMap.
Also parameterize HashMap object declaration for easier usage and
tighter type checking by the compiler.
========================
Re: odd javadoc output since Friday, Feb 7, 2013
Posted by Myrna van Lunteren <m....@gmail.com>.
On Wed, Feb 13, 2013 at 11:03 AM, Rick Hillegas
<ri...@oracle.com> wrote:
> On 2/13/13 10:11 AM, Myrna van Lunteren wrote:
>> Hi Rick,
>>
>> Thanks for fixing the previous warnings. However, now the javadoc
>> build fails, with the following:
>> [path_to_trunk]\build.xml:1388: Javadoc failed: java.io.IOException:
>> Cannot run program "[path_to_ibm16jvm]\bin\javadoc.exe": CreateProcess
>> error=206, The filename or extension is too long.
>>
>> Do you see this with Oracle jvms?
>>
>> Thx,
>> Myrna
>>
> Hm, haven't seen that error with my Oracle Java 7 or my Open JDK Java 8
> javadoc. Can't think of why the path to the javadoc executable would be
> longer now. The command line might be, though, because on Java 7 there's now
> a redundant "-J-mx500M" switch on the command line. Maybe the IBM javadoc is
> objecting to that. The error occurs on this javadoc invocation:
>
> <javadoc
> additionalparam="-J-mx500M"
> packagenames="org.*"
> access="private"
> breakiterator="yes"
> bootclasspath="${java16compile.classpath}"
>
> classpath="${out.dir};${java16compile.classpath};${jars.javadoc};${junit}"
> destdir="${out.javadoc.dir}/testing"
> windowtitle="Apache Derby V${major}.${minor} Test Javadoc"
> doctitle="Apache Derby V${major}.${minor} Test Javadoc"
> Footer="${javadoc.Footer}"
> bottom="Apache Derby V${major}.${minor} Internals -
> <i>Copyright &copy; 2004,${copyright.year} The Apache Software
> Foundation. All Rights Reserved.</i>"
> source="1.5"
>>
> <fileset dir="${derby.testing.src.dir}"
> excludesfile="${javadoc.exclusions}"/>
> <arg value="${xarg.doclint}"/>
> </javadoc>
>
> You might try removing the first argument and see if the javadoc builds
> then. That is, remove this line:
>
> additionalparam="-J-mx500M"
>
> Thanks,
> -Rick
Hi,
After some research & some trial and error, I found that this problem
is related to the fact that I'm building on windows. The
additionalparam was irrelevant.
To fix this, I needed to add the following property to the javadoc
target for the testingdocs:
useexternalfiles="yes"
We already had this for the javadoc for derbydocs, and demodocs
target. I don't fully understand what has caused this to be needed,
but I'm assuming that the error condition is correct and that some
filename of a new test is now too long for windows.
I'll log a JIRA issue, then change this.
Myrna
Re: odd javadoc output since Friday, Feb 7, 2013
Posted by Rick Hillegas <ri...@oracle.com>.
On 2/13/13 10:11 AM, Myrna van Lunteren wrote:
> On Tue, Feb 12, 2013 at 7:37 AM, Rick Hillegas<ri...@oracle.com> wrote:
>> Thanks for noticing this, Myrna. As Kristian noted, these warnings are
>> caused by the fact that the Java 7 javadoc tool can't find new Java 8
>> classes in java.sql. Those classes are referenced by the JDBC 4.2 support
>> added by DERBY-6000. I have checked in derby-6000-13-aa-fixJavadoc.diff at
>> subversion revision 1445196. That fixes the javadoc build for me on Java 7.
>>
>> Note that the javadoc does not build cleanly on Java 8. It spews pages of
>> warnings about missing @param and @throws annotations. I think that is a
>> separate problem which I will need to tackle later on.
>>
>> Thanks,
>> -Rick
>>
>>
> Hi Rick,
>
> Thanks for fixing the previous warnings. However, now the javadoc
> build fails, with the following:
> [path_to_trunk]\build.xml:1388: Javadoc failed: java.io.IOException:
> Cannot run program "[path_to_ibm16jvm]\bin\javadoc.exe": CreateProcess
> error=206, The filename or extension is too long.
>
> Do you see this with Oracle jvms?
>
> Thx,
> Myrna
>
Hm, haven't seen that error with my Oracle Java 7 or my Open JDK Java 8
javadoc. Can't think of why the path to the javadoc executable would be
longer now. The command line might be, though, because on Java 7 there's
now a redundant "-J-mx500M" switch on the command line. Maybe the IBM
javadoc is objecting to that. The error occurs on this javadoc invocation:
<javadoc
additionalparam="-J-mx500M"
packagenames="org.*"
access="private"
breakiterator="yes"
bootclasspath="${java16compile.classpath}"
classpath="${out.dir};${java16compile.classpath};${jars.javadoc};${junit}"
destdir="${out.javadoc.dir}/testing"
windowtitle="Apache Derby V${major}.${minor} Test Javadoc"
doctitle="Apache Derby V${major}.${minor} Test Javadoc"
Footer="${javadoc.Footer}"
bottom="Apache Derby V${major}.${minor} Internals -
<i>Copyright &copy; 2004,${copyright.year} The Apache Software
Foundation. All Rights Reserved.</i>"
source="1.5"
>
<fileset dir="${derby.testing.src.dir}"
excludesfile="${javadoc.exclusions}"/>
<arg value="${xarg.doclint}"/>
</javadoc>
You might try removing the first argument and see if the javadoc builds
then. That is, remove this line:
additionalparam="-J-mx500M"
Thanks,
-Rick
Re: odd javadoc output since Friday, Feb 7, 2013
Posted by Myrna van Lunteren <m....@gmail.com>.
On Tue, Feb 12, 2013 at 7:37 AM, Rick Hillegas <ri...@oracle.com> wrote:
> Thanks for noticing this, Myrna. As Kristian noted, these warnings are
> caused by the fact that the Java 7 javadoc tool can't find new Java 8
> classes in java.sql. Those classes are referenced by the JDBC 4.2 support
> added by DERBY-6000. I have checked in derby-6000-13-aa-fixJavadoc.diff at
> subversion revision 1445196. That fixes the javadoc build for me on Java 7.
>
> Note that the javadoc does not build cleanly on Java 8. It spews pages of
> warnings about missing @param and @throws annotations. I think that is a
> separate problem which I will need to tackle later on.
>
> Thanks,
> -Rick
>
>
Hi Rick,
Thanks for fixing the previous warnings. However, now the javadoc
build fails, with the following:
[path_to_trunk]\build.xml:1388: Javadoc failed: java.io.IOException:
Cannot run program "[path_to_ibm16jvm]\bin\javadoc.exe": CreateProcess
error=206, The filename or extension is too long.
Do you see this with Oracle jvms?
Thx,
Myrna
Re: odd javadoc output since Friday, Feb 7, 2013
Posted by Rick Hillegas <ri...@oracle.com>.
Thanks for noticing this, Myrna. As Kristian noted, these warnings are
caused by the fact that the Java 7 javadoc tool can't find new Java 8
classes in java.sql. Those classes are referenced by the JDBC 4.2
support added by DERBY-6000. I have checked in
derby-6000-13-aa-fixJavadoc.diff at subversion revision 1445196. That
fixes the javadoc build for me on Java 7.
Note that the javadoc does not build cleanly on Java 8. It spews pages
of warnings about missing @param and @throws annotations. I think that
is a separate problem which I will need to tackle later on.
Thanks,
-Rick
On 2/11/13 12:06 PM, Myrna van Lunteren wrote:
> Hi,
>
> Since Friday, I see some unusual output in the javadoc, it doesn't
> seem to be flagging as a warning or error...Does anyone recognize
> this?
>
> ------------------
> ...
> [javadoc] Loading source files for package org.apache.derby.impl.jdbc...
> [javadoc] Constructing Javadoc information...
> [javadoc] C:\derby\trunk\java\testing\org\apache\derbyTesting\functionTests\tests\jdbc4\PreparedStatementTest42.java:28:
> cannot find symbol
> [javadoc] symbol : class JDBCType
> [javadoc] location: package java.sql
> [javadoc] import java.sql.JDBCType;
> [javadoc] ^
> [javadoc] C:\derby\trunk\java\testing\org\apache\derbyTesting\functionTests\tests\jdbc4\PreparedStatementTest42.java:59:
> cannot find symbol
> [javadoc] symbol : class JDBCType
> [javadoc] location: class
> org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest42
> [javadoc] private static final JDBCType[] ILLEGAL_JDBC_TYPES
> = new JDBCType[]
> [javadoc] ^
> (there's more like this)
>
> This started with build at revision level 1443825, and includes the
> following changes:
>
> ========================
> r1443812 | myrnavl | 2013-02-07 16:51:09 -0800 (Thu, 07 Feb 2013) | 9 lines
>
> DERBY-5977; Run storemore and possibly other store .sql tests in junit
> harness using ScriptTest mechanism
> Committing patch DERBY-5977_2, which:
> - adds the StoreScriptsTest, and adds it to store._Suite
> - modifies the .sql scripts run in it to have fully qualified resources
> - modifies the canons affected to adjust for running them through the
> ScriptTest mechanism
> - removes the now unused properties files
> - removes the .sql scripts run this way from derbyall's storemore suite.
>
> ------------------------------------------------------------------------
> r1443712 | rhillegas | 2013-02-07 12:39:35 -0800 (Thu, 07 Feb 2013) | 1 line
>
> DERBY-6000: Rename DatabaseMetaData.getMaxLogicalLOBSize() to
> getMaxLogicalLobSize().
> ------------------------------------------------------------------------
> r1443697 | rhillegas | 2013-02-07 12:17:08 -0800 (Thu, 07 Feb 2013) | 1 line
>
> DERBY-6000: Add new PreparedStatement.setObject() overloads introduced
> by JDBC 4.2.
> ------------------------------------------------------------------------
> r1443599 | mamta | 2013-02-07 08:42:55 -0800 (Thu, 07 Feb 2013) | 7 lines
>
> DERBY-6053 (Client should use a prepared statement rather than regular
> statement for Connection.setTransactionIsolation)
>
> Sinnce Connection object is already synchronized, no need to use
> synchronized Hashtable, instead us HashMap.
>
> Also parameterize HashMap object declaration for easier usage and
> tighter type checking by the compiler.
> ========================
>
Re: odd javadoc output since Friday, Feb 7, 2013
Posted by Kristian Waagan <kr...@oracle.com>.
On 11.02.2013 21:06, Myrna van Lunteren wrote:
> Hi,
>
> Since Friday, I see some unusual output in the javadoc, it doesn't
> seem to be flagging as a warning or error...Does anyone recognize
> this?
Hi Myrna,
The warnings arise due to references to a class from Java SE 8.
That said, something has gone wrong with the configuration of the build
job. For some reason it was now set to scan for COBOL warnings (!) - my
guess is that a plugin or Jenkins update caused the configuration to be
lost.
I've tried to configure the build job correctly again, but right now it
doesn't behave as I want it to. This may be corrected once we fix the
current warnings (or deal with them in another way).
Here's what the build output has to say on the matter:
[WARNINGS] Parsing warnings in console log with parser Java Compiler (javac)
[WARNINGS] Parsing warnings in console log with parser JavaDoc Tool
[WARNINGS] Computing warning deltas based on reference build #1653
[WARNINGS] Ignore new warnings since this is the first valid build
[WARNINGS] Computing warning deltas based on reference build #1653
[WARNINGS] Ignore new warnings since this is the first valid build
I'd expect the build job to fail, but it doesn't.
Regards,
--
Kristian
>
> ------------------
> ...
> [javadoc] Loading source files for package org.apache.derby.impl.jdbc...
> [javadoc] Constructing Javadoc information...
> [javadoc] C:\derby\trunk\java\testing\org\apache\derbyTesting\functionTests\tests\jdbc4\PreparedStatementTest42.java:28:
> cannot find symbol
> [javadoc] symbol : class JDBCType
> [javadoc] location: package java.sql
> [javadoc] import java.sql.JDBCType;
> [javadoc] ^
> [javadoc] C:\derby\trunk\java\testing\org\apache\derbyTesting\functionTests\tests\jdbc4\PreparedStatementTest42.java:59:
> cannot find symbol
> [javadoc] symbol : class JDBCType
> [javadoc] location: class
> org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest42
> [javadoc] private static final JDBCType[] ILLEGAL_JDBC_TYPES
> = new JDBCType[]
> [javadoc] ^
> (there's more like this)
>
> This started with build at revision level 1443825, and includes the
> following changes:
>
> ========================
> r1443812 | myrnavl | 2013-02-07 16:51:09 -0800 (Thu, 07 Feb 2013) | 9 lines
>
> DERBY-5977; Run storemore and possibly other store .sql tests in junit
> harness using ScriptTest mechanism
> Committing patch DERBY-5977_2, which:
> - adds the StoreScriptsTest, and adds it to store._Suite
> - modifies the .sql scripts run in it to have fully qualified resources
> - modifies the canons affected to adjust for running them through the
> ScriptTest mechanism
> - removes the now unused properties files
> - removes the .sql scripts run this way from derbyall's storemore suite.
>
> ------------------------------------------------------------------------
> r1443712 | rhillegas | 2013-02-07 12:39:35 -0800 (Thu, 07 Feb 2013) | 1 line
>
> DERBY-6000: Rename DatabaseMetaData.getMaxLogicalLOBSize() to
> getMaxLogicalLobSize().
> ------------------------------------------------------------------------
> r1443697 | rhillegas | 2013-02-07 12:17:08 -0800 (Thu, 07 Feb 2013) | 1 line
>
> DERBY-6000: Add new PreparedStatement.setObject() overloads introduced
> by JDBC 4.2.
> ------------------------------------------------------------------------
> r1443599 | mamta | 2013-02-07 08:42:55 -0800 (Thu, 07 Feb 2013) | 7 lines
>
> DERBY-6053 (Client should use a prepared statement rather than regular
> statement for Connection.setTransactionIsolation)
>
> Sinnce Connection object is already synchronized, no need to use
> synchronized Hashtable, instead us HashMap.
>
> Also parameterize HashMap object declaration for easier usage and
> tighter type checking by the compiler.
> ========================