e(fx)clipse is an Eclipse.org project that provides JavaFX capabilities for the Eclipse IDE, so that people can easily develop JavaFX applications inside their favorite IDE.
To make the development process as smooth as possible, it provides the following:
Additionally, e(fx)clipse also provides runtime components to develop OSGi enabled JavaFX applications, including otherwise missing features when using JavaFX in an OSGi environment.
Besides providing single components to develop pure OSGi applications, it also provides a complete framework implementation on top of the core Eclipse 4 technologies (modelled application and DI container), allowing people to develop RCP applications with any level of complexity.
In Java 7, JavaFX is part of the default JDK/JRE install, but surprisingly it is not found on any of the default classpaths, so e(fx)clipse comes with a helper ClasspathLibrary that fixes this problem. In Java 8, JavaFX is within the extension classpath, but because the source code is not part of the ordinary JDK src.zip, stepping through the JavaFX source code using JDT would not be possible for the developer while debugging. e(fx)clipse works around this limitation, and so developers can step through JavaFX code while debugging and are shown JavaFX related JavaDoc when hovering over JavaFX APIs in their Java editor.
CSS is a very important technology for people developing JavaFX applications, because all the theming is done through CSS-Stylesheets. JavaFX’ CSS-Attributes are quite different from the known HTML CSS-Attributes, instead it comes with a huge set of custom properties, some working similar to their web counterparts, others completely custom.
e(fx)clipse provides a very smart CSS-Editor that knows exactly, what attribute can be applied to which element definition. It is even clever enough to detect the used JavaFX version and shows different proposals based upon the targeted runtime.
Next to Java and CSS, the 3rd important technology used by JavaFX developers is FXML. FXML is a declarative language to define JavaFX UIs. While Oracle provides a WYSIWYG tool called SceneBuilder, many developers still prefer to the define their UIs by directly editing the FXML-File.
e(fx)clipse’s specialized FXML-Editor supports Java editor like features like auto completion, javadoc hovers, quick fixes and much more.
FXGraph is a custom DSL provided only by e(fx)clipse, that removes much of the noise when using FXML to define UIs. Its syntax looks similar to JSON and “compiles” FXML so that no additional runtime libraries are needed.
More information on FXGraph can be found in the e(fx)clipse wiki: http://wiki.eclipse.org/Efxclipse/Tooling/FXGraph.
Although not backed by an Oracle JVM, JavaFX applications can run on Android (Davlik) and iOS (AOT with RoboVM) devices. e(fx)clipse provides a preview mode for mobile resolutions and a small runtime framework that provides basic transition effects between screens.
Another important issue when running on resource constrained devices, ie. with less powerful CPUs, is that the overhead of constructing UIs from FXML is too big. Because of that, e(fx)clipse provides a FXML to Java “compiler” (or better converter), that runs at build time.
JavaFX comes with a default set of layout containers, but people switching from SWT to JavaFX are probably used to the layout containers used in SWT. e(fx)clipse provides layout panels that use the same layout algorithms as known from the SWT world.
EMF itself has support to populate structured SWT controls like Lists, Tables, Trees and TreeTables with EMF objects. e(fx)clipse provides EMF edit hooks that can be used by JavaFX controls like ListView, TableView and TreeView. JavaFX8 added a TreeTableView that is supported as well.
JavaFX does not work out of the box in OSGi. On Java 7, it was not found on any classpath and even though it is on the extension classpath in Java 8, it is not part of an EE. So Equinox will not wire JavaFX packages by default. e(fx)clipse provides an Equinox Adapter Hook, that integrates JavaFX into OSGi, so that developers don’t have to worry about this issue, too.
The Eclipse 4 framework was designed to be widget agnostic since day one. e(fx)clipse comes with a full implementation of the widget specific parts of the Eclipse 4 framework. So people can easily implement JavaFX applications of any complexity on top of the core Eclipse 4 concepts, like modelled applications, dependency injection and OSGi.
Back to the top