Most Java applications don't look the same as C/C++ applications. Swing might have been designed on purpose to have a distincitve look, but based on what I've read, SWT for example tried to 'look native', and doesn't completley succeed.

My question is:

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?

  • 32
    because swing writes its own gui components that try to mimic the native, instead of creating a binding to the actual native components, in the idea of portability Feb 3, 2014 at 11:58
  • 5
    I am not an expert on this topic, but I guess it is just a matter of how much effort GUI toolkit vendors are willing to invest to get all the gory details right. See, for example, the C++ framwork "Qt" and this SO question: stackoverflow.com/questions/7298441/…
    – Doc Brown
    Feb 3, 2014 at 12:01
  • 4
    There are many many details to take care of. For example the way auto-completition works in a file open dialog is one point where a native looking java application broke down. Feb 3, 2014 at 12:27
  • 4
    Swing has a "native lookalike" look-and-feel that you can plug in instead of the default. Also, Java first tried to use available native stuff with AWT but it didn't work very well, AFAIK because of the inherent differences between platforms. That's why they created Swing, so that a Java app works exactly the same everywhere.
    – marczellm
    Feb 3, 2014 at 12:58
  • 5
    Don't overlook JavaFX. It's the SWING replacement and is in the JDK/JRE by default starting with Java 8. It is much more modern than SWING and AWT and looks a lot more native on just about all platforms (it hooks a lot into the native UI toolkit on each platform). With that said, as others have mentioned, to get an exactly native looking application out of a "one-size-fits-all" language like Java, you will have to do some work. Java's UI's was/were/still-are intended to be a "best fit for all platforms" out-of-the-box.
    – SnakeDoc
    Feb 3, 2014 at 21:30

9 Answers 9


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.) And 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 - and 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 toolkit. You specifically mention SWT not looking native, which is a bit odd, because SWT is native. It's a toolkit 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.

  • 1
    Thanks. What does 'light-weight' mean exactly? And what does 'native' actually mean? I assume it means something that uses resources from the OS of the computer or interacts with it directly. Is this true? Feb 3, 2014 at 12:22
  • 1
    @user3150201 Sure, so the underlying OS will have a set amount of buttons and widgets that can be placed natively, but obviously these buttons will differ between OS and between platforms - these are the heavyweight, native components. Lightweight components aren't the components dictated by the OS, they're drawn by Java (in this case) to look and behave like GUI components - so they can look however you want if you put the work in (but you have to emulate the platform look and feel if you want that, you don't get it for free.)
    – berry120
    Feb 3, 2014 at 12:27
  • 14
    Placement of buttons, exact sizes, and preferred GUI styles vary by platform and getting Java to mimic them takes work. Swing can give you the native button but if it's 10 pixels to tall the user will still think something is off. Apple has the Human Interface Guidelines and Microsoft has the User Interface Guidelines to help you get the correct native look. You will need to change UI somewhat between platforms. Feb 3, 2014 at 15:47
  • 4
    JavaFX appears much more "native" than SWING and AWT. It has native transparent windows, etc. Much more modern looking out-of-the-box.
    – SnakeDoc
    Feb 3, 2014 at 21:27
  • 2
    @SnakeDoc It appears more modern, sure, but I wouldn't say it appears "native" - it certainly doesn't use the platform's underlying GUI components, it's all skinned in CSS.
    – berry120
    Feb 3, 2014 at 21:54

There are literally half a dozen of toolkits that could be considered “native” on some system. Some of these have rather unique concepts or capabilities, and replicating them in a cross-platform toolkit is tedious. The look & 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 re-write 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 over system-specific toolkits. 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.

  • 1
    +1. Only one thing I’d like to add: What about things the system allows the user to configure, starting from “simple” details such as how to open context menus? (And I’d much prefer windows programs to have ribbons and Mac apps not to, thank you. Yes, good GUIs need to be designed per OS.) Feb 4, 2014 at 4:51
  • @ChristopherCreutzig That's where my experience comes from: On my main desktop, I use KDE on Linux (both of which are very configurable themselves), and use QtCurve to adjust the look of applications. These special styles work just fine in the flagship KDE applications. Well-written GTK apps can make use of a compatibility layer, but background gradients are missing, the menu bar stays inside the window etc.. But then it quickly starts to deteriorate, with programs taking some widgets from the system style (like scrollbars), but ignoring others (like font rendering, or shadows around menus)
    – amon
    Feb 4, 2014 at 9:52
  • +1 because there are some strong points in this answer, but there are some weak points, too. Any "how does this window manager draw X" issue is handled by using the native API. For example, X11 on OS X can draw native OS X windows, buttons, scroll bars, dialogs, etc. So a lot of those issues disappear. The real answer is what @TheSpooniest said below: UX is so much more than just drawing widgets. Spacing, timing, animation, mouse acceleration, touch inputs... there's a world of subtle details that are very expensive to reproduce with a cross-platform toolkit. Aug 19, 2014 at 14:53

Yes, it does go deeper.

Building a button which looks like a Windows or OS X button is easy, when you are building only this button. But the button must "behave" like the original ones, which might not be easy: maybe there is more space in one version available, but not in the other, maybe the color is more fitting for your design in the Windows version, etc.

This is excarberated when you have a whole GUI: an OS X program presents its content differently than a Windows program. This is next to impossible to capture in one GUI - you would need two GUIs, but not many applications make so much fuss. Instead they are aiming for "looks ok on most systems" - this still looks somewhat alien, but is usable and much easier to develop.


It's not hard to make a button that looks like an OSX button, or a Windows button, or that of any other toolkit. 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 so 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 toolkits 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.


There is a trade-off between expecting your application to look as natural as possible on every system and expecting your application to work in the same way on each system. There is no "right" choice.

Moreover, even if you choose the "natural looking" side, you might want to protect the users of your graphic toolkit against "improvements" in the underlying native components and API which might break their application unexpectedly.

This is why some GUI toolkit developers prefer to provide their own components that mimic native ones, but provide their own implementation. On the other hand developing a functionally complete GUI toolkit is a significant effort and economic considerations may lead to cutting a few edges.

Note that this problem is not Java specific, but is faced by every company producing platform independent toolkits.

  • Rather than silently downvoting you'd do a greater service to the community by explaining what you feel is wrong with an answer. Unless it's just a personal issue... Feb 4, 2014 at 8:34

It’s all due to history.

Sun wished all Java software to work the same on all machines.

For software to “appear native” it has to work the same as other software on the given OS.

Sun did everything in their power to make it hard to write Java software that integrated in with an OS, as any integration with an OS would make the software work differently on each OS.

These days very few Java programmers care about anything other than web server based software.

Sun killed Java on the desktop by shafting all programmers that used the Microsoft java based systems, hence making any programmer that choose Java in the early days look bad.

Anyone writing desktop software that care about “appear native” learned a long time ago not to use Java and has their views reinforced every time they use any Oracle software.

Therefore these days there is no demand for “appear native” on desktop software from Java programmers.

  • 5
    "Sun did everything in their power to make it hard to write java software that integrated in with an OS, " wrong. They simply put no great effort into making it easy. "Sun killed Java on the desktop by shafting all programmers that used the Microsoft java based systems" wrong, the mutual enmity between Microsoft and Sun caused Microsoft to create a version of the AWT libraries that wasn't compatible with Sun's requirements, causing the infamous Sun/MS lawsuits.
    – jwenting
    Feb 4, 2014 at 9:09
  • 1
    @jwenting, Sun cared more about making problems for Microsoft then about programmers that had chosen to use Microsoft's java based system. Hence I gave up on Jave and kept with MFC until C# come out.
    – Ian
    Feb 4, 2014 at 9:31
  • 3
    maybe some people at Sun, but that sentiment was mutual. If you're developing exclusively for a single platform, a native tool for that platform is ALWAYS the prefered option, this has nothing to do with corporate politics. If you choose your tools based on "I hate Sun" or "I hate Microsoft" that reflects very poorly on your professional attitude. I've mostly used Java, but alongside that I've also used Delphi, C#, Ruby, C++, C, Progress, whatever was the best for the job at hand. And more often than not that will end up being a hybrid solution.
    – jwenting
    Feb 4, 2014 at 13:02

What you think is native is actually native apps doing their own thing while toolkits like SWT follow the published standards for the UI of that OS. The problem is that no one builds apps following those standards so when you fire up a Java app. It appears to not be native. As an example, almost all of Microsoft's projects (Office, Outlook, etc.) cannot be reproduced visually using Windows standard controls.

It's going to get even worse as both Microsoft and Apple add dynamic UI features to their OS platforms. Allowing developers to skin/style their apps much the same way web designs create styles for websites.

Java on the Android platform is following this path. Making the UI elements for Android defined in XML with skinnable styles.

Java has never been very popular as a desktop platform. As a result these changes in the industry are not propagating down to the desktop runtimes. There just aren't enough developers willing to spend time to fix the issue.

  • 1
    +1, back in the Windows 95 era there was a 'standard' look for Windows controls. Now, not so much. Feb 3, 2014 at 15:54
  • Yeah, its been a few years since I've programmed desktop but I was surprised that .NET didn't ship with a ribbon style control despite it becoming integral to the MS built productivity software.
    – Rig
    Feb 3, 2014 at 16:27
  • @Rig Since NET 4.0 there is a good native Ribbon Control in .NET. Here is a good article: c-sharpcorner.com/UploadFile/0b73e1/ribbon-control-in-wpf-4-5 Feb 3, 2014 at 18:15
  • 1
    @Rig You'll need .NET 4.5, not .NET 4. Visual Studio 2010 can only target up to 4; you'll need VS2012 or newer to target 4.5. I can see it when targeting 4.5 in VS2013, but not when I change the target version to 4.
    – Bob
    Feb 4, 2014 at 0:15
  • 1
    @Rig It is possible to use the Ribbon in Net 4.0 - you can download it from Microsoft and then it will show up: 10rem.net/blog/2010/10/22/wpf-ribbon-october-release (Not sure if this is the latest version). Better download it from Nuget. I had to do that for a program which had to run on Windows XP - works fine and is mostly compatible with the Net 4.5 variant, so you can rip out the 4.0 thing when XP finally retires. Feb 4, 2014 at 7:27

Which operating system do you want to look "native" too?

You just can't be native to all of them 100% of the time.

SWT etc. are the best effort approach to look as native to all of them as it gets when you need to reach some compromise.

And in fact, this compromise starts to become more and more hard to reach; not so much because of operating systems, but because of input devices. For touchscreens, you actually have to design differently, because there is no right mouse button. Therefore, you need to accomodate the same functionality otherwise.

There will never be a magic button that moves functionality "intuitively" from the right mouse button to guestures, without you specifiying every detailed aspect for every single input device (at which point, you are native to every platform you have considered, but nevertheless non-native to any you have not considered).


Really good question. I always wondered about it myself for a few subsequent years in the past, I thought there was some legit reason behind this, but there really isn't.

I think the answer is rather simple, and a lot of answers are not really digging into the issue.

If your language allows to draw piexel on screen then it is 100% possible to create a gui framework based on it which will mimic Windows form controls looks & feel precisely.

Since Java is crossplatform its also entirely possible to make sure that based on actual running system type (Mac/Windows) UI would choose to look different on both platforms, matching the runtime platform style.

As you can see in XAML for example UI can be easily presented in very structured form and language. Choosing the "native" behaviours is also possible if time is taken to do this.

So it would be possible to create GUI framework which would allow Java developers to get applications which would look native on Mac and Windows.

So we get to Swing, thats just one GUI framework out of potential infinity of GUI frameworks which could be created for Java. It behaves how it was programmed, which doesn't follow the above process and you get weirdly looking apps on both systems. Thats the choice made by Swing developers, noone forced them to do this and to behave that way.

  • 2
    this does not answer the question, asker already covered this point: "Swing might have been designed on purpose to have a distinctive look"
    – gnat
    Feb 3, 2014 at 21:07
  • I disagree, but thanks for commenting your minus(?) Feb 3, 2014 at 21:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.