Why is it so hard to make a Java program appear native?

One solution is to rewrite the application for each system.

This Q&A is part of a weekly series of posts highlighting common questions encountered by technophiles and answered by users at Stack Exchange, a free, community-powered network of 100+ Q&A sites.

user3150201 asks:

Most Java applications don't look the same as C/C++ applications. Swing might have been designed on purpose to have a distinctive look. SWT for example tried to look native and doesn't completely succeed.

Why is it hard for the developers of the Java language to design a GUI system that copies exactly the look of native GUIs? What's different in native GUIs? Isn't it only a matter of designing buttons that look like native buttons? Or does it go deeper than that?

This question has been edited for brevity. See the full, original question here.

Doesn't try to be native

The Spooniest answers (8 votes):

It's not hard to make a button that looks like an OSX button, or a Windows button, or that of any other tool kit. But the UI guidelines for most environments are not as simple as the basics of "this is what a button looks like." There are many subtler differences, from the spacing between UI elements to the order in which certain well-known actions should appear in a list to the exact position of the preferences/options dialog in the menu system. One can automate the most common cases for very simple user interfaces, but many if not most UI tasks require a much finer touch.

SWT tried to automate this to some degree, and once again, it gets it right for simple UI tasks. But there is no one-size-fits-all solution and when UIs get more complex, the basic methods it uses begin to fall apart. It is generally possible to bring it back into line with painstaking manual UI work, but this is not something that most programmers are able or willing to do for all platforms.

Swing's approach to this was simply to eschew native tool kits whenever possible. It's not native, and it doesn't try to be: instead, it tries to create something that will look (almost) the same no matter where it is run. Rather than trying (futilely) to please everyone, it tried to please itself, and while it succeeded as far as that goes, one can question how effective the result is to the wider community of users.

Different graphics for different buttons

berry120 answers (46 votes):

Isn't it only a matter of designing buttons that look like native buttons?

Well—sort of, for buttons. But this might be harder than you imagine. These days the graphics used to represent GUI components aren't as simple as random bitmaps that are stretched (since these don't scale very well at all.) They're often vector-based graphics with a lot of corner cases programmed into them (so when the button reaches the edge of the screen it may look slightly different, for instance.) Of course, you'll need different graphics when a button is clicked. For copyright reasons, developers often can't just use these existing graphics outright, so they have to be recreated. While they do a good job for the most part, inevitably some things get missed given the huge array of graphical components out there. This is much less severe than it used to be—these days if I set the default platform look and feel in Swing, I notice very little that looks odd.

I'm saying all the above based on Swing, which is of course a lightweight, non-native GUI tool kit. You specifically mention SWT not looking native, which is a bit odd, because SWT is native. It's a tool kit that uses JNI underneath to call native components, so if something doesn't look right there, it's not going to be because of the look and feel.

Related: "How to design identical UI for a cross platform mobile app?"

This calls for a rewrite

amon answers (49 votes):

There are literally half a dozen of tool kits that could be considered native on some system. Some of these have rather unique concepts or capabilities, and replicating them in a cross-platform tool kit is tedious. The look and feel of an application is not only determined by a “skin," but also on the layout and how it behaves. Some considerations:

• In a dialog, on which side does the OK button belong – on the left or on the right? Fair enough, let's build a separate dialog for each system.
• How do we mark the default button on a screen? Color tinting, bold font, enlarging the button? Fair enough, let's put that in a stylesheet.
• On Windows, the “Ribbon” concept is rather native. How would this be translated to Mac, where the Ribbon isn't common? Fair enough, let's forget pixel-exact layout and provide a different toolbar implementation for each system.
• Is the menu bar part of the window (Windows, optionally KDE), or does it sit at the top of the screen (Mac, Unity)?Fair enough, let's write a different implementation for each system, as we've already thrown away pixel-exact layout.
• How are the fonts rendered? As crisp as possible, or smooth and antialiased? And what font should be used? Note that different fonts have different metrics, so the same paragraph rendered to the same width may have a different number of lines depending on the font.
• Is the background of a window a single color, an image, or a gradient? Let's just put that into a stylesheet as well.
• How do scrollbars look? Where are the buttons – if they have any? How wide are they, or are they only revealed when the pointer moves into a certain region?
• How do we incorporate other color schemes?
• What is expected to be draggable? Where are context menus expected?

These issues can't be solved through a simple stylesheet when they touch on the behavior or general layout of the application. The only real solution is to rewrite the application for each system (thus ignoring Java's cross-platform benefits.) The only realistic solution is to forget about pixel-exact layout and to write to a common interface which abstracts over system-specific tool kits. The solution taken by Swing is to emulate various systems, which fails spectacularly.

And then there is cross-platform consistency, the idea that your app can look exactly the same on all systems (often chosen by games, where this increases immersion). On desktop applications, this is just annoying and breaks user expectations.

Find more answers or leave your own answer at the original post. See more Q&A like this atProgrammers, a question and answer site for professional programmers interested in conceptual questions about software development. If you've got your own programming problem that requires a solution, log in to Programmers and ask a question (it's free.)