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