Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Java IDEs comparison


> Another example is e(fx)clipse. It's a very interesting project, but one
> wonders if they could have gotten even further ahead if Eclipse has made
> their life easier. You see, there is a lot of "JFace" code that is
> actually UI-independent, stuff like jface.text IRule, IPredicate and
> document partition management code, or certain preference utilities -
> however, all such code is in plugins that indirectly depend on SWT (!)
> Even though their core functionality does not depend on anything UI. So
> e(fx)clipse can't use it. (Or they can, but have to bundle SWT and bloat
> their program footprint, or otherwise have other issues).

Most of JFace-Text is already moved to eclipse.text so it is platform
neutral there's an open bug report with a proposal to move even more and
Dani agreed that I can move that parts [0].

In the meanwhile I've forked those useable bits [1] in an own bundle who
is part of e(fx)clipse. BTW did you know that one can use all this
without OSGi? We pushed older releases to maven-central [2] and do that
if someone request that for current releases, the whole editor framework
we developed at e(fx)clipse is:

* split in a core framework eg to get content-assist data, annotations,
  ... (built upon Eclipse-Text)

* presentation API for JavaFX (& SWT which was just a quick proof of

* can run in/outside OSGi [3]

There are already commercial IDEs built on top of this platform BTW and
they look soooo slick!

And we (e(fx)clipse team) have big plans for e4. On our list is:
- make OSGi and optional layer

- support Java9 module as an alternate module system
  => The main driver for this are
     - Customers demand that they can use ANY IDE
     - Customers don't need to repackage all their other stuff for OSGi
       useage (although they'll get bitten by Java9-mods even more!)

The first and most important part to make this possible is already in
our current releases. A replacement for the OSGi-Service-Registry when
running in pure Java [4].

It's on our current plan to get this working in Java9-modules as well
but we didn't yet had the time.

The changes to e4 are deep and I'm afraid we can't get around without
breaking APIs which means most likely we - e(fx)clipse - are going to
fork the e4 platform.



Thomas Schindl, CTO EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Back to the top