OpenJDK adoption by Java User Groups

[Jonathan Gibbons]

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