As part of e(fx)clipse we are implementing a custom CSS-Editor based upon Xtext.

We have a grammer of CSS-Specification so that we can parse CSS-Files, the interesting part though e.g. which properties are available, what values they can have is at least for JavaFX not speced in a machine useable format but as plain HTML.

There are rules in this file but they are not useable for tools so we defined our own small language to store the information in a structured format so that we can make use of them in the CSS-Editor to:

• Show documentation
• Provide attribute proposals
• Provide value proposals
• Validate attribute values

Today we’ve reached an important first milestone by showing the documentation of attributes and elements.

The language definition looks like this:

and results in the following documentation tooltips in our CSS-Xtext-Editor:

If you’d like to follow the implementation or want to take a look at the CSS-Definition-Grammer we’ve developed you can do this by cloning our git-repo and use the cssext-branch

There’ve been some requests from people to use the SVG to FXML converter outside my e(fx)clipse project. I’m happy to announce that the latest nightly builds provide a standalone version of the converter.

Useage is quite simple:

java -jar svg2fxml-0.1.0-SNAPSHOT.jar http://croczilla.com/bits_and_pieces/svg/samples/tiger/tiger.svg tiger.fxml

will produce an FXML which can be loaded into SceneBuilder:

Need to teach myself now how I can provide this as a netbeans module 😉 Any volunteers to provide an implementation and contribute it to e(fx)clipse.org?

I almost forgot that a video was recorded at this years Vienna DemoCamp.

You can find my video at http://vimeo.com/47109493 if you read this through a aggregator.

Inspired by a recent thread on e(fx)clipse user forum “Why some things don’t work out-of-the-box when using JavaFX instead of SWT”. I think its time to take a look at the current state of JavaFX 2.2 on OSGi.

The first thing we need to decide is which deployment strategy we want to use.

The 2 possibilities are:

1. Make JavaFX 2.2 a prerequisit on the target system which requires your OS-X/Windows users to install OpenJDK7u6. For Windows users there’s another option because they can install the JavaFX-Runtime seperately
2. Ship JavaFX 2.2 with your application as an OSGi-Bundle

The prerequisit deployment

A reason to follow this strategy could be for example that you want to keep your download size as small as possible. If you think this is not a problem then think about the following: If you want to ship only one application “binary” you’d have to package JavaFX 2.2 runtime (Java-Sources+Native libs) 6 times (Mac, Win32_x86, Win32_x86_64, Linux_x86, Linux_x86_64)!

Even even if you require your users to have Java7u6 installed which has the JavaFX-runtime co-installed the JavaFX binaries are not on the bootclasspath, nor are they exported by OSGi by default so your application will fail to start.

The only solution I have found and implemented so far is to Adaptor_Hooks in Equinox to dynamically locate the JavaFX-binaries.

As far as I’ve heard JDK8 will have the javafxrt.jar on the bootclasspath and so that I can be supported by OSGi-Implementations the same way they currently support the usage of swing.

Repackage JavaFX for OSGi deployment

Straight Repackageing

Since 2.0 many problems with JavaFX on OSGi have been solved and so straight repackaging the javafxrt.jar as an OSGi-Bundle should work. One can use the Eclipse wizard to repackage the jar and afterwards only has to add the Bundle-NativeCode-Code header and the native code.

Now on first sight this works but there’s one big problem with this. The code in JavaFX which is detecting the native code follows those steps:

1. Locate native code relative to javafxrt.jar if that fails
2. Locate native in the java.library.path if that fails
3. System.loadLibrary()

The problematic part in the above strategy is the 2nd one.

Let’s suppose with have repackaged JavaFX 2.2 but the user has installed Java7u5 which has JavaFX 2.1 co-bundled your java.library.path looks like this.

C:\Program Files (x86)\Java\jre6\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:/Program Files (x86)/Java/jre7/bin/client;C:/Program Files (x86)/Java/jre7/bin;....

Your application will not load the native code from your repackaged JavaFX-OSGi-Bundle (step 3.) but the native code inside your Java7u5 install which is the one from 2.1 which means your Java-Code (2.2) and Native-Code (2.1) won’t match.

Repackageing as a “deployment container bundle”

The approach here is that one repackages the javafxrt.jar and the native code as an OSGi-Bundle with a predefined name (e.g. javafx.osgi) but you don’t export any packages from it but see it only as a deployment unit. At runtime you once more use Equinox-Adaptor_Hooks but instead of locating the jar somewhere on the system you resolve your deployment container bundle and extract the DLLs and javafxrt.jar from there. If you used "Eclipse-BundleShape: dir" you only have to detect the install location because the jar is already exploded.

Summary

Although it looks like the default approach to make use of JavaFX in OSGi would work (Straight Repackageing) fails when taking a closer look and this will not change until JavaFX 3.0 (shipped with JDK8).

So currently only the only solution for me as of now is the use Adapter-Hooks which e(fx)clipse uses, promotes and provides tooling for.

I’m happy to announce release 0.1.0 of e(fx)clipse. This release fixes a lot of bugs discovered and adds new cool features.

Minimum JavaFX version

Like announced with the previous release 0.1.0 drops support for JavaFX 2.0. You need to have at least 2.1.

All in one downloads

I’ve upgrade the download packages to the latest released bits. So you now get downloads for 3.7.2, 3.8.0 and 4.2.0. Naturally all other components like EGit, Xtext got updated to latest and greatest.

New features

JavaFX runtime detection

Since JRE/JDK7u4 on Mac and 7u5 on Windows JavaFX is included into the JRE/JDK, e(fx)clipse will now detect the this and use that as the default. This sounds great news on first sight but it comes with one major drawback: No JavaDoc. e(fx)clipse will fallback to the web-url of the javadoc but if you can’t access the internet for some reason the IDE can’t assist you.

This runtime detection also works for OSGi integration which will fallback to the JRE install if no FX can’t be detected.

Packaging

Native packaging

JavaFX 2.2 comes with a new packaging options which creates a deployment package (.dmg, .msi, .rpm) which includes your application and jre.

Support for Splash-Screen

The fxbuild-Editor now allows you to specify a splash-screen image which results in the setting of SplashScreen-Image MANIFEST-Header as described here.

Support for custom MANIFEST-Attributes

You can add custom attributes to the MANIFEST-File now

For the next release I plan to revisit the build & packaging tooling and support more stuff. I’ll most likely switch to Sapphire but I’ve not yet decided.

FXML & FXGraph

SceneBuilder interoperation

SceneBuilder uses processing instructions to locate css files and the resource properties file used for translations. FXGraph now encodes its information also in this form so that FXML-Files produced by .fxgraph files can be loaded into SceneBuilder.

Another compability issue with SceneBuilder interaction is solved. SceneBuilder has a bug which makes it unable to parse all types of static attribute definitions supported and document for FXML.

<GridPane>
  <Button>
    <GridPane.columnIndex>0</GridPane.columnIndex>
  </Button>
</GridPane>

is not loaded appropriately by SceneBuilder (see bug http://javafx-jira.kenai.com/browse/DTL-5028), when writing the FXML-Generator I was a bit lazy and encoded all static properties as subelements instead of the deciding upon the type. In 0.1.0 the generator has been made smarter and now generates xml-attributes when possible.

I originally planned to provide the FXML to FXGraph converter also with this release so that there’s a full FXGraph => FXML => SceneBuilder development cycle support but had to defer this to next release.

Support for fx:root

FXML support a new type of root-element named fx:root. The FXML-Editor can now understand it and provide proposals like you used a standard element as the root.

FXGraph naturally also supports this by the addition of a new keyword “dynamic” you can prepend to your “component” definition.

FXGraph: Condensed static properties syntax

I’ve introduced a new syntax to define static properties. In FXML static calls used for layouting look like this:

<HBox>
  <Button HBox.hgrow="ALWAYS" />
</HBox>

In 0.0.14 the FXGraph code looked liked this:

In 0.1.0 one can optionally also use the static keyword:

which infers the target type by walking the parent tree until it finds the layout container of the control when the FXML-File is generated.

Includes can use static-properties

Utilities

Wizard to create e4 JavaFX application

This wizard allows you to bootstrap an e4 JavaFX application. If you execute the wizard you get a simple application like this:

SVG To FXML

The convert now supports to 2 SVG-Element types:

• polyline
• image

which allows you to import really nice looking JavaFX-Controls

Project Management, …

I’ve invest a lot of time in this release to automate the build and release process using maven-tycho. Like I already announced a few days ago on our forum we are now publishing all our artificats as nightly builds.

To make the creation of eclipse distributions a no brainer for none bash gurus like me, I’ve published a small library which can be used inside ant or java.

For those not following http://fxexperience.com/.

I’ve been interviewed by Jonathan Giles on my work on e(fx)clipse and my view on JavaFX 2 in general.