Why Swing / JavaFX is not a platform (yet)
If a platform is a set of resources (both code and data) which can be organized to create an application, then the usefulness of a given platform is defined by the utility and consistent availability of these resources. It is my belief (and has been for 10 years now) that Swing and JavaFX could both go much further in terms of adoption if the Java platform had built-in font support.
The reason is simple: native fonts are unreliable. A given font may or may not exist and may or may not render the same image on two operating systems running your supposedly portable Java application. This inconsistent availability and appearance of fonts is the root problem which forces the use of layout managers in cases where users simply want to place components at pixel-precise locations and have them stay put (in fact, this is arguably the use case most of the time!).
It is not actually Java coding, but layout managers which have been holding desktop Java back all these years. And without fixing the root problem here, JavaFX will just inherit the same issue with the same rather predictable result. If you don’t believe me that layout managers are a problem, take a look at the JavaFXPad WebStart example. Even the people making JavaFX have a difficult time getting layout managers to make things look nice:
While it is technically true that you can embed fonts in your Java applications, I think this is a cop-out which just skirts the core issue that JavaFX is not a real and reliable platform without the consistent availability of font resources. I mean, think about this. What would Windows be like if every application had to license and embed its own fonts? How well would that work?
Now imagine what Java Web Start and JavaFX would be like if the underlying Java platform included access to reliable, pixel-accurate, pure Java fonts.