Eclipse Tooling for JavaFX Project
The most important missing feature is a CSS-Editor who understands the CSS-Extension used by JavaFX 2.0.
Earlier this week, Tom Schindl blogged about the
first release of a new project that provides Eclipse Tooling
for JavaFX projects, ‘e(fx)clipse.’ JAXenter spoke to Tom Schindl
about what niche he’s aiming to fill with e(fx)clipse, and what the
future might hold for this new project.
JAXenter: You recently announced a new project:
e(fx)clipse. Can you give us an introduction to e(fx)clipse?
Tom Schindl: Before talking a bit about
e(fx)clipse I think it is important to understand how e(fx)clipse
came into existence. Some people might know that I’m part of the
Eclipse 4 development team which is working on the next generation
of the Eclipse SDK.
At first I didn’t start with what I later called e(fx)clipse but with the target to teach myself
how I can create a DSL using the Xtext 2.0
framework released as part of Eclipse Indigo, and was searching for
a medium complex problem with a practical relevance.
At the same time I was working on a proof of concept to make the
Eclipse 4 Application Platform using JavaFX as a UI-Library instead
of SWT, and so I had to edit JavaFX specific
CSS-Files and missed an editor for the vendor extensions. It was a
fortunate coincidence because now I had a practical use case for
teaching myself a DSL.
I think this bit of history is important when proceeding to talk
about e(fx)clipse and what the future holds for it, because there’s
currently no commercial, or whatever, hidden agenda.
I naturally welcome if a company thinks that a free and open
source Eclipse Tooling for JavaFX 2.0 is needed to make it a
success – leaving a big community like the one using Eclipse is
probably not ideal! – but I don’t have problems proceeding with it
in my spare time because it provides enough technical fun that I’ll
Anyways, what do I think e(fx)clipse is, and what could it
e(fx)clipse’s main target is to provide tooling to author JavaFX
2.0 applications using the Eclipse IDE, so that developers
currently using Eclipse as their primary IDE do not have to switch
to e.g. NetBeans to get tooling support when they want to develop
applications using this new UI-Toolkit.
Because JavaFX 2.0 applications can be authored with a mixture
of Java (or any other JVM-Language) and CSS, and Eclipse provides
excellent Java-Tooling out of the box, the most important missing
feature is a CSS-Editor who understands the CSS-Extension used by
Another interesting fact is that I don’t want e(fx)clipse to
stop on the tooling front but also provide a runtime framework
which supports developers writing medium to big modular JavaFX
The idea is to leverage the runtime platform used by Eclipse 4.1
named “Eclipse 4 Application Platform” to provide such a runtime
layer. I’ve already shown in proof of concept implementations that
the runtime platform used by Eclipse 4.1 can be used by none SWT-UI
applications, so technically it is possible.
JAXenter: Can you give us some potential use
cases for an Eclipse Tooling for JavaFX?
Tom: The target audience of the tooling part
are naturally all developers who use Eclipse today to develop all
kinds of Java-Applications (e.g. WTP, Virgo-Tooling, …) and don’t
want to switch to another IDE to author their JavaFX-UIs, which
would contradict the idea of an IDE a bit.
The target audience of the runtime framework are developers who
want to write modular JavaFX applications using a modern software
architecture including OSGi, Dependency Injection and central
application model. As far as I know there’s no such framework
available as of now, and it simply makes sense to leverage this
solid application framework outside the Eclipse SDK project,
instead of reinventing and reintegrating those technologies.
JAXenter: What functionality is already
available in the 0.0.1 release?
Tom: The only real feature the 0.0.1 release
provides is an CSS-Editor which currently provides, besides the
default CSS 2.1 attributes, those defined by JavaFX. There is some
preliminary support for attribute values but it’s not really
sophisticated as of now.
JAXenter: What’s the next step for the
Tom: From a feature point of view:
0.0.2: Will bring better attribute value proposal support
0.0.3: Will bring validation support, improved outline view
0.0.4: Will focus on e(fx)clipse runtime on top of the “Eclipse
4 Application Platform” (the current biggest problem here is JavaFX
itself because it is not designed with strong modularity, as
defined by OSGi, in mind)
Out of scope for now is e.g. a WYSIWYG-Editor, which could be
built in theory on top of WindowBuilder. It would require a big
investment because – at least I – would have to make myself
familiar with the WindowBuilder codebase.
Another interesting idea would be to develop a DSL using Xtext
to author JavaFX applications, together with the XBase and Xtend2
introduced with Xtext 2.0, this could lead to slick DSL integrated
tightly into Eclipse and Java.
From a project organization point of view:
I currently plan to move the Core CSS-Editor codebase to the e4
project because Eclipse 4.x application developers currently face
the same problem JavaFX devs do in Eclipse: They’ll have to author
CSS-Files with vendor specific extensions but have no tooling.
Because I’m currently the one responsible for the Eclipse 4.x
Tooling it makes sense to move the core over to Eclipse.org and
proceed with the development of the core there.
The e(fx)clipse code will be developed outside Eclipse.org on my
personal github repository.