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 :).

What can we(Eclipse community) learn from Libre Office?

Before reading further please watch "LibreOffice cleaning and re factoring a giant code base" from this year's FOSDEM conference. Note that reading this post without watching the video would put a lot of things out of context!

The one and single most obvious thing for me from the whole talk was "it's about the people". Watching it one will notice the amount of people that started contributing in there free time and how fast LibreOffice grows in number of contributors. As one that works almost entirely with Eclipse.org projects (especially Eclipse as an IDE) this made me ask a very basic question:

How did a pure end-user application managed to attract more developers to spend improving it in their free time than an IDE ?

 

I started to think about initial experience I had trying to improve various plugins and realized that we do fail entirely in welcoming new committers. Even after one has number of patches in, if one just opens a bug(gerrit review) and attaches his/her patch - nothing happens for months (even years!). Or the patch will comments why it can't happen now and nothing will happen for months/years again. Now I'll try to fight some of the most common myths used to explain the situation:

• there is release pressing - this is seen for milestones, SR releases, etc. But there is always something pending and most of the time people start with so small contributions that they can hardly affect the whole release train. Potential contributors might be more happy if instead of saying it can't happen now and forget it, we do comment a week later once the M-build is out (this covers most of the calendar year) and work with the contributor to get his change in.
• it gains us nothing - wrong! for at least two reasons: First: one of your users identified the need for it and cared to spend time to contribute it back, one could bet that he/she see it as important; Second: even if there will be no technical benefit immediately - that's one more contributor and this makes difference soon after that.
• old versions depend on something that this patch changes - You know there is a reason for calling a version an old one. Don't hold the new development - we have the awesomeness of git - branching, cherry-picking and so on can hardly be easier. Old way of doing something belongs to maintenance branches. Here we come to catch 22 - there are not enough people to support two ways but we don't want new contributors too. New people need new things.
• this part of the code is "tabu" - only blessed ones can touch it. Telling a potential contributor - "you're not smart enough" isn't it ? Well, I read it differently - if in my code there is something so sensible that I should be afraid is someone touches - it needs a fix (or ever rewrite?) as soon as possible so it can continue improving as normal part of the codebase. As long as someone starts spending his time on it of course.
• it's not tested with other version of third party library - this is seen really often from my point so it's like a personal rant. If someone requests a dependency range to be bigger one can think that he tried it or that even a product using the version outside of the range is shipped. And this means nothing as the project can continue ship its preferred version but you can make the life of people depending on your code easier for no cost.
• the contributor already ships a fork so he/she can continue do that - If one ships a fork and submits patches back it clearly means he doesn't want to do that but he is forced to do that because the project is not interested to grow in the area he needs.

If we want to grow as community members, everyone has to go through his projects bugzilla/gerrit see for pending patches or requests and make the easiest one come in the next release. Or we will soon get to the point where people will not even report bugs as they would not believe anyone will look at the bug opened and that would be a failure growing to disaster. Seeing even well respected people withing the community having to poke numbers of time for really simple patches to be applied makes me very sad as this is pure energy lost. One can fix few more bugs instead of rebasing patch 3 times and poking 5 times.

It's not too late for a change we need to just encourage people by accepting their changes or work with them till the change is in a good enough change. Just a bit more openness and trust to new contributors is needed. So do we actually want to grow the community?

SWT on GTK 3 - Eclipse starts !!

So another major milestone is hit. One can start eclipse on top of GTK 3.x - not everything works as expected but here is the screenshot.

SWT on GTK 3 can be shown !!!

If we keep the pace I might get used to blogging more often.
A picture is worth a thousand words so here it is:

Not much to see but it's the first ever screenshot of SWT on GTK3. Not much more can be done for now and the label was supposed to be centered (source) but still we are finally at the stage where we can start showing things.
Big thanks goes to Silenio who bite the bullet to disable/workaround things so we can start running the code instead of targetting perfection with the compiler.

SWT on GTK 3 status 2012-10-23

That was amazing week - 29 compile errors were fixed! On the other side my metric is broken - I have been counting only errors in os.c while there are a bunch of others hiding in os_structs.c too. Anyway, at least for what we were counting there are 31 more errors left and they are a prerequisite for even trying to build os_structs so we continue working on them.
So what was fixed last week:
* 2 gdk_colormap_* functions are dynamic now as they are removed in Gtk 3
* 3 drawable/pixmap functions are no longer used in Gtk 3 codepaths
* 14 errors - GdkRegion/cairo_region swap landed in
* 9 gtk_style_get_*_gc  are ignored - used only in the unfinished Theme api
* gtk_widget_size_request - time will tell whether this was the correct call.

Additionally a number of other fixes for the structs landed too but I do not keep track of numbers there as I compile them in my blind_convert branch so the numbers are flawed by the dummy fixes done for unfinished things in os.c.
And now the good news - one can successfully compile my branch in question and try to run an empty shell example - nothing will show but it would not crash either, which was the state for long time preventing me from making this branch public. Don't count to much on this branch  - it's known to be broken and serves only as a test bed before things go into master.

SWT on GTK 3 status 2012-10-16

Another week - 15 down!  60 more problems expect us before trying to run on top of GTK 3.
The problems fixed this week are:
* 5 gtk-paint* functions  replaced by the new gtk-render* functions
* GdkDragContext, GtkSelectionData and GtkTargetPair structs are no longer used directly but via accessor methods
* GdkGCValues, GdkImage and GdkVisual structs sizeof is no longer needed
* gtk_cell_renderer_get_size replaced by gtk_cell_renderer_get_preferred_size

Let's see what will next week bring us!

SWT on GTK 3 status 2012-10-09

SWT doesn't run on top of GTK 3 (latest and greatest ) but work is ongoing. Last week was a really productive one getting us to the state of less than a hundred compile errors (well, some are warnings actually). Not only that but we are down to 75 as of today. A number of others are pending reviews in bugzilla giving us hope that speed should not decrease.

Here is the list of all the GTK problems we have identified for now. Be fast and pick one (check the tracker bug first), open a bug and block the tracker so we know someone is working on the issue. There is still time to add your name to Thanks list. If you want to help out checkout swt from git and  when building natives instead of the plain `sh ./build.sh` do `GTK_VERSION=3.0 sh ./build.sh` the list of errors is what's still pending. Nothing else but code counts as help for now! There should be semi-regular updates on the state from now on.

Big thanks to SWT project members for making me a committer to speed up the work and to my teammate Anatoly Spektor for his hard work on the topic in the last months.