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

Why Swing / JavaFX is not a platform (yet)

05.15.2008
| 8576 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

Mikael Grev replied on Thu, 2008/05/15 - 4:50am

For some reason the Swing engineers are not interested in solving the problem with layout managers. The sad fact is even that JavaFX will just wrap the old very limited layout managers. I thought that when they are in fact creating a new API, why not solve this and be done with it?

I had a session at JavaOne about MiG layout and got a lot of positive feedback. Adding MiG layout to the platform is climbing fast on the Top 25 Request for Enhancement list at Sun (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6530906). That RFE system is the only way we have to put preassure on Sun and they constantly tell us to "file a RFE". The problem is only that they still just choose the RFEs they like and not the RFEs people like, or so it seems.

The normal answer I get from Sun people is that "Well, it is an excellent Layout Manager, but wouldn't it be better to have it outside the JDK so that users can download it?". The problem is that only about 1% (guesimated) actually will go out on the net and find a replacement, so that argument really doesn't matter.

If users complain about Layout Managers being crap in Swing, then that is a fact. Sun might think that the commenters are at fault for thinking so but that does not change the fact that they DO think so. And developers outside Sun are not more stupid. Infact they are probably using the APIs more than Sun developers, which are creating them.

Everything (almost) developers complain about has after a while ended up being fixed and I salute Sun for this. The problem is that it takes way too long and they resist furiously until they finally understand.

If there is a problem it should be solved IMO. The only way to know what is wrong is listening to the users, and I mean actually listening. Hearing what we say and disregard it will only increase tention. 

Btw, the ugly fonts will finally be solved. Java 6u10 has native font rendering... After 7 years of complaining it finally paid off...

Fabrizio Giudici replied on Thu, 2008/05/15 - 5:05am

I believe that properly aligning those components to the font baseline works pretty well with the GroupLayout. I routinely do that with Matisse (and I have only two specific bugs: one is with sliders, the other with the use of Quaqua look and feel, but the latter could be a problem of mine). But I must admit that not everything is clear to me about this post, especially why we are talking about (native) font renderings and layouts, so maybe I'm just missing something.

Mikael Grev replied on Thu, 2008/05/15 - 6:08am in response to: Fabrizio Giudici

Without a doubt GroupLayout solves the problem when it comes to using a GUI builder to create the GUI. It is almost impossible to use by hand though.

Carl Antaki replied on Thu, 2008/05/15 - 6:35am

Karsten Lentzsch's works extremly well too and it supports DLUs.

Fabrizio Giudici replied on Thu, 2008/05/15 - 7:55am

Undoubtedly MiGLayout and FormLayout are by far a better option than GroupLayout when working by hand. Given that, it seems to me that the assertion that Java's embedded layout manager are a complete failure is a bit too strong.

Carl Antaki replied on Thu, 2008/05/15 - 8:03am

You are right Fabrizio but Sun should have payed more attention to UI guidelines when they develop GUIs. It's only in Java 6 that buttons have the same size in the Java Control Panel. Most of the Java examples up to know are poor except SwingSet 3 which seems to be good.

Fabrizio Giudici replied on Thu, 2008/05/15 - 8:11am

Carl, I "do strongly agree" with you. I think it's a fact that we all agree on. Still having things such as that combobox misaligned on the JavaFX pad is a big mistake: while in Sun there has been some injection of people with a more graphic design attitude at UIs, including details, it's still clear that this attitude is not yet pervasive.

Jose Smith replied on Thu, 2008/05/15 - 8:49am

I wouldn't say Java's layout managers are a complete failure Fabrizio, but this video sums up my thoughts :) 

http://madbean.com/anim/totallygridbag/

I use MigLayout for just about everything.  Complex panels, simple panels, cell renderers, everything.  The behavior is very predictable and it just does what I expect it to.

Fabrizio Giudici replied on Thu, 2008/05/15 - 8:56am

I think I watched that video a few time ago, it's totally clever and fun! :-)

Osvaldo Doederlein replied on Thu, 2008/05/15 - 11:59am

I hate non-native fonts, anywhere. Use of nonstandard fonts is one of the worst look&feel problems of many Swing applications. My suggestion: just dump jre/lib/fonts, even the small set of Lucida fonts that ship there serves only to make the JRE fatter and less efficient. And while we're doing that, let's also remove the JRE's font rasterizer entirely, and rely 100% on the native TrueType/OpenType rasterizer. Inferior/different rasterization traits (e.g. for subpixel antialiasing) is another LAF issue, and the performance also sucks, the native rasterizers are always better (not necessarily because they're coded better but becuse they're tightly integrated with video drivers and other gfx infrastructure). This performance disadvantage STILL puts Swing to shame in applications that depend heavily on text rendering, e.g. a maximized source code editor displaying a large file, when you scroll the file continuously, the performance is irritating even on modern CPUs/GPUs, and I blame this straight on the Java rasterizer because a similar editor in native code (or in SWT - which uses the native font system) delivers "instantaneous" output.

JeffS replied on Thu, 2008/05/15 - 12:07pm in response to: Osvaldo Doederlein

As of Java 6, where it defaults to anti-aliased fonts (finally!), I've had zero problems with fonts in Java, whether running on Windows or Linux.

 That said, it wouldn't hurt for Java to have it's own rich set of fonts (that are anti-aliased, of course).

Also, the ongoing improvement of layout managers is a good thing.  But I do quite like Matisse.  Except in rare cases, it's the way to go.  It's as easy as pie to get a great looking interface that has stuff lined up how you want them.

Jim Weaver replied on Thu, 2008/05/15 - 12:21pm

I'm posting the MiG Layout suggestion on a JavaFX development mailing list.

Mikael Grev replied on Thu, 2008/05/15 - 12:37pm in response to: Carl Antaki

Yes, Carl, it is a good layout manager. When I created MiG layout I started out by making sure I added all features that FormLayout had. I even had DLU. The problem with DLU is that people don't use it since it is another messurement to learn. Therefore I added "logical pixels". They are normal pixels that we all know and love for normal screens but they will scale with a HiDPI screen, just like DLU. This means that you actually get resulotion independent GUIs absolutely free (since Logical Pixels are the default unit in MiG layout). :)

Mikael Grev replied on Thu, 2008/05/15 - 12:38pm in response to: Jim Weaver

Thanks Jim! :)

Fabrizio Giudici replied on Thu, 2008/05/15 - 12:43pm in response to: Osvaldo Doederlein

I agree that native fonts should be preferred (BTW, I think that Kirill Grouchnikov, author of Substance L&F, did some interesting tweak integrating into Swing the SWT native font renderer), even though I wouldn't exclude the capability of having an handful of "portable" fonts installed by the platform. What puzzles me is that while Sun is going to the use of native fonts, Apple recently made just the opposite step with the latest release of Java 5, by configuring by default the Sun renderer & pipeline instead of the Quartz one (native on Mac OS X). As usual it's not clear what they will do in future, but I think that this move could anticipate a future drop of the Quartz renderer.

Osvaldo Doederlein replied on Thu, 2008/05/15 - 1:55pm

Yes, the Java fonts and renderer should be kept as a backwards compatibility option, perhaps forever. They could just be off by default, and for JavaKernel, downloaded as a last priority bundle or only at first need.

Apple's Sun/Quartz pipeline change is a different issue that we discussed before... btw, any changes in the FCS of Apple's Java6?

Dmitri Trembovetski replied on Thu, 2008/05/15 - 3:20pm in response to: Osvaldo Doederlein

> any changes in the FCS of Apple's Java6?

It's been released a couple of weeks ago. Only for Intel and 64-bit  only, unfortunately.

Osvaldo Doederlein replied on Thu, 2008/05/15 - 7:15pm in response to: Dmitri Trembovetski

[quote=tdv]

> any changes in the FCS of Apple's Java6?

It's been released a couple of weeks ago. Only for Intel and 64-bit  only, unfortunately.

[/quote]

I know, I meant - does this version use the Quartz pipeline?

Jonathan Locke replied on Thu, 2008/05/15 - 10:02pm

I'm not necessarily opposed to native font rendering (although over the long term I would expect Java font rendering to be a better way to go), but any kind of font rendering in Java should look almost exactly identical on any two platforms (which means Java must include a full suite of fonts like Windows does) and absolutely must result in precisely the same bounding box for a given piece of text.  

There are other reasons to use layout managers to be sure (for example, localization, pluggable look and feel or stretchable dialogs), but for an overwhelming number of applications, they simply are not necessary if the sizes of components can be fixed by a designer. And fixed size components are not reliably possible without fixed sized text.

Although swing has greater generality in terms of look and feel, I think many applications would be better written in a single, fixed, simple style (like the metal look and feel, only slicker). The complexity created by pluggable look and feel is really not worth it much of the time. What's more, the market for Java FX is going to be online applets more than desktop applications, and that audience is really only going to be interested in precise designs.

I would not suggest that layout managers are undesirable or that they have not improved, but they have never been a good default for the vast majority of users and particularly designers, who often have simple fixed problems and want a precise look and feel. Even with the new group layout and Matisse, I still finding layout managers pretty frustrating and sloppy and they make input from professional designers much more difficult. If there are easier options on other platforms, users will choose them.

 

 

Fred Swartz replied on Fri, 2008/05/16 - 3:07am

Unfortunately it's not an exaggeration to say that the Sun's layout managers have been a complete disaster.

There are many examples of good (non-Sun) layout managers, MIG layout being the most recent, which are simple to use and produce a very attractive result. 

GroupLayout can produce good results, but is effectively completely dependent on Matisse, which is an unattractive choice for many.

The fact that Sun's examples either look like crap or are almost impossible to refactor by hand (ie, GridBagLayout, GroupLayout), that students (and textbook authors!) can't produce a nice GUI, and that the best advice you can give someone is to use a non-Sun layout manager seems to be adequate evidence of the disaster.

Karsten Lentzsch replied on Fri, 2008/05/16 - 3:44am in response to: Mikael Grev

[quote=mgrev] [...] The problem with DLU is that people don't use it since it is another messurement to learn. [...] [/quote]

I'm surprised about that statement. In layout courses I found that the contrary is the case. Every Java developer I met could work with DLU.

Logical pixels work quite well on a single platform with a single main control font. Logical pixels suck, if you change platforms or move over to different fonts. MS provides these nasty tables for folks that move layouts over from Tahoma to Segoe UI. That's basically what you face if you deploy an app on multiple platforms - which is at the core of many Java UIs.

Mikael Grev replied on Fri, 2008/05/16 - 3:53am in response to: Karsten Lentzsch

Hello Karsten,

I am sure everybody can easily be taught how to use DLUs, they are simple to understand. The problem is to get people to use them. Not many developers actually have attended a GUI creation course, where DLUs are used. How many Java developers do you think actually create GUIs using DLUs today? 1%?

Logical Pixels are exactly the same as DLUs. It is just a factor thereof to make 1 pixel mean 1 lp on a standard screen. This means that as long as people just use the default unit (e.g. "width 100" and not "width 100px") they will get resolution independence for free.

Logical pixels even has two modes in MiG Layout. Font based and actual screen DPI based. The knowledgeable user can actually make the choise. I prefer to have it scale to the DPI of the screen since that is decoupled from the Font and more intuitive to understand.

Collin Fagan replied on Fri, 2008/05/16 - 6:27am in response to: Jonathan Locke

If someone wanted to they could use Null Layout. Then package up some free fonts (like Bitstream) with the program and force the font sizes in the Look and Feel. Given that type of environment I'm sure one can build a wonderfully designed interface for one specific set of circumstances. The problem is that users do not fit into one set of circumstances. Internationalization, accessibility for the disabled, high DPI screens, and even resizeable windows are all things that you can't use exact pixel placement to design for. We all know what people did before layout managers. They hard coded pixel locations and made windows that don't resize. So now we are left with a task that requires a balance of programming skills and design skills. Not everyone has both.

Maybe I'm wrong. There are plenty of web sites that have hard coded pixel sizes. There are plenty that are not internationalized or respond poorly to larger fonts. Why should Java be any different? Is there any platform that "gets is right" that we could learn from?

 

 

Fabrizio Giudici replied on Fri, 2008/05/16 - 6:27am in response to: Jonathan Locke

any kind of font rendering in Java should look almost exactly identical on any two platforms ...

but for an overwhelming number of applications, they simply are not necessary if the sizes of components can be fixed by a designer ...

Although swing has greater generality in terms of look and feel, I think many applications would be better written in a single, fixed, simple style (like the metal look and feel, only slicker). 

The three above statements have a logical link, so I'm quoting all of them. Well, I strongly disagree :-) You can't just ship a Swing application to Mac users if it carries "a slicker" metal look and feel. Unless you have reasons for developing your own look and feel, Mac users want Aqua. They are so picky that most of them can immediately spot even minor disturbances of the Apple's HIG, such spacing with the wrong number of pixels. This invalidates all the three above sentences: since on Mac OS X you must have the specific margins, spacings and the fonts must look like the fonts in native Mac OS X applications. Hence you can't avoid layout managers.

 Of course one could say that wants only to develop for Windows or Linux... 

 

Jakub B?aszczyk replied on Fri, 2008/05/16 - 8:21am

Have a look at SWT/JFace layout managers that Eclipse RCP uses. It is commonly admitted that Eclipse looks great. There are some ports of SWT's layout managers to Swing, especially FormLayout.

Building forms with fixed-position was something Visual Basic and Borland Delphi were based on. But up until now even MS is dropping that approach I guess.

The reason to use layout managers is not only portability, but more importantly use of custom fonts. Windows or Linux user may use a desktop theme which is based on, say, big fonts, or a disabled person might want use such fonts to ease work with his PC. Just image a font beight slightly larger than deafult buttons height! "Cancel" could not fit within a button!

 

Jonathan Locke replied on Fri, 2008/05/16 - 9:46am

You can't just ship a Swing application to Mac users if it carries "a slicker" metal look and feel.  

Totally disagree. That's what most of this RIA stuff is... custom UI LAF.

 

Fabrizio Giudici replied on Fri, 2008/05/16 - 12:53pm

Totally disagree :-) RIA - a term that should defined in context, but I think I understand what you mean - is only a part of the problem, there are also "regular" desktop applications, for instance those in the enterprise where you don't need custom look and feels - you just need to go to NetBeans and Eclipse showcases of the related RCP technologies for dozens of examples. And even when you have custom L&F, it's not implied that the whole application has the custom L&F. For instance, if you look at Adobe Lightroom for Mac OS X, it has a custom L&F in the main window, but all the dialogs are regular Aqua.

Jonathan Locke replied on Sat, 2008/05/17 - 5:39pm

So you want to make sure that there's no simple way to create a Java FX application for people who don't have any of these requirements?

Jonathan Locke replied on Sat, 2008/05/17 - 5:42pm

I never said we didn't need layout managers. I just don't think we should be forced to use them when the problem doesn't require it. Is that really so much to ask?

Mikael Grev replied on Sat, 2008/05/17 - 6:24pm in response to: Jonathan Locke

What is a Layout Manager though? Unless you go 100% with null layout and position everything by x and y in pixels you are using a Layout Manger, even if you don't call it that. One that can only position the right edge of a compoent to the container's edge is still layout manager...

What you are saying is that the layout managers you have encountered in Java is crap, right? Or?

Comment viewing options

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