OpenJDK adoption by Java User Groups

[Sebastian Sickelmann]

Am 08.12.2011 22:38, schrieb 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
Another fine thing would be to have an public reachable review system.
Like gerrit(for git) just for mercurial. I think inside of Oracle there 
is such
a system, at least most of the webrevs from oracle folks are hosted on
a server with the name http://cr.openjdk.java.net.

Providing patches through webrev is not the easiest part for anyone
who can move the OpenJdk forward. I think this is true at least for
those who uses windows as there primary development plattform.
Pushing to hg server that creates webrev for them would be really cool.

-- Sebastian