Since Jonathan is traveling for Devoxx he allowed me to act as a guest editor this week for JavaFX links of the week post. My short introduction is at the bottom of this post. Lately I have been working on one of my personal projects in JavaFX so I am a regular follower of this blog. Everyday I have to head towards JavaFx forum or stackoverflowfor my queries.
- Pedro Duque Vieira has blogged about how to create checkboxes with a metro theme using JMetro.
- Randahl Fink Isaksen described the problems he faced due to unavailibility of interface classes for JavaFx control classes and suggested a potential workarround for the same .
- NotZed blogged about Quick and Dirty image viewer using JavaFx with basics features like pan and zoom and flicking through a set of images.
- Find out how you can test JavaFX user interface in your application using JemmyFX in JemmyFX Getting Started Guide
- Andres Almiray blogged about how to change language (i18n content) in JavaFx applications on the fly without re-launching it.
- Leon Atherton gave a quick overview of the differences between Java3D and JavaFX. He mentioned how JavaFx can be used to emulate some of the Java3D features till full 3D support comes in the next versions.
- rjahn got inspiration from the JavaOne Technical Keynote and blogged about Beagleboard xm.
- JavaFX Scene Builder 1.1 Developer Preview is now available for download.
- Mark Heckler created MonologFX which is a flexible JavaFx dialoge component.
- Tom Schindl posted about how to implement an editor using Xtext and JavaFX shader language.
- Thomas Bolz posted about his mortgage calculator called Finanzierungsrechner which is created using JavFx.This is exactly what I was looking for last month to analyze my own loan statement 🙂
- Pedro Duque Vieira announced Modellus X 0.2 Release Candidate released.Modellus is a freely available software package that enables students and teachers (high school and college) to use mathematics to create or explore models interactively.
- November/December issue of Java Magazine is published and can be downloaded for free.
- Gerrit Grunwald showed JavaFx on BeagleBoard-xM during the night hacking tour streaming interview.
- NetBeans IDE 7.3 Beta 2 got released.
Neil Ghosh works for Oracle Corporation as a project leader in the Technology Initiative team. Neil graduated from University College of Engineering, Burla with Computer Science and Engnieering as major and has over 6 years of experience in ERP, Web services and Web application development. He has contributed to various financial software and mobile projects with his expertise in Oracle, Java, J2EE, jQuery, PHP and MySQL. Neil is also chair of IEEE GOLD affinity group of Hyderabad section. He is also a co-organizer of Java User groups Hyderabad. Apart from programming his interest involves astronomy and cricket and other outdoor activities.
Why is JavaFX 2 not interface-based in the first place?
My experience is that really high quality, flexible, maintainable software development STARTS with a proper interface based architecture (yes, this automatically excludes Swing and much of the JDK). You might also want to read an article containing thoughts from James Gosling on that topic (http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html).
A co-worker of mine who works with Swing and already took a deeper look into JavaFX 2 constantly complains about the both the library’s architecture not being properly interface-based, hence preventing proper use with good program structure.
So instead of just linking some blog entry complaining and showing a workaround, why not refactor the JavaFX architecture to do it properly?
Don’t tell me the people driving Java development forward still don’t fully understand how interfaces are used properly (like e.g. DirectBuffer implies).
API evolution. Interfaces practically forbid it (without cluttering up the API with Interface2, Interface3, and so on). There are places where interfaces make sense, there are places where they don’t. When you have to maintain strict compatibility across 15 years and many releases for millions of developers, you learn rather quickly that interfaces pose challenges in API evolution.
Thanks for your answer.
Nevertheless, I don’t see where types hardcoded as classes are anywhere more flexible for API evolution than interfaces are. At design time you can take a type that started as a class or abstract class and turn it into an interface with the current class reimplementing the interface. You don’t lose any flexibility, you only gain more.
Besides, there are defender methods coming up (or default extension methods or whatever they will be called in the end) which gives interfaces even more flexibility for API evolution and still don’t have any flexbility drawbacks compared to hardcoded classes.
The only real drawback of interfaces that I see are the bridge methods. But there are a lot of articles saying the JIT will optimize them away and there’s even a Talk where Brian Goetz said they could be removed altogether and that that’s just matter of resources and priorities (which is understandable). My experience is that proper interface architecture even increased performance, because a lot of flags, if-s, bad instanceof-s, map lookups, redundant logic calls and what not can be spared if the design is a little more modular in the first place.
I’m really fascinated about JavaFX and the new rich client possibilities it can potentially bring compared to the old and rusty Swing. It’s just that looking at the source code still gives the old “way too hardcoded” feeling swing gave with again all the architectural problems that comes with this.