OpenJDK adoption by Java User Groups

[Martijn Verburg]

>> 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

We could certainly list projects like this on a Adopt OpenJDK site and
work with
the JUG leaders to put together teams.  There's never any guarantee that a
particular project will get picked up, but with such a diverse group
of developers
there would hopefully be some sort of adoption yes.

Cheers,
Martijn