On 12/08/2011 12:47 PM, Martijn Verburg wrote:
Hi all,
I think the experiment was pretty successful the other night and Mike
and I have also figured out some ways to
streamline the process even further for future events (pre-built VMs
with the initial build already executed once
work pretty well if you're running adequate hardware).
We're keeping the VM up-to-date with jtreg and the latest commits and
will be organising a regular monthly
OpenJDK hack night for the LJC to work on low hanging fruit such as
javac warnings.
A few of the more enthusiastic folk will probably keeping submitting
ad-hoc patches, but what would you like us
to work on as a group next time? There is still ~8500 warnings last
time I checked so we'd probably be quite
happy to run through a similar exercise again.
Once we've found our feet (and made sure we're not making life
difficult for all of you) then we'll spread the
program further to other JUGs.
We're also exploring where we can help out with documentation, but
I'll cover that separately.
Cheers,
Martijn
Martijn,
There were a number of surprises on Warnings Day last week.
One was the amount of enthusiasm. Another was the difficulty of
staying within the prescribed bounds, such as "no public API changes".
Which brings me to a suggestion I've been meaning to make for a
while, and is relevant here.
For changes to the OpenJDK code itself, you can see the sort of
controls we go through to make sure nothing bad happens. That can
be somewhat limiting for folk who want more creative freedom ;-)
One possibility is the development of tools which are not themselves
part of the OpenJDK itself, but which are useful to folk working on
OpenJDK. One such category of tools is intelligent comparison tools.
Given two copies of a library (such as rt.jar and tools.jar), analyze
them to report on differences. A bunch of different comparison
tests could be done:
-- have any public API signatures changed (where "public" means
"documented/published")
-- have any public API signatures changed (where "public" means
the Java access modifier)
-- if any signatures have changed, are the changes binary compatible,
source compatible, etc.
[See http://blogs.oracle.com/darcy/entry/kinds_of_compatibility]
-- have any method bodies changed
-- and so on
I wonder it would make sense for interested groups, such as JUGs,
to team up and take on such projects.
-- Jon
