JavaFX and the Missing Interfaces
jasper.potts at oracle.com
Thu Nov 8 05:35:29 PST 2012
This is a hard problem as interfaces have some nice properties but they have one huge problem when it comes to building a API that needs to grow over time. That is you can never add a new method to a interface without breaking backwards compatibility with every class that has implemented that interface. So if Node was a interface we could not add any new methods needed to implement 3D in FX 8 or any other new feature. The only way is to add Node2, .... NodeN interfaces which gets ugly and unmanageable very quickly. There is a partial solution in Java 8 with default methods but it only solves a limited set of problems and was not available when we designed the core JavaFX API.
So when stuck between a rock and hard place with no perfect answer we had to weigh our options make a decision and live with it. Otherwise we would be stuck for ever debating the pros and cons of these fundamental design decisions. This is one of those cases and although there are times as a app developer it has annoyed me, I still think we made the right decision. It has never prevented me from doing anything I have just had to solve my app problem in a different way.
Sent from my iPad
On Nov 5, 2012, at 6:50 PM, Randahl Fink Isaksen <randahl at rockit.dk> wrote:
> I have been struggling with a number of problems stemming from the way JavaFX is designed – specifically the lack of interfaces for many of the extension points in the class hierarchy.
> It takes some thorough explaining with code examples, so instead of just an unformatted e-mail I posted a more readable explanation of the problem on-line:
> Please read http://blog.randahl.dk/2012/11/javafx-and-missing-interfaces.html
> I hope we could have a constructive discussion on this matter on this list before I go ahead and file a Jira, so the Jira issue becomes the best possible basis for solving the design problem.
More information about the openjfx-dev