OpenJDK adoption by Java User Groups (original) (raw)

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Thu Dec 8 21:20:27 PST 2011

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/kindsofcompatibility] -- 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

More information about the jdk8-dev mailing list