Proposed source code and regression test suite improvement projects for JDK 9

Stuart Marks stuart.marks at
Tue Dec 17 13:57:43 PST 2013

Hi Joe,

+0.9999998! :-)

I think that it's a fine goal to complete all of the efforts we began in JDK 8. 
But there should be some priorities assigned here. As you know, I'm a champion 
of warnings cleanup. But I think dealing with the test failures is *more* 
important than warnings. If we're warnings-free at the end of JDK 9 but we still 
have test failures, I think we'd have missed the boat.

As you know, the situation is essentially that we cannot get a complete test run 
without at least one test failure. This makes it difficult to assess the quality 
of a change being tested, it wastes time, generally slows things down, and is a 
barrier to introducing a more streamlined system for building, testing, and 

I'd like to see us focus our efforts at getting us test-failure-free as quickly 
as feasible in the JDK 9 development cycle, while continuing warnings and 
doclint cleanup as a side activity.



On 12/13/13 11:13 AM, Joe Darcy wrote:
> Hello,
> With JDK 9 about to get underway, I'd like to propose several source code and
> regression test suite improvement efforts to tackle during this release.
> Over the years, the JDK code base has accumulated a bit of technical debt in
> various areas. In JDK 8, efforts have already been underway to pay down that
> technical debt including:
> * doclint cleanup: core libs is now doclint-clean and over 1,000 of the doclint
> warnings in client libs have been fixed [1]
> * javac lint cleanup: many lint issues have been resolved [2] and a number of
> lint categories are configured to cause fatal errors if they are found when
> building the jdk repo [3]
> * test stabilization: numerous regression tests in the jdk repo failed
> intermittently, ran for an unnecessarily long time, or suffered from other flaws
> that have been corrected [4]
> For JDK 9, I propose we complete these initiatives for the code in the langtools
> and jdk repositories (then possibly extend to jaxp, jaxws, etc.):
> * Source code in java.* and javax.* is doclint clean for public and protected
> elements and the docs build is configured to fail on a doclint issue. The
> generated javadoc is also tidy clean.
> * Java sources compile cleanly under "javac -Xlint:all -Werror" and the build is
> configured to fail if a lint issue is introduced.
> * There are no chronic intermittently failing tests and clean jdk test runs are
> a common occurrence.
> Reducing C/C++ build warnings would be a worthwhile goal too, but is complicated
> by the number of C/C++ compilers used across different supported platforms. In
> addition, various structural properties of javadoc should be regularized ({@code
> Foo} instead of <code>Foo</code>, instead of package.html,
> @throws instead of @exception, etc.) and the Java source code should use
> contemporary coding idioms (lambda, diamond, etc.).
> There are thousands of lint and doclint issues remaining, but they can largely
> be addressed in parallel without interfering with each other, as was seen in JDK
> 8. While some effort will be required to get these issues addressed initially,
> once the source code and tests are in a clean state, we would benefit from
> tooling support to prevent certain classes of errors from being introduced.
> Comments?
> Thanks,
> -Joe
> [1]
> [2]
> [3] JDK-8024643 Turn on javac lint checking in building the jdk repo
> JDK-8024603 Turn on javac lint checking for auxiliaryclass, empty, and try in
> jdk build
> [4]

More information about the jdk9-dev mailing list