JavaFX: Where's the Application Framework?
Reading JavaOne summaries, I completely agree with this paragraph here:
What really bugged me in JavaFX presentations were that they did not give me any reason for me to get excited or interested about JavaFX. They did not show how you could build great looking enterprise applications with JavaFX, did not show components that would make your life so much easier – nor application frameworks for building larger applications without turning your code into a pile of spaghetti. But they did show a game running on multiple mobile devices, including iOS… painfully slowly.
Indeed, where's the application framework?
JavaFX ultimately has precisely the same problem as Swing: it is simply a widget toolkit, does not provide any help in terms of an application framework, and therefore does not solve the real problems of application development. Modularity on its own (i.e., JDK 8) will not solve this problem and JSR 296 is dead in the water for not providing a window system.
Terence Parr, the ANTLR guy, has tweeted today the only reasonable solution: http://www.antlr.org/wiki/display/~admin/2011/10/09/Report+of+GUI%27s+death+greatly+exaggerated
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)





Comments
Ryan De Laplante replied on Mon, 2011/10/10 - 4:18pm
Michael Remijan replied on Mon, 2011/10/10 - 4:20pm
Marko Milicevic replied on Mon, 2011/10/10 - 5:29pm
There needs to be more complex widgets. I think Oracle will be pretty good at evolving a good base set over time, and hopefully we will see something like "JideFX" at some point.
As for a framework, how about Griffon (+groovyFx)?
http://pleasingsoftware.blogspot.com/2011/08/writing-javafx-applications-with.html
Hontvári József... replied on Mon, 2011/10/10 - 5:34pm
in response to:
Ryan De Laplante
Otengi Miloskov replied on Mon, 2011/10/10 - 9:00pm
Hontvári József... replied on Tue, 2011/10/11 - 4:02am
Wai Ho replied on Tue, 2011/10/11 - 7:23am
Edvin Syse replied on Tue, 2011/10/11 - 8:53am
I've written a rather large Eclipse RCP app, later ported it to NetBeans RCP, and then realized that the framework was more in the way than a benefit, even for an IDE-like application. I'm using Pivot right now, but might as well have used JavaFX 2.0, as they are quite similar in many ways. Sure, a nice docking framework is missing from both Pivot and JavaFX 2.0, but for the most part I find I write less code doing stuff myself rather than relying on built in features in an RCP platform. Don't overestimate the need for a do-everything framework, even in a business application!
You can use OSGI or other module systems even if you don't rely on one of these RCP frameworks, or you can simply be a good programmer and make sure you modulerize your code even if you don't need to adhere to some module system scheme.
Marko Milicevic replied on Tue, 2011/10/11 - 2:33pm
@Wai Your post suggested the need for a JavaFx application framework in the context of "enterprise applications"...
For the vast majority of enterprise applications, Griffon seems to be a very nice application framework. Why do you think it's not appropriate?
Even for something like building an IDE i think Griffon could provide appropriate structure, and will likely support runtime modules in the future such as OSGI. To me the only limiting factor is the level of sophistication of available JavaFx UI widgets. That's is not ready yet, but also not a Griffon limitation.
Marko Milicevic replied on Tue, 2011/10/11 - 3:06pm
in response to:
Marko Milicevic
Btw, looks like Jide is starting to deliver JavaFx components...
http://www.jidesoft.com/blog/2011/10/04/meet-our-first-javafx-component/
Here is a Griffon presentation in the context of enterprise application frameworks.
http://www.slideshare.net/ecspike/enterprise-griffon-final
Otengi Miloskov replied on Wed, 2011/10/12 - 12:53am
in response to:
Wai Ho
Wai Ho replied on Thu, 2011/10/13 - 10:32am
Great, so I'm going to go ahead and create my new IDE for my new language on top of Griffon. OK... so I need editor APIs, first of all, for integrating with Griffon's editor support... oops... Griffon doesn't have a concept of editors. Oh well, let's go ahead and create some special kind of projects for opening up multiple files at the same time, e.g., like a Java applicaton project in Eclipse, but then for my own language... oops... Griffon doesn't have project support, while the MVC concept is nice but doesn't provide me nearly the kind of project support that the related API in NetBeans IDE gives me.
In short, Griffon is nice, especially if you like Groovy as your main programming language. But for any real robust large modular application, why would I use something that has way less features than what an RCP offers? And if I use a Swing RCP I have complete control over the look and feel and my application will look exactly as I want.
Marko Milicevic replied on Thu, 2011/10/13 - 12:43pm
in response to:
Wai Ho
Wai, it would have helped if you titled your post "Where's the IDE frameworks?" And to that i would answer, "just build Eclipse plugin".
Are you familiar with JIDE (http://www.jidesoft.com/)? Check out the demos (including theming), then combine that with Griffon. I would be shocked to find an Enterprise Application that could not be built with relative ease with that combination.
If you are really hung up on a code editor, they even have a component for that...
(http://www.jidesoft.com/products/editor.htm).
Griffon was built precisely for large modular applications. You should give a try before knocking it. And as a bonus your application will likely be a fraction of the size/complexity of an equivalent NetBeans/RPC app.
On the other hand if your problem is to create an IDE for language "X", then creating an Eclipse Plugin (or NetBeans) would be the right approach.
Ahmet E. Karahan replied on Wed, 2012/03/28 - 12:21am
in response to:
Edvin Syse
You are absolutely right. We share the same experiences.
I strongly agree with your following sentences:
1. Frameworks was more in the way than a benefit.
2. I find I write less code doing stuff myself rather than relying on built in features in an RCP.
3. You can use OSGI or other module systems even if you don't rely on one of these RCP.