Java User Group - Warnings clean-up hack day - 31st of Jan

[Martijn Verburg]

Hi Stuart,

> I don't know if anyone from Oracle will be involved in this. I can try to
> hang out on the #openjdk IRC channel, and I can review and push a couple of
> the patches if you need help doing so. What time do you guys think you'll be
> online?

We'll be on-line around 1830+ GMT, on the 31st (tonight for me).  Mike
and I (and
perhaps some others) will jump on IRC (we won't have all 20+ jump on as it'll
create too much noise).

We had 45 people volunteer this time, but have capped it at 20 :-).  As we get
the VM and the process tightened down people should be able to start working on
things outside of an organised hack night.

> If you need to track the work on a wiki, the obvious place is a page next to
> the previous Warnings Cleanup Day wiki, which has been moved from
> wikis.sun.com to wikis.oracle.com [1]. Unfortunately that's actually an
> Oracle wiki, not an OpenJDK wiki, though we do have OpenJDK material on
> there. It's not entirely clear to me how external folks can get access to
> this wiki. (I know that some external folks do have access, but it's through
> a process different from OpenJDK.) Dalibor might have a better idea.

I've at least got read access to that wiki (I grabbed a login after
Dalibor made the
shift).

> I've added an awk script to the main Warnings Cleanup page [2] that does
> some analysis of warnings from a build log. I used this script to keep track
> of the warnings counts as the cleanup fixes were integrated. This script
> breaks down the warnings by "build step", that is, a run of javac from a
> particular Makefile in a jdk/make subdirectory. It might be effective to use
> the report from this script to target a build step with relatively few
> warnings and to get it all the way to zero. When this occurs, -Werror can be
> added to its Makefile to prevent warnings from being reintroduced. Another
> approach would be to find a build step with hundreds or thousands (!) of
> warnings and then further break it down to file granularity.

I ran this script over the latest build that I have
(http://hg.openjdk.java.net/jdk8/tl/jdk).
It's really useful but I think there might be a bug?  The complete
output I got was:

files warnings dir
    2      0   make/java/java
    1      0   make/java/java/reflect
    1      0   make/java/java/reflect
    1     34   make/java/awt
    1      2   make/java/beans
   10      0   make/java/invoke
    1     10   make/javax/swing/plaf
    1      0   make/sun/awt
    1      0   make/sun/xawt
    1      0   make/sun/tracing
    2      0   make/com/sun/net/httpserver
    2      0   make/com/sun/tracing
    1      0   make/com/sun/tracing/dtrace
    1      0   make/com/sun/tracing/dtrace

But when analysing the build.log file by hand, I could see other large
warning counts
e.g. 77 warnings for democlasses/demo/jfc/Font2DTest/src

Actually that perhaps makes sense as I assume the democlasses are excluded? If
that's the case then http://hg.openjdk.java.net/jdk8/tl/jdk has only
46 warnings left,
we might need to look at another branch to work on at that stage
(recommendations
welcome).

The strategy of winding the warnings down to 0 sounds good, we'll try
to follow that.

> (Crap. I've just realized that I never pushed Deepak Bhole's java.text
> patches from December. To avoid conflicts, I'd suggest avoiding changes to
> src/share/classes/java/text. Other areas should be fair game.)

Noted, if they get pushed before the event I'll just inform everyone
to hg fetch before
running the first build.

> In any case, this script counts warnings the same way I did for the previous
> warning stats, so we can get consistent numbers.

Cool, thanks again for the script.

> Good luck with the event, and I hope to see you on IRC tomorrow.

Cheers,
Martijn