It’s been a long time since the last release (end of September 2012).

I’m happy to announce that we’ve just released e(fx)clipse 0.8.0 to the public. You can download it from our server! Make sure you run your Eclipse instance we’ve Java7u7 and above, the tooling bundles will refuse to start in Java6!

From 0.1.1 to 0.8.0

I’ve presented our tooling and framework on various conferences and democamps in the last few months and when I talked to people they all thought the framework is immature simply because it has such a low version number. I think 0.8.0 reflects the real state of the project: Stable and mature but not 100% done yet.

None Functional

Infrastructure

The download bandwidth used by this projected started to affect our office’ internet connection so we’ve setup a dedicated server in at an external hosting provider. We’ve updated our trac instance so that you now get mails when you filed bugs and we’ve e.g. fixed it.

Website + Wiki

One of our early adopters (Uwe Sander from TESIS DYNAware) updated our website and started to transform so of the content to our wiki.

Tooling

Java 7 and Java 8

The minimum version needed to run the tooling is now Java7, so you need to make sure you run your Eclipse using Java7u8 but we also added support to run the tooling on Java8/JFX8. Currently Java7 is the main target environment but at least for the runtime JFX8 is a quite interesting. We’ll support Java7 for the forseeable future but clearly Java8/JFX8 is going to be the main target.

FXGraph

This versions has a first implementation of a FXGraph-FXML cycle which means one can convert an FXML file back into an FXGraph file. It’s still a bit rough (e.g. the formatting of the FXGraph-File is not as nice as it could be) but all our fxgraph samples can get translated back and forth.

More and better Wizards

One of the most important facts when developing OSGi-JavaFX projects are:

• A good project structure: I’ve blogged about my ideal project structure already some time ago.
• A automated build: Build your project on a CI-Server is one of the most important things but it’s sometimes a bit of a problem to developers to setup things up appropriately

With this release we provide a set of new wizards who solve both problems for you.

You can see this in action in an older blog post. You as a tooling user might not care about this but we’ve developed a small DSL allowing one to specify your project-set creation.

If you are a tooling developer and want to provide your users wizards to bootstrap projects I’d suggest you take a look at our stuff. It can be used without depending on other e(fx)clipse code.

Runtime

EMF and JavaFX

Another employee from TESIS DYNAware – Torsten Sommer – worked on an integration of JavaFX and EMF-Edit. You can now setup FX List, Tables and Trees from the generated EMF-Edit classes makeing is super easy to implement UIs using EMF-Frameworks like e.g. CDO or Teneo. I’ve already blogged about this some time ago here.

JavaFX & e4

We’ve fixed various bugs and added new feature like a fixed tile-layout. The coolest feature is that you can now specify how the transition for perspective to perspective is done.

Beside that we fixed some bugs (e.g. in the keybinding system) and refactored the API so that people can easier extend and provide customizations.

Logging

One of the nice things we added from an API perspective is how you can log. We don’t want to force you to any logger (not even slf) so we’ve added a minimal Logger interface to our core service library and a default logger which uses java.util.logging (not my prefered framework but available from the JDK).

The logger factory is simply an OSGi-Service you can make use of it by querying the OSGi-Service-Registry:

public class MyClass {
   private Logger logger;
   
   private Logger getLogger() {
     if( logger != null ) {
       return logger;
     }
     BundleContext ctx = FrameworkUtil.getBundle(getClass()).getBundleContext();

     ServiceReference<LoggerFactory> ref = 
       ctx.getServiceReference(LoggerFactory.class);
     logger = ctx.getService(ref).createLogger(getClass().getName());
     return logger;
   }
}

If you know me you can imagine that I’m not too happy with code like the one above and because you’ll most likely develop OSGi and DI driven applications when you use our stuff there’s an easier way.

public class MyClass {
  @Inject
  private LoggerFactory factory;

  private Logger logger;

  private Logger getLogger() {
    if( logger != null ) {
       return logger;
    }
    logger = factory.createLogger(getClass().getName());
  }
}

The runtime components have not been our sole target for the logging but we wanted use it also for our tooling code where some of the parts are using Google Guice. So if you are using OSGi and Google Guice as your DI container you can make use of a small Provider class we’ve implemented for you.

Still above code is still a bit to verbose so we’ve implemented an ObjectSupplier for Eclipse DI and a TypeListener for Guice.

So the code you’ll most likely write in future is simply:

public class MyClass {
  @Inject
  @Log
  Logger logger
}

In the e4 runtime we’ve redefined the Logger and ILoggerProvider to delegate to our log infrastructure so that all informations are logged through the same system.

Like state in the beginning the default logger we provide is based upon java.util.logging but you can simply register your custom LoggerFactory and give it an OSGi-Service ranking of 1 and magically everything will make use of it. We’ve scheduled an Log4j or SLF implementation for the next release.

Samples

For the presentations of JavaFX I did at JavaOne and EclipseCon Europe I’ve implemented some demo applications which i’ve already blogged about already.

Java8 support

To implement features we have to depend on internal API of JavaFX 2.2 which is different between JFX2.x and JFX8 but with this release we’ve isolated those areas. Starting with this release we support running on JFX8 (=Java8) and JFX2.2 (Java7) – supporting both of them is equally important but FX8 will certainly get more attention.

Upstream contribution

We are depending on other projects. In the tooling space we worked with the WTP project to fix some problems with their XML-Editor (you’ll get them once you run on 4.2.2). In the runtime space we are working with e4 and recently with the JavaFX team (we managed to get our first required API into the latest JavaFX builds) which certainly takes time but helps us to provide required features more easily.