Helping users with problems - a never ending story

When I started working with Eclipse, one of my first assignments was to refine status handling (an error handling that could handle warnings and stuff like that). Early Eclipses 3.x did not have any service that would allow for status, or error reporting. This was quite problematic, as each Eclipse component had to handle problems by its own means. Usually it was either logging problems to the .log file or opening SWT Error Dialog (you may still find some bugs like 259358). This was wrong, mostly because an error dialog should be brandable.
So, status handling was introduced, and almost all UI components started using, directly or indirectly, StatusManager. Handling errors became as simple as:

StatusManager.getManager().handle();

One central place of status handling allowed for certain customization, so a little bit later a "Phone Home" functionality appeared in Rational applications (which, as you know, are Eclipse based).

The picture is hosted at IBM help pages.

Due to the specific nature of my work (Eclipse Support), I was told very often what and how should be logged, and what Eclipse could do to help users.
I quickly understood that StatusManager being a part of UI is a big mistake (and I was not first, the bug was already opened). As time flew, I was digging deeper and deeper, and it appeared that status handling should be a part of OSGi.

The bug was fixed but at that time multiple factors prevented me from doing further work in this area. Being between jobs, I have more time now, and I found that E4 simplified reporting statuses even further - the central place is now called StatusReporter, and is an injectable service. I like that part.

What worries me is the fact that StatusReporter is an E4 service - and therefore it is impossible to capture low-level errors (like those thrown inside OSGi plugins). Eclipse is not perfect, and fast changing world (new features of OSes), virtualization solutions or even backup services may break it, hence it is important to have one, consistent status handling mechanism across the whole software stack.

On the other hand, I do wonder if implementing such a solution is really a justified effort - do you, Eclipse adopters, believe that it is worth to advocate of OSGi status handling?

For those of you, who are not yet bored, I have embedded my old and poor quality screencast which presents what could be done in status handling (you may safely start from 50%).

DON'T PANIC

I am sorry I could not resist using those large, friendly letters in the title of this post.

I have recently seen a Twitter message like this:

It looks like all the rumor is started by this post on omgubuntu with a very unfortunate title. It is not java that will be removed. It is a Sun Java, a closed implementation, that can no longer be distributed by Canonical, because Oracle has sunset the "Operating System Distributor License for Java" [1].

But please do not cry - as it was further [2] explained, Sun's implementation was no longer a match for OpenJDK. I guess the situation could be summarized with those words:

The kind is dead. Long live the king!

It is actually a big thing in Java world. Oracle currently uses OpenJDK as a base for its java packages, so, who knows..., perhaps total control over java will be handled to some open source community?
We might say hello to Java in Eclipse Foundation at some time ;-). Well, that's at least what I would wish for.

Just a small note for those of you who thought about abandoning Ubuntu and installing other distributions, like Fedora - let me quote to me a couple of words from fedoraproject.org:

We try to always do the right thing, and provide only free and open source software. We will fight to protect and promote solutions that anyone can use and redistribute. 

So, go ahead, and install Fedora, but because of its security, open-source purity or lack of Unity. But not because of Sun Java, which is not there!

[1] http://jdk-distros.java.net/
[2] http://robilad.livejournal.com/90792.html

Eclipse Unity Integration now under EPL

I have finally managed to find time to create my own github account. And as I have promised, I have published my source code for accessing Ubuntu Unity Launcher. It is available here.

There is a lot of work to be done. The project itself needs to be wrapped in a plugin, some P2 support would be nice...

Anyway, 2012 is coming, it's high time for new year resolutions - I wish I manage to complete this project before the end of the 2012 year!

Debugging JNI apps with Eclipse

Sooner or later you will find a bug in your JNI. And I am very sorry for you, because debugging JNI is not a simple task.

Native libraries are not compiled to bytecode, which implies that they cannot be debugged with standard Java Platform Debugger. That means that no matter how much you try you will have to face it - you need a second, native debugger (like gdb), which has to be attached to your vm. Then you debug your java app as long as possible in Eclipse, and at some point you switch to the other debugger (which may or may not be in Eclipse).

There was some effort in the Eclipse community to workaround this problem by launching two debuggers simultaneously - you can find results here, but as Doug Shaefer says, "it's maybe 5% of what needs to be done".


I am afraid that your problem has no easy solution.


But wait... Isn't a significant part of Eclipse (namely SWT) native? How it was written? And, what's more important, how it was debugged?


To find an answer for that it is necessary to reach to the roots of Eclipse, to the document the document dated to 2001, which states:

Internally, the SWT implementation provides separate and distinct implementations in Java for each native window system.[...] This strategy greatly simplifies implementing, debugging, and maintaining SWT because it allows all interesting development to be done in Java.

The idea behind that approach is fairly simple - the JNI layer needs to be as thin as possible, and leave no space for bugs. All the platform specific logic needs to be put in java code, so you could debug your code in Eclipse Debugger to the point where native library API is involved, which means that one of the following statements is true:

• you have bug in your java code
• the native library you are using has a bug

That approach solves a lot of problems, doesn't it?


Do you think other Eclipse projects that use native code has preserved that knowledge? 
I am tempted to check - are you?.


Edit: I have found out that Apache Harmony had support for debugging JNI libraries, which was then used by Intel JNI Debugger. The bad news is that it is no longer maintained, and therefore all hope in this area is lost.

Eclipse Unity Integration - without JNA

As I have explained in my previous post, it is very easy to access native libraries when you use JNA. This approach has, however, two major drawbacks: it uses LGPL, which is allowed in Eclipse Foundation only in very border situations, and it requires almost 2MB of jars. That's a lot.

In this post I am going to show you how to write java code that manipulates Ubuntu Unity Launcher using pure JNI. I will use for that Eclipse with JDT and CDT installed.

To prepare environment, it is necessary to install all the required dev linux packages. The command that do that is:

sudo apt-get install libunity-dev

After downloading the whole package (nearly 70MB), you are ready to start coding. So, let's create a java  project, and create following class, which more or less corresponds to native methods.

  If you compare that code with the approach described in my previous post, you will notice that pointer to launcher structures has been replaced with a long type. I do not care what is stored in the C structure, so let's make a handle from it.

Now it is time to launch a terminal, go to the bin/ folder and generate a C header file. Yes, the java command that generates headers operates on class files, so it is necessary to have the java project compiled. Then we can invoke following command (you may need to adjust your class name):

javah -jni org.eclipse.ubuntu.UnityLauncher


The generated code will make most of the java developers shiver:



Since now we are C developers, it is time to use CDT and add a C/C++ nature to the java project - we will keep everything together. The conversion can be performed by selecting 'New'->'Convert to a C/C++ Project (Adds C/C++ Nature)', and then 'Shared Library', because this is what we want to create - a library that can be loaded by jvm.

Newly converted C project requires some setup - especially we need to inform compiler and linker about existing Ubuntu headers & libraries. On the screenshots below you can find my settings:

There is one more option that needs to be set - fPIC:

I do not know what it actually means, but compiler instructed me to add this if I wanted to have a library that could be shared ;).

After setting the C project, put the header file into the C source folder, and then create a new c file:



This code requires almost no explanation - we use a long variable to store a pointer to the actual structure, and do some small native operation to get char* from String. Nothing really big.

At this point it is necessary to hit the 'Build All' button. A .so library should be created in our project. The library needs to be added to java path, so we go to the project build path, and add native library:

That's almost it. We need two more things - first of all it is necessary to load the shared library into vm, so let's modify UnityLauncher



The second thing to do is to write a small SWT application - because it is impossible to modify any gtk widget without starting the gtk loop - and that task can be safely delegated to swt main loop. So our test class looks like that:



The result is expected (and nice):

We have reduced the size of the required libraries about 10 times (now it is more or less 200kb), and we are 100% EPL compliant.

There is much more work to be done - first of all the java project needs to be converted into a linux-specific plugin and hooked into jobs framework, although the latter is not a very complicated task.

I'm curious if it is possible to configure P2 in such a way that it will create an eclipse.desktop file when my plugin is installed?

I hope this long post will help somebody ;-). And I plan to release sources of my plugin as soon as I clean up the code :).

Eclipse and Unity integration

My EclipseCon proposal was rejected - I guess I have to try harder next time. But the bitter taste of disappointed was quickly eclipsed by the package FedEx delivered yesterday. It was brand new hardware from my future employer - Red Hat - and I felt really flattered.
The most funny thing was that I had been asked to specify which keyboard layout I preferred. And I got a laptop in one box, and a separate keyboard for that laptop. I had to replace it by myself :). If I had known how much hassle such innocent wish can create, I would have chosen the default layout whatever it was.
I still have about 4 weeks before my real job is commencing, so I am playing right now with all things that I think I should know. One of them is calling native code.

And nothing has me annoyed me recently more than this ugly question mark in Unity launcher.

 Quick searching revealed that there is a very easy thing to do (described f.e. here), and I can enjoy now beautiful Eclipse icon in the launcher

and in Lenses

I said that it was a very easy thing - because it actually required creating one file named "eclipse.desktop" in a specific location. I am mentioning it, because adding proper launcher to Eclipse did not appealed to me as something ambitious, so I tried force Eclipse to display progress in the launcher, in the same way as it is done on Windows or MacOs.

Unfortunately SWT does not support that yet. On the other hand, Unity Launcher API is documented quite well, so I tried to create java bindings for that using the simplest approach JNA. JNA is a very powerful library that allows you to call native libraries without writing a single line in C.

So, I have downloaded the JNA libraries, put it into a regular Java Project, and wrote following interface:


Actually the two JNA libraries take care almost about everything. You do not need to worry about f.e. data conversion.
And the actual code that shows progress bar is:

What is worth noticing is the fact that you can access every launcher if you know the name of the *.desktop file. So you can run even a java program that will test if the integration is correct. I got the following effect:

There is still a lot of work to do. I need to remove dependency on JNA - it is licensed as LGPL - and therefore not welcome very warm by Eclipse Community. Then I will try to provide system taskbar for SWT - so it would integrate with Eclipse Jobs framework! I hope to update you soon with results!

Time to say "Hello"

This is a follow up of my previous post in which I told "goodbye".

The good news is that I am not leaving Eclipse community. I am just changing my hat, from a blue one to a red one.

Linux was always fascinating me. I still remember the moment in which I have heard "This is Linux. It has six text consoles and a GUI." It was something completely new and amazing for a first-year computer-science student. And the Linux (Suse) at that time was FAST (at least in comparison to other OSes at the university).

Some part of me always wanted to explore that system much more, but I was constantly facing some obstacles. Actually it was one obstacle named, Counter Strike. And you cannot play CS in text mode (time to put some xkcd for Kim)

So now, after  my adventure with CS has ended, I will start working for Red Hat. Can you imagine that? Not one wonderful community, but two vibrant communities! Even more open source, more smart people  and more knowledge to gain!I guess you can imagine my inner geek happiness! And I am sure I will spend more time contributing to Eclipse!

Work commencement is scheduled for January 1. It is a pretty good date for making New Year's resolutions. Have you thought about yours?

Mine is rather simple - I will get you know as much as I should like*!

Cheers!