The direct result of this change is that I’d have to switch to Netbeans or IntelliJIDEA to work with the code base which although not really nice would have been acceptable but there’s another problem with all this.

The e(fx)clipse code started to make use of JDK8 APIs and because we are subclassing JDK8/OpenJFX8 classes (e.g. collections) we got compile errors in our workspace, the same is true for our maven-tycho build.

The Java8 support is developed in an extra branch of JDT-Core and you can find informations about it on the wiki how to selfhost it. This would have allowed me to work around the development problem but I don’t think this is an acceptable solution for the months to come (until Kepler SR2!) so I’ve set up my custom CBI build where instead of building with JDT-Core from master I’m switching to the BETA_JAVA8 branch – you can find my shell script here.

For those who don’t want to run the CBI stuff their own I’ve also published complete SDKs (Platform+JDT+PDE) which I’ll update from time to time – if you know a certain fix went into the repo you can ping me e.g. on twitter (@tomsontom) to start a build.

Please note: The JDT stuff is very young code so don’t immediately file bugs when things don’t work. Consult the wiki on the status of the feature. Don’t spam the JDT-Team with bugs on stuff they have not yet developed!

On the left you see how the SWT one works and on the right handside how the JavaFX one is structured. The cool thing is that all the complex logic with lazy activation, … is implemented in an toolkit agonostic way and abstracted throught W*-Interfaces (git-repo).

Here’s an example of the WWindow abstraction we are using:

public interface WWindow<N> extends WWidget<MWindow> {
	
  public void setMainMenu(WLayoutedWidget<MMenu> menuWidget);
  public void setTopTrim(WLayoutedWidget<MTrimBar> trimBar);
  // ... left, right, bottom

  public void addChild(WLayoutedWidget<MWindowElement> widget);
  public void addChild(int idx, WLayoutedWidget<MWindowElement> widget);
  public void removeChild(WLayoutedWidget<MWindowElement> widget); 
	
  public void show();
  public void close();
}

That’s the whole interface you need to implement. Back to EclipseCon so showed off this concept and on the last day I was approach by a guy who immediately recognized that this renderering can be used to renderer with other UI-Toolkits like FX as well.

He’s been interested in a Swing one! He asked me for an estimate how much time it would take to get such a thing going and I answered: “Not more than a week”. He could not believe that is doable so had to proof it to some extend!

All the conversation happened before the start of a talk and I have to confess I don’t know anything about what the talk was about because I started hacking right on a Swing renderer, and before the 35 minutes talk had been finished I could show him this little app.

The most of the time it took to implement the bootstrapping of the OSGi-Application (25 minutes) implementing the SwingWindowWidget was a simple task. If you happen to be in need of a e4 on Swing-Renderer I’d suggest you take a look at the prototype I hacked together in 30 minutes.

I’ve pushed the code to an extra repository for now (it is not part of the e(fx)clipse code base donation to Eclipse.org).

We (BestSolution.at) currently have no plan to develop any Swing-Renderers but if you are interested in doing so or want to hire us to do it for you just get in touch with me because 99% of the code builds the foundation for our JavaFX renderer story (where we provide commercial support) a swing implementation automatically inherits all improvements and bugfixes we are implementing.

Before someone asks: Yes I know about Kai’s prototype doing something similar but he approaches the problem in a different way. In our case being able to implement Swing renderers is only a (nice) side effect of our rendering design concept which makes it super easy for you to implement custom JavaFX renderers (e.g. writing SWT-Renderers with our engine would/will never work!)

• Monday, March 25th
  • 1pm – 4pm: Tutorial: Advanced Eclipse 4 Application Platform – not for the weak-hearted – Sopot and myself are doing a deep dive into e4, from the DI-Engine to different renderering strategies like vaadin and JavaFX
  • 7pm – 8pm: BoF: Jump start at JavaFX and Eclipse 4 – I’m moderating this BoF where we can discuss the possibilities e4 on JavaFX provides and for those interested we can take a look what is already possible and how you can leverage it
  • 7pm – 9pm: BoF: Raspberry Pi and Eclipse Hackathon – JavaFX and Raspberry Pi are good friends – unfortunately the 2 BoFs are at the same time – I hope to crash the party in the 2nd half
• Wednesday, March 27th
  • 1:30pm – 2:05pm: Talk: EMF.Edit: the Force Unleashed! – Mikael Barbero will make use of e(fx)clipse EMF-Edit integration
  • 5pm – 6pm: Talk: An Orion Symposium – How to utilize Orion in the Community – I’ll show of how to combine WebView from JavaFX and Orions editor to get up a mini IDE
• Thursday, March 28
  • 10:15am – 10:50am: Xtended JavaFX – Sven and myself will demonstrate how Xtend can be leveraged to write JavaFX applications
  • 11:45am – 12:20pm: Modern UIs with JavaFX, OSGi, and e4 and the tooling provided by e(fx)clipse – I’ll show the latest enhancements in tooling and runtime space – e.g. I’ll show a prototype of a (Java)IDE built with e4, JavaFX

Hope to see you in Boston.

All in one downloads

Updated to the latest and greatest up-stream projects (Eclipse 4.2.2/3.8.2, WTP 3.4.2, egit 2.3.1). The WTP-Update holds fixes for the FXML-Editor we’ve developed with the Upstream project committers and the Eclipse 4.2.2 Platform fixes many of the performance problems people have been having.

Tooling

Kepler Support

The tooling now installs into Kepler M5 and there we make use of new API we’ve developed with the PDE-Team. We are not yet providing All-In-One downloads and we are not testing the tooling in Kepler but this is going to one of the main targets for the next iteration (0.9.0).

Java8-Support

Since JDK8 b75 JavaFX is on the extension classpath which e(fx)clipse now detects appropriately in plain Java-Projects and PDE-Projects. The only problem as of now is dealing with the JavaDoc which will be solved with Kepler M6 where JDT-Launching will provide us new API to contribute JavaDoc and Source Locations for entries of the JRE-Container. We’ve not yet decided whether we can backport this support to Juno and how we could do it.

CSS-Editor

The CSS-Editor is not context sensitive and if it e.g. detects that you are editing the styles of a BorderPane it only shows the styles applicable for it.

I’ve blogged in more detail already.

@FXML

To help you detecting errornous @FXML annotations in your controller methods we’ve made the ECJ a bit smarter delivering a warning if the arguments in @FXML annotated methods is not of type javafx.event.Event.

Runtime

Java8

At runtime we now support Java8 b75 and above where JavaFX is on the extension classpath and starting with this we are now also compatible with ScenicView so that you can inspect your applications from the outside with it.

e4 support

Animations

Since some time we already support animations for perspective switching. Starting with this release we also support animations for window show/hide. You can see both of them in action in a demo applications I’m currently working on.

View Toolbar/Menu-Support

We’ve added support for View Toolbar and View Menus like you know them from e4 on SWT

StyledTextArea

If you are reading my blog you know that I’ve been working a lot on getting a StyledTextArea up and running for JavaFX while the widget itself is not yet included into the build and downloads it’s been one of my major working areas in this iteration and I think what we’ve already achieved in this short timeframe is amazing.

Development Target Platform

To make it as simple as possible to develop JavaFX-OSGi-Application we are now building a complete target platform for you including bits from eclipse.org and efxclipse-runtime bundles. Simply point your target platform and tycho build to http://downloads.efxclipse.org/p2-repos/dev/releases/latest/ and you are done.

Bugfixes

We’ve made a lot of bugfixes like unrendering of perspectives and many many more small things.

With basic syntax highlighting you can already achieve a good results because you can highlight things like keywords, String-Literals, … . Still if you are used to e.g. the JDT sourcecode editor you know it e.g. highlights fields – this is called semantic highlighting and because it involves some time to run the compiler to find out semantic informations this is done in the background.

So I started and ported more parts of the Eclipse-Text and JDT-Infrastructure

Highlighting is nice but a more important feature is auto-complete and so I ported more and more of the JDT-UI infrastructure and the result in shown in the video below which shows a prototype of an IDE I’m working on for my EclipseCon talk.

the internal code is a bit ugly and I’m using some brute force stuff to simply get it going, naturally there are missing features like selection, … . Next is to port more stuff from Eclipse-Text-Infrastructure and integrate with JDT once more.

The sourcecode is found at e(fx)clipse github repo

I’ve worked a bit on it last night and take a look at this result:

The really cool thing is that the API of my StyledTextArea is fairly the same than the one from SWT-StyledText (in fact also many of the inner workings are a shameless copy from SWT!) this will make it super easy to use and adjust the current text parsing infrastructure used by the Eclipse IDE.

public class StyledTextArea extends Control {
  public void setContent(StyledTextContent content) {
    // ...
  }

  public StyledTextContent getContent() {
    // ...
  }

  public ObjectProperty<StyledTextContent> contentProperty() {
    // ...
  }

  public void setStyleRange(StyleRange range) {
    // ...
  }

  public void setStyleRanges(int start, int length, int[] ranges, StyleRange[] styles) {
    // ...
  }

  public void setStyleRanges(int[] ranges, StyleRange[] styles) {
    // ...
  }

  public void setStyleRanges(StyleRange[] ranges) {
    // ...
  }

  public void replaceStyleRanges(int start, int length, StyleRange[] ranges) {
    // ...
  }

  public StyleRange[] getStyleRanges(int start, int length, boolean includeRanges) {
    // ...
  }
}

Ok. This was the easy part, next is to somehow add editing functionality, I have no freaking idea on how to do it.

Here are some screenshots:

I’ve recorded a small video so that you can see it in action:

The scrolling performance is great but you’ll notice that the initial rendering of big files (> 10.000 lines) takes some time. So while this is Ok for a prototype time has to be spend on the performance for a real world app (I also hope there are optimization possibilities in JavaFX itself), adding editing needs logic to only modify parts of the TextFlow model but I hope I can find some time to give it a try.

What Richard is telling us is that they release their (prototype?) code for iOS/Android, not more not less. This means the community has to put a lot of effort to turn this into something one can use to write and package iOS and Android applications – at least this is how I read Richards announcement.

Having the prototype code makes it easier to start because we can see how Oracle approached this but one has to have a lot of knowledge about the inners of the JavaFX’ Glass and Prism code, OpenGL-ES and iOS/Android. Gaining this knowledge will take time and is probably not something one can do on evenings / weekends.

Another uncertainty is “JavaSE Embedded for iOS/Android”. What is it? Does it provide us AOT compilation? In case it does not this is one more thing to be solved by the community so that at least performance critical parts of your application can be AOT compiled. There are solutions to this like Avian or xmlvm but one has to make things work. There is a reason Codenameone provides this as a cloud service for their platform!

The last thing to consider is that only having JavaFX on the system is not really enough. You need to interface with platform services and sensors without them you can’t write useful applications, so we’d need a cross-platform API for this to develop useful apps.

To round up this short post. Yes it’s good news but still leaves me with many questions/doubts.

JavaFX provides many many CSS-Attributes (many more than HTML) but only very view apply for a given CSS-selector. Because of that we made the CSS-Editor context aware which means it restricts the provided CSS-Attributes based upon the selector you are currently in.

This screenshot shows the unrestricted set of CSS-Attributes because the CSS-Selector “.test” is a generic one.

This screenshot shows hover-Informations for element definitions (used for almost all Scene-Graph-Elements beside Controls)

In this screenshot you’ll notice that the list of proposed attributes is way smaller compared to the first screenshot. Nice!

From this screenshot you can see that the editor knows that the .button class is applied to Button-Elements.

And naturally the set of attributes is restricted as well in this case.

I think this feature once more puts e(fx)clipse a head of other IDEs.