Skip to main content
Last updated January 26, 2015 10:27, by Martijn Verburg

UPDATE - THIS WORK IS PRETTY MUCH DONE! - See Joes Darcy's blog post

This section takes you through how you can help clean up javac warnings in the OpenJDK and submit patches, reducing the number of bugs in Java itself! Any questions, comments, feedback etc please send to the Adopt OpenJDK group (if you have no luck there, try posting to the JUG leaders list).


See Events

Project Sponsors

The Adopt OpenJDK reviewers will liaise with the following sponsors to get patches into the right groups.

  • Stuart Marks --> core-libs.
  • Artem Ananiev --> swing and awt (client)

Instructions for instructors

See Instructions for instructors

What fixes are accepted (The barrier for patches)

The barrier for the OpenJDK committers to accept a patch (even one as seemingly simple as a warning clean-up) is exceptionally high. The instructors will be checking a wide variety of conditions before your patch can be accepted. Please survey the list below and try to ensure your patch meets the quality bar.

Main focus: simple, minimal, and risk-free warnings fixes, most of the javac warnings are easy fixes. However, we've listed some gotchas below:

  • For this exercise avoid making any API changes or any large scale refactorings.
  • Avoid @SuppressWarnings except where it is clearly necessary.
  • Make sure the whitespace formatting is the same!
  • Only look at javac warnings, do not fix warnings from your IDE! They can bring up warnings that are not javac warnings.
  • Use javap -c <class file>, e.g. javap -c java.awt.Frame to analyse byte code before and after the change
    • byte code should ideally be the same/very similar
  • Be very careful when looking at fixes for Generics. For example, quite often if you unravel the code you can figure out what the Generic should be as opposed to using <?>.

Serial UIDs

The compiler will occasionally issue warnings of the form: "warning: [serial] serializable class Foo has no definition of serialVersionUID". Usually the fix is to add a static serialVersionUID field initialized to the proper value.

To get the proper serial version UID value, run the "serialver" tool using a *released* version of the JDK:

serialver java.misc.Foo

 java.misc.Foo:    static final long serialVersionUID = 362498820763181265L;

Paste this line into, with the addition of the private modifier:

 private static final long serialVersionUID = 362498820763181265L;

Note however that anonymous inner classes should not have a serialVersionUID. Instead, use @SuppressWarnings("serial") to suppress the serialization warning for this case.

Detailed Explanation of SerialVersionUID

Hardware Requirements

See Hardware Requirements

Attendee Instructions

See Attendee Instructions

Run the jdk library build

See Run the JDK build

Check for warnings

NOTE $SOURCE_CODE is where you installed the source code to. If you are using the Pre packaged VM then this is /home/openjdk/sources

 cd jdk8_tl/jdk/make
 ./countWarnings.awk build.log

You'll see output similar to:

 files   warnings   dir
    ..         ..   ..
     8        333   make/javax/swing/plaf
    ..         ..   ..
  1. Then look in the build.log file to find out details about the outstanding warnings.
  2. Search for the package name e.g. javax/swing/plaf and then Running javac to narrow it down.

Fix warnings

Remember not to overlap with other efforts that are going on. If you're part of a global hack day, your instructor(s) will be co-ordinating with other teams. Fix some warnings in the source code (these are mainly under $SOURCE_CODE/jdk8_tl/jdk/src/share/classes). Depending on whether you're using the new or old build system, you'll then want to execute a build.

New Build

 make images
 tail -f build.log

Old Build

 tail -f build.log

Check the log

When the build is done you should see something in the build.log file like:

 Done Processing SUBDIRS: tools java javax sun com    org sunw jpda mkdemo mksample launchers
 linux i586 1.8.0-internal build finished: 12-04-21 19:08

Then execute:

 ./countWarnings.awk build.log

Check in the build.log file that the warnings you fixed are gone

NOTE: The build will be much faster the 2nd time around, it only compiles in and around the area that you have changed.
NOTE: You should see a much smaller set of warnings as the build.log only shows the results of the smaller build (i.e. What you've changed).

Run jtreg tests

See Run jtreg tests

Repeat the Process

See Repeat the process

Create Patches

See Create Patches

Submit Patches

See Submit Patches

Back to Adopt OpenJDK

Please Confirm