Jonathan has posted 1 posts at DZone. View Full User Profile

Why Swing / JavaFX is not a platform (yet)

05.15.2008
| 8643 views |
  • submit to reddit

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.

Published at DZone with permission of its author, Jonathan Locke.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jonathan Locke replied on Sat, 2008/05/17 - 7:19pm

Yes. That's it. What I want is for null layout to be a workable and correct option for fixed UIs.

The fact that even the newer layout managers give me a headache is a separate conversation.

 

 

Mikael Grev replied on Sun, 2008/05/18 - 2:17am in response to: Jonathan Locke

Well, then we live in very different worlds.

karthike rahul replied on Sun, 2008/05/18 - 2:43am in response to: Mikael Grev

hi, i am studing mca student. i want to j2ee books and servelets  books

as i  intrested in java platform.

how do you apply in servelet, rmi ,ejp java beans concepts pls reply in my mail

as i teach  the national seminar topics in above

so pls request the presentation or books

Jonathan Locke replied on Sun, 2008/05/18 - 3:36pm in response to: Mikael Grev

No, I would say we live in the same world with the only exception being that fixed layouts are impossible in your world.

In your world, if I were creating a fixed size Java FX advertisement I would be forced to use a layout manager and the result would look slightly different on every platform. In my world, the creative team would get precisely what they wanted and without the use of a layout manager. Everything that you do would still be possible (although I can think of better ways to implement layouts).

 

Mikael Grev replied on Sun, 2008/05/18 - 4:06pm in response to: Jonathan Locke

I guess you are English speaking and never create internationalized apps. You don't create apps that can scale to HiDPI screens or that can change the font to accomodate for those how see badly. You know that all your users have approximately the same screen size so that all dialogs and windows are statically set to your predefined sizes. What you value the most is that the GUI should look exactly the same pixel by pixel no matter what.

If that is so, the yes, a null layout manager is fine. For us that do not create apps that fall under these constraints, a good layout manager is better and I wish there was one in the JDK.

Jonathan Locke replied on Sun, 2008/05/18 - 5:08pm

No, I do all of those things. I was writing constrained layout managers under Windows before Java existed. Believe me, I understand the problem domain fully.

I just ALSO think that the Java platform should support consistent text rendering for people who want precise imaging.

As for better layout managers, I'm not sure I like the existing architecture that well. I certainly don't have time to fix this problem but I have posted a few quick thoughts on component layouts on my blog

 

Fred Swartz replied on Tue, 2008/05/20 - 4:52am in response to: Jonathan Locke

@Jonathan: You seem to inhabit a different world from most developers.   Although I understand the designer's desire for total control, it leads to so many problems as to be useless for most real purposes.  The problems with your blog suggestions on layout seem similarly idiosyncratic.

That the Java layout managers can't make either you or the rest of us happy shows there's a big problem.   Perhaps the very idea of layout manager in the traditional Java sense should be questioned, and we would be better off with something like Jacek Furmankiewicz's JavaBuilder, or ...


 

Mikael Grev replied on Tue, 2008/05/20 - 10:29am in response to: Fred Swartz

> ...and we would be better off with something like Jacek Furmankiewicz's JavaBuilder

Which is using MigLayout under the cover... :)

Jonathan Locke replied on Tue, 2008/05/20 - 4:18pm in response to: Fred Swartz

If by different, you mean wider, then I agree.

I find it interesting that on the one hand you want to question the idea of layout managers and on the other hand, I suggest a direction to look for an alternative (impractical as it may be with the current architecture swing) and you label it "idiosyncratic". There is actually a certain OO logic to the approach of avoiding setters and having components determine their own location (even if they choose to delegate this in some circumstances to something like a layout manager). The current architectural idea of components and "layout managers" in swing, at least in my mind falls short in capturing and encapsulating component location, instead making that extrinsic to this fairly arbitrary API. The trouble there is that you're stuck with just one conception of layout... which lands us where we are today...

Fred Swartz replied on Fri, 2008/05/23 - 10:50am

@Jonathan:  By "idiosyncratic" I mean that your layout proposal seemed to be designed for one particular use, and not for general layout.   Since you posted such a tiny fragment, perhaps my extrapolation of how it would scale to a realistic layout was incorrect.   Showing proposed code for an entire layout would either expose your layout's weaknesses or show my misunderstanding.

Although giving components responsibility for their own layout has a nice self-organizing feel to it, the result is an unmangeable increase in coupling.  It is this coupling complexity that is the objection to something like GroupLayout, which gives satisfactory results, but can't be easily written and modified by hand.

I'm in complete agreement with you that we should be thinking outside the Layout Manager box.   Sun has been unwilling to produce a good layout manager, and has turned to JavaFX.   Perhaps this DSL will be OK (I haven't tried it yet), or one of the YAML or XML configuration interpreters (I've tried several).    Although I didn't happen to like your last proposal, I like the idea that you're looking for something better.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.