Javac and backward compatibility

It's a nice start of the week to read this. As a Linux distro guy this makes me really happy as it's a first step in the right direction to fix some of the long standing problems for "source-first" developers. Java programs are full of references to libraries that have been cool and state of the art ~10 years ago but it's time to let them R.I.P. 

Dropped support for old targets in javac will hopefully have the nice side effect to reducing the private patched jars many projects has in their scms. (Please stop including activation.jar with your app!)

Not to mention that it will help moving to newer JVMs - yes, I'm looking for the moment noone will ask me to compile my projects to target 1.5 as it would be just impossible. The answer would be awesome - javac don't support it anymore!

Sometimes I even wish to see something like "one plus FIVE back" for the JVM itself - aka Java 9 stop loading bytecode from pre-1.4 times. This would lead  to huge cleanup in resources used by applications by making people look forward as now it's impossible to have a coherent support for even 2 application with the same set of libraries as each of them has stalled some dependency in the very distant past to the state it becomes impossible to collaborate. And NO, shipping private copies is not OK - search for the jakarta-httpclient CVEs which would not be fixed as it is EOLed and no further releases will happen(rightfully as it has been EOLed for years already!) but many applications expose their users by shipping a private copy most of the time not even knowing.

Even if this has been standing in my mind for quite some time I never expressed it in non-private conversation and reading that there is a hope made me start the week with some joy :).

Eclipse and gtk-doc

If you are a Linux developer you already are aware of the beauty that some devel packages provide - their gtk-doc generated documentation. Or maybe you have been using it's online variant (e.g. cairo manual). Or you might have used Devhelp to search and read the documentation coming from your locally installed devel packages.

Now if you are using Eclipse for your development the very same documentation is integrated into Eclipse Help Center together with all the other documentations available there, you can read it there. 

Or you might want to have it opened side-by-side while coding.

Pick your style and enjoy! Hopefully this brings the documentation closer to more developers. We all know how hard it is for everyone to read documentation so the easier to read it the better for everyone :).

It is already available from Linux Tools nightly update site and will be part of our 1.0 release in June.

P.S. This was written by Jeff Johnston almost entirely, I just had the privilege to do the final touches and announce it.

The awesomeness of Eclipse Development Process

The Hudson proposal to move to Eclipse started a big discussion about the Eclipse Development Process, IPLog/IP team and etc. A lot of people are complaining about the amount of work they have to do but having done few Eclipse Linux Tools releases I don't find this work that much, probably it hasn't costed me more than a day with non technical issues.
Now I plan to explain why is to so awesome to follow this process and respect it (note that I'm a Linux distro guy so I'm heavy biased):

• every single bit is properly licensed - One can not imagine how many times we(Fedora) have reported/asked upstreams to at least put some license to their work! And this is a blocker for inclusion in the distribution and we have spend a lot of time patching out such bits and dealing with the consequenses of these actions. +1 for the Eclipse process here

• incompatible licenses are not used/shipped together - One might think that this is just to make lawyers happy but this is only half the truth. It is also about respecting authors wish - if I choose to license my work under BSD I want people to use my work whenever they found it possible but if I choose to license under GPLv3 my primary goal would definetely not be the same and I would care most for people giving back. Most probably library developers would not gonna sue you for using incompatible licenses but this is pure DISRESPECT TO THEIR WORK. I can name a huge number of Java projects that don't even understand that. +1 for the Eclipse process too

•  reduce duplication (side effect) - One of the recent reviews of the IP team made one project remove code that was already done in one of its dependencies. Most probably just to not bother with getting it IP clean. I don't know what would readers think but this is pure technical win!

• remove unneded dependencies (side effect) - Same review as the previous point - a number of unneeded dependencies were removed just to not bother with getting it IP clean (if possible at all - read the first point). And the build was failing without these deps despite them being unused/unneded. Another pure technical win thanks to the IP team!

There are a lot of other benefits that can be mentioned but just the first two are making us - Java packagers(I'm sure I speak for at least few others) want every Java project to go through similar process. This would make packaging Java software a lot easier, a lot more acceptable and not that allien on Linux systems.

Kudos to Eclipse's IP Team 

Everyone actively working on some Java project - think whether you want your software to be included/shipped to a lot of users. You may achieve that yourself but having a team helping you in this is definetely helpfull.

P.S. Links and people/project names are intentionally not used to prevent someone getting it personal. :)