With some of my workspaces I want to have a similar IDE as with others, but some IDEs require special plug-ins. A while ago, as I still unzipped Eclipse-downloads, this was a huge pain. Every time I wanted to work in a specific workspace I had to remember which IDE I used for what, then find the workspace location on the disk, before I could do anything.

Permanent workspaces

Now I double-click a .yoxos file on my Desktop, then start working. Related .yoxos files hang out together on different areas on my desktop. This is possible with the Yoxos 5 Launcher which I explained in my last blog post.

I associate the workspace I want to start in terms of “upper right” or “vaguely in the middle, left” on the screen. No need to remember long directory names.
Remember, a .yoxos file is a definition of both the workspace and the IDE that works on the workspace. The actual workspace is somewhere in my home directory. Since every .yoxos file defines a separate IDE, I always click “Use this as default” after defining the first time where the workspace is located.

Temporary workspaces

Throwaway workspaces go to /tmp. Along with everything else in /tmp, they will be deleted the next time I reboot. The .yoxos file that defines a throwaway workspace should be deleted with it, so this belongs to /tmp as well. The IDE definition works this way:

• Start the Yoxos Launcher
• Add “Project SDK” and all the other desired plug-ins
• Save the .yoxos file to “/tmp/throwaway-workspace” (a new empty directory)
• Hit “Launch”

With the bundle pool I don’t worry about the plug-ins that compose the throwaway IDE. Only rarely something new gets downloaded anyway.

.yoxos files and workspaces

A special handling of .yoxos files in otherwise empty directories supports this workflow. If a .yoxos file is is started while residing in an empty directory, the IDE uses this directory as workspace. This provides an easy answer to the question about the “where”, and I use this feature at a regular basis.

On Mac OS X, I can append the extension “.yoxosws” to a directory that contains a .yoxos file. This defines a workspace that I can start directly with a double-click, without bothering about opening a folder to access the .yoxos file.

Conclusion

The Yoxos 5 Launcher makes it simple to handle a multitude of workspaces. The best thing is that you can stop wondering about the IDE contents and start thinking about workspaces. The Launcher provides a consistent UI to define new IDEs, including a huge number of 3rd-party plug-ins that are not shipped with the default Eclipse downloads.

But the number of useful plug-ins increased, and many are not included in the downloads from eclipse.org. Developers use different plug-ins in different workspace. For some developers, this leads to as many Eclipse installations as workspaces. Others capitulated and just don’t use many plug-ins even though they see their value; but managing the installations is just too hard. Others again have one huge installation that includes about everything for all the workspaces, and they too have pain with plug-in dependencies. They all suffer from plug-in dependencies.

Imagine you had a system where each plug-in you use is downloaded just once and reused whenever you need it for a new Eclipse IDE.

Yoxos 5 provides that.

Imagine you could just start your workspace and your IDE starts up including all plug-ins you want to work with in that workspace. If it is a new workspace you’d have automatically adjusted predefined settings, import projects etc.

Yoxos 5 excels at that.

Yoxos 5 unifies the workspace settings and its IDE description in a Yoxos Profile. A Yoxos Profile can be defined in a .yoxos file. The Yoxos Launcher creates Yoxos Profiles and starts them, for example when double-clicking the .yoxos file. Plug-ins are downloaded to the bundle pool and started only if the profile includes them.

Yoxos 5 is now in beta phase. You can try it out now:

• Download and install the Yoxos Launcher
• Download and start one of the sample profiles (further down at the download page)

Get more information at http://eclipsesource.com/yoxos5

1. My computer has 2 cores (there will be more in the future).
2. My IDE feels sluggier with every version.

Applications feel fast if the time between user action and application reaction is short. Ben Galbraith suggests that this threshold is around 200 ms for web applications, for desktop applications the boundary is lower. A rule of thumb places it around 100 ms, so I there must be a yellow range in between.

My IDE crosses this threshold more often than it should, so it’s sluggish. What’s the reason and what can be done about it?

It seems like a fundamental law in software engineering that every new version of any program executes more code than the previous version.

Java 5 introduced the java.util.concurrent API that made corse grained parallelism easier. The combination of thread pools, Futures and Barriers covered a wide range of tasks between CPU and I/O bound.

To me as UI programmer this had little consequence. For a while I could still state that Java+SWT is fast, consuming my part of that lunch that is not free any more but was cheap enough anyway in the doses I required.

This is changing. A few years ago we saw a pain barrier reached and solved in startup time of various operating systems. Today my pain barrier is reached in many of the functions that are executed as reaction to user clicks and key presses in my IDE. Undoubtedly it is only a matter of time when this will apply to smaller desktop applications, too. They must react, and using multiple cores is the solution at hand.

Other languages and frameworks already have good support for multicore programming, Java 7 will include the ForkJoin framework for Java. In the wild, it is a library known as jsr166y that can also be used with Java 6.

In the following I’ll discuss a little example that shows how to use the ForkJoin framework.

A simple easily parallelizable example is assigning random values in a large array. It’s also an example that can not be solved with raw processor power but accesses memory.

First, care must be taken where the random number comes from. Even a sequential solution using ForkJoins ThreadLocalRandom was about twice as fast than one with Math.random(). It’s also more comfortable to use.

    int[] result = new int[ARR_SIZE];
    for( int i = 0; i < result.length; i++ ) {
      result[i] = ThreadLocalRandom.current().nextInt( result.length );
    }

ForkJoin provides a class named ForkJoinPool as executor service for tasks. The constructor can be configured with the parallelism (number of threads) to be used. The default constructor takes the number of available processors as returned by Runtime.availableProcessors(). The pool is then given tasks for execution.

    ForkJoinPool pool = new ForkJoinPool();
    pool.invoke( new ArrayGenerator( result, 0, result.length ) );

The ArrayGenerator is a RecursiveAction. The RecursiveAction differs from the RecursiveTask mainly in the return value of the compute() method. It’s implementation is a straightforward recursive algorithm. First, there is an exit condition that solves the remaining problem sequentially. If that is not hit yet, the remaining problem is divided for two other RecursiveActions. Those are given to invokeAll, which blocks execution in this task until all subtasks are executed. In my experiments, the definition of the exit condition didn’t matter as long as all cores where busy at least once.

public class ArrayGenerator extends RecursiveAction {
 
  private int[] nums;
  private final int start, end;
 
  public ArrayGenerator( int[] nums, int start, int end ) {
    this.nums = nums;
    this.start = start;
    this.end = end;
  }
 
  @Override
  protected void compute() {
    if( arrayIsSmallEnough() ) {
      assignSequential();
    } else {
      int middle = start + (end - start)/2;
      ArrayGenerator left = new ArrayGenerator(nums, start, middle);
      ArrayGenerator right = new ArrayGenerator(nums, middle, end);
      invokeAll( left, right );
    }
  }
 ...
}

On my machine with 2 cores I achieved a speedup of 1.24 over the sequential solution. While that’s not as good as I hoped it still is a significant improvement that has the chance to move my clicks back down into the green area. I suspect that more cores could achieve a better speedup, so there is free lunch again once I design my program for concurrent execution.

Programming with this framework seems easy enough to me to see it adopted widely. However, we must rethink our problems and search for chances to parallelize.
I implemented the same thing with ThreadPoolExecutors and Futures. While the execution time did not differ there, it took me 3 times as long to implement it.

The concept of Import-Package is quite appealing. In today’s world, Java itself doesn’t have a concept for modules so we depend on OSGi for modularity. Actual dependencies on the Java side are specified on the class and package level. So it feels more natural to specify what you need via Import-Package instead of where you want something from via Require-Bundle.

As an experienced Eclipse developer dealing with many large projects… I’ve lost some enthusiasm for Import-Package. All those different bundles and their dependencies are difficult enough to grasp for newcomers. Require-Bundle has better tooling support in Eclipse and less complexity in general… so I recommend to use Require-Bundle unless someone needs the improved flexibility of Import-Package.

What’s the reason for my attitude?

Recently I spent some time with a single-sourcing a RAP/RCP project. Having different target platforms for the same bundles is a perfect example where you need the flexibility of Import-Package. Flexibility is good, right? So I went ahead and declared all dependencies as Import-Package.

Now imagine you have declared an Import-Package to the org.eclipse.ui bundle, being sure that org.eclipse.ui is exported in your target.

Everything is fine, right? So far so good in the typical Eclipse RCP case.

However, it’s not so fine if you try it with RAP although you’ll find that bundle org.eclipse.rap.ui.workbench exports the org.eclipse.ui package.

So the situation is:

my.bundle imports org.eclipse.ui
org.eclipse.rap.ui.workbench exports org.eclipse.ui

However, your bundle just won’t be resolved due to a missing Import-Package constraint on org.eclipse.ui.

The diagnostics in Equinox don’t help much either… it just tells you exactly the above imports and exports. I don’t know if there are better tools out there to diagnose issues.

The reason for this behavior is a concept in Java called split packages. It allows the same package to be declared across several bundles… giving each split a special name. So it’s something like a sub-package concept for packages. Although it is discouraged in the OSGi specification… it is used by the Eclipse workbench and other areas where there has been a lot of refactoring and Require-Bundle usage.

The correct import declaration in my.bundle would be

Import-Package: org.eclipse.ui; ui.workbench="split"

Why does it work in the RCP target case?

It wouldn’t if your target platform contains RCP only. However, most RCP applications have the bundle org.eclipse.ui.ide in their target platform which exports another split of the org.eclipse.ui package. OSGi only resolves split packages if at least two exported split packages can be found.

Knowing this… I now can safely use Import-Package for my single-sourced applications. However, I don’t see a way how I possibly could recommend this to students in my training courses or new people to OSGi in general. I’d need to tell them “Look, Require-Bundle is something that has been used in Eclipse for awhile, mostly for legacy reasons. We don’t recommend its use any more. Import-Package is better if you want looser coupling between bundles. However, be aware of the pain split packages can cause.”

I guess my gripe is that split packages make things complicated and we need better tooling to support them.

How are other people handling split packages in the wild?

With the Jobs framework the Eclipse IDE provides some means for long running operations. The Jobs framework is able to run tasks in a parallel fashion and queue the rest, while providing user feedback with progress monitors. Other RCP applications have different needs when doing long running operations.

Specifically the Job frameworks UI feedback is not always what an RCP application wants. Sometimes I find that I’d rather prevent the user from clicking in the UI than queue more jobs. This happens for example if the user action triggers a network access that might take a while. There is no point in accepting the same user action again. So I want to provide a nice feedback mechanism to the user that their click is being processed.

Eclipse provides a progress monitor dialog. It’s a modal dialog that shows a process to the user and prevents her from clicking in the workbench. Personally, I don’t think it’s very appealing. Also, it’s not what I want… while I want some view being blocked often other views should stay operable.

I don’t know anything that means my use case from Eclipse so I created a few classes myself that take care of a presentable way to block workbench parts. Basically it’s a transparent shell that lays itself over a given control and displays a SWT ProgressIndicator widget. It responds to the controls re-size, move and disposal events… and looks quite neat! Way better than the progress modal dialog, and it leaves it up to the programmer which part of the UI should be blocked.

From the programmers point of view, I took the approach we find in Eclipse all the time: The programmer has to implement some “I..Runner” interface that is custom to my API.
It contains a run method that takes an IProgressMonitor and is called outside the UI thread.
My aim was to make the different steps during and after the long running operation as clear as possible to the programmer and reduce their need for inner classes. Unlike the Eclipse API I don’t think that it’s the users responsibility to sync back into the UI thread. This use case is common and creates unnecessary bloat in the source code. Therefore I provide 2 methods that are called within the UI thread after the operation is done, one for doing the actual feedback for the user and one for exception handling (if necessary).

public interface IResponsiveRunner {

/**
* called from without the UI Thread
*/
public abstract void runOutsideUIThread( final IProgressMonitor monitor ) throws Exception;

/**
* called after {@link #runOutsideUIThread(IProgressMonitor)} from within the UI Thread
*/
public abstract void uiFeedbackAfterRun();

/**
* Called within the UI thread. This method is called if an error occurs during execute before
* {@link #uiFeedbackAfterRun()} is called.
* @param caught
*/
public abstract void handleException( final Exception caught );
}

This is what a programmer has to implement. Starting the nifty progress report is very similar to using a progress monitor dialog, instantiate and run:

new NiftyProgress( myResponsiveRunner, new TransparentUIBlocker( control ) ).run();

The TransparentUIBlocker is the class that does the actual blocking. It’s passed in under a generic IUIBlocker interface that might have other implementations.

So, as a programmer, you provide an implementation of the IResponsiveRunner and point to a control that should be blocked, and you’re done. Nifty feedback to the user.

I attached a zip with plug-in projects with the classes and a small application that makes use of them. Use it, it’s EPL.

Oh, and if someone can tell me how to get notified if a view is hidden behind another one in a view stack, please do.

And if you then get an error that even Google knows only 2 pages of useless results about, you start scratching your head. At least I did after I got this one:

java.lang.UnsatisfiedLinkError: no swt-pi-gtk-3346 or swt-pi-gtk in swt.library.path, java.library.path or the jar file

It gets a bit more mysterious when you start looking for the swt-pi-gtk libraries, locate them in one of the SWT fragments, and you make sure that all your “-os” “-ws” and “-arch” options are set correctly.

To make the long story short, the solution was to install GTK on the new server…

One example I liked is the question whether a program is a virus or not. As a proof, you could reduce the halting problem to this problem, but it is far better illustrated by giving a self-referencing program (the formal proof then would be based on diagonalization):

Let P be the program that decides whether A is a virus. Then you could define your virus A as:

if P(A) then exit;
else infect();

Great, isn’t it? The virus knows the virus-detector P and doesn’t behave as a virus if P can identify it as a virus. If not, it’s evil. q.e.d.

That’s the theory. Let’s have a practical look at it.

First of all, it seems that the virus author is a pretty bad program designer – we usually try to avoid circular dependencies. But, being pragmatic I’m willing to compromise where it is necessary and in this case I must (unless I want to reduce the halting problem).

What seems more awkward to me is that the virus depends on P to being a behavioral analysis. Antivirus programs actually do behavioural analysis to detect viruses. And although I can’t find a link of proof between all the antivirus ads in Google I remember at least one headline where a root kit detected antivirus software and clouded itself against it.
But Antivirus programs also do statical analysis. In statical analysis the code isn’t run but only looked at. And any P that does statical analysis would find infect() (hopefully, if the heuristics work) and thus mark the self-clouding virus as virus anyway.

Of course this does not invalidate the proof that I hinted to above. I really like it as example for decidability. It works if you define “virus” as a program with malicious behaviour.
It’s sad that in practice we can’t always restrict our environment as we need it – unless we just write a “Hello World”.