OT: Netbeans ported to JFX?

Doug Schaefer dschaefer at qnx.com
Thu Jul 10 14:34:52 UTC 2014

I think from the Eclipse side, it probably makes more sense to start using FXCanvas more. I've already started that with editors that use the WebView.

I'll throw my hat into the ring of rewriting the IDEs from scratch would be very difficult to do where we are today. Back when we used to make a lot of money selling IDEs, yeah. But now we need to take a more evolutionary approach as much as I know IDEs would benefit from JavaFX today.


From: openjfx-dev [openjfx-dev-bounces at openjdk.java.net] on behalf of Tom Schindl [tom.schindl at bestsolution.at]
Sent: Thursday, July 10, 2014 4:07 AM
To: openjfx-dev at openjdk.java.net
Subject: Re: OT: Netbeans ported to JFX?


I've thrown Eclipse at it [1] - performance is ok but certainly not
better than pure SWT but the reason for that is maybe my custom SWT port.

What you see is not a rewrite of Eclipse code itself (which is 99%
unmodified) but an alternate SWT implementation which has the big
draw-back that some part of the IDE (and I assume the same is true for
some parts of Netbeans) are written with a direct mode toolkit in mind.

For modulare application frameworks I currently know of:
* e(fx)clipse - which leverages the Eclipse4 Platform
* eFX - which leverages the Netbeans Platform
* JacpFX - IIRC built solely above OSGi Felix
* jrebirth

IMHO doing a simple rewrite is not the right way - start with one of the
platforms (Eclipse/Netbeans/IntelliJ) and rethink the IDE. What I mean
is: Doing a rewrite simply for the sake of rewriting is wasted time and
in case of rewriting Netbeans/Eclipse/IntelliJ/... it's a huge huge huge
waste of time.



On 10.07.14 09:06, Robert Krüger wrote:
> On Wed, Jul 9, 2014 at 4:14 PM, Jeff Martin <jeff at reportmill.com> wrote:
>> My thought is that JavaFX is perfect for an IDE targeted to education, like Greenfoot and BlueJ:
>>         SnapCode: SnapCode is the first and only pure JavaFX IDE
>>         YouTube Overview: SnapCode JavaFX Overview
>> SnapCode has visual code editing ("Snap-coding"), a sprite kit, graphics/sound editing, a runtime browser/player with animated transitions and more. It also has most of the features you expect in a modern IDE. Hopefully this is a great way to attract a new generation of developers and bring JavaFX to all Java developers.
>> What it doesn't have is very much in the way of resources. If anyone wants to help, let me know. If Oracle would like to kick in an engineer or a few dollars, I wouldn't turn that away either.
>> We need something like a "JavaFX Playground" before Apple Swift-boat's us. :-)
> I have to say I passionately disagree here. Of course, everyone has
> different requirements/expectations. I am currently looking at JavaFX
> as a candidate technology for commercial products in a market where
> people are used to native applications. So far, I think JavaFX, from a
> developer point of view, is great and the dedication of the dev team
> and the transparency of the dev process are outstanding but it still
> suffers from maturity problems that usually go away after a lot of
> serious applications have been thrown at it, not by another Ensemble
> or educational tool. Even big finance or medical or system management
> applications may not be a good enough test for some areas because
> their users are typically more forgiving in certain areas than e.g. a
> photographer or designer using their favourite photo organisation tool
> on a Mac but of course, every application helps and Netbeans is so
> huge that porting it would probably result in a number of new Jira
> issues making the platform better and, as I wrote, I thought with the
> Swing API no longer being developed, it would either have to die or be
> ported anyway.
> BTW, is there any directory of (commercial) JFX applications anyone is aware of?

More information about the openjfx-dev mailing list