Posted on Mar 16, 2009

The other day I was discussing with colleagues if Nimbus should be the default LAF(Look and Feel) for Swing application. The current default LAF is Ocean which is a spiced up theme for Metal which has been the Swing default LAF since the beginning. It feels like with a large release like Java 7 it is about time we changed the default LAF to a more sensible choice which leaves two choices Nimbus which is the new cross platform LAF and the system native LAF which will be Windows LAF on Windows and GTK LAF on Unix. Apple has already gone with the system native choice and the default LAF for Java Swing applications on Mac is Apple’s Aqua native LAF. The only reason for remaining with Ocean LAF is to maintain backwards compatibility for old Java applications which were written with static pixel based layout so will be all messed up if the size of components changes. My feeling is that sector of users should be getting pretty small now and as long as we provide a easy work around like system property file that lets a user/administrator change the default LAF back to Ocean for those few special cases then we can move forward and select a modern LAF as the default. So then it comes down to what to choose Nimbus or Native(Windows/GTK) I am torn between the two. So we decided the best idea is to ask more people, so what do you think?

What Swing Look and Feel should be the default in Java 7?

Native (ie. Windows LAF on Windows, GTK on Unix) (56%, 465 Votes)

Nimbus (40%, 330 Votes)

Stick with Ocean(Metal) (4%, 34 Votes)

Total Voters: 829

Loading ...

If you have a strong feeling one way or another then please explain in a comment below as we would love to hear. All your votes and comments will be taken into consideration when we make the final discussion.

When a user runs a piece of software, she should experience something that “fits” within her current environment. For all I know, the underachiements of Swing stems from its inability to look and feel like a normal, native application. This has gotten better over the years thankfully, though I still find myself cursing at the JFileChooser especially. Furthermore, the few successful Java desktop applications I know of (Eclipse and Azureus) use the native SWT toolkit.

I voted for the native look and feel. Not to detract from Nimbus in any way. I think there is something to be said for developers wanting an application just to look like any other application running on a given operating system. The default look and feels can make Java Swing apps stick out like a sore thumb vs other application (though granted most full serious application would explicitly choose the look and feel that they want to use.

There are still no shortage of Java critics around and sometimes it can be a bit of a back handed compliment when they do not realise an application is written in Java (due to it seemlessly blending in with the other apps).

I’ve spent the last four months working on migrating a large suite of multi-million line apps from the Windows LAF to Nimbus. We originally created some of these apps more than five years ago, so we are stuck with an awful lot of legacy code. Much of this was written before we knew the “right way” to use Swing, but I suspect that’s the case in many organizations.

GUI layout is the biggest problem with the switch to Nimbus. Because Swing components cannot paint outside their own bounds, Nimbus adds a 2-pixel gap around the outside edge of most components like JTextField. This gives them space to paint the glowing highlight when the components have focus.

This introduced much scrolling in our apps, and we had to go through many screens and remove gaps between fields because Nimbus now adds the gaps for us.

Even with all the work it took, we are pressing forward with Nimbus. I think Nimbus should be the default LAF. Companies that want the native LAF already have explicit code in their apps to activate the native LAF, so you won’t be breaking them anyway.

Hmm tough one, nobody really likes Ocean/Metal – but changing the default will immediately break backwards compatibility. There’s little support for Nimbus outside of the core components as yet (not even in SwingX) and the default increased widget sizing and differences in behaviour (nimbus chooses to ignore font sizing, margins and background colors in certain places) leads me to believe a UI really needs to be designed for Nimbus or at the beginning or very least fully tested and vetted beforehand. This cant be switched automatically and hope-for the-best.

But then I also wonder how many apps actually stick with Ocean/Metal? no serious apps I can think of, they’ll all either go system l&f, JGoodies or substance ASAP. I’d hazard native has been tested more than Nimbus (JDK7 package change will no doubts catch some out). So I’d like native but for compatibility sake you’ll probably have to stick with ocean in perpetuity..?

I’m in favor of switching to all-native. Nimbus is great, but Java really needs to start building confidence that it can be used to create professional desktop applications. While a lot of pro apps *choose* not to use native components, ironically they are often repelled by Swing simply because they think they don’t have the option. I think Java on Mac surprises a lot of people by being native, it would be nice if the other platforms (which have higher-fidelity IMHO) could receive the same treatment.

FYI I can’t redesign our apps for Nimbus as we need to be 1.5 compatible. The differences between sizing in the two l&f makes plaf layout independence practically impossible (need to design for Nimbus and/or use nimbus alternate sizing client-properties). So I can see us ever doing a similar porting effort to enable a functional Nimbus Plaf interface. Probably colors my judgement.

Nimbus, definitely. Although, here’s a more subtle idea: it should be Nimbus in the browser, and Native on the desktop. The whole concept of Native really comes from a desktop mentality, whereas Java needs to do a better job of marketing itself as a web platform. But I also think Nimbus makes Java easier, which is also something Sun needs to promote about Java. Let Native be something that sophisticated desktop developers choose to turn on and support.

I voted for Nimbus. I live in the Linux KDE world, and GTK is horrid, Nimbus fits in so much better. For the same reason I tend to use Konqueror even though a number of sites do not like it ,in preference to Firefox which being GTK based looks klunky.

The option between Nimbus and Native L&F’s can basically be summarised down to the argument between consistency between all Java applications (Nimbus, by default) vs consistency with the desktop (Native, by default). My preference is for consistency with the desktop, meaning that I would rather see the native L&F.

Arguments can of course be made that not even Microsoft follows desktop-consistency between its applications (Windows Media Player, Windows Live Messenger, MS Office 2007, etc, etc, etc), so why should Java apps be consistent. In my world, I tend to write enterprise software, and so I would argue that when deploying a Java app to a ‘common’ end-user, anything that can be done to minimise the ‘wtf’ factor to the office user is good. The native l&f does this as it looks like other applications a user uses, whereas Nimbus immediately scares my users into thinking this is a funky app that may not follow normal rules (I even feel this way when first introduced to a new Microsoft ‘skinned’ application, and I’m an ‘advanced’ user).

Cheers, and regardless of your choice, it’s good to see consideration being given to Swing!

I agree with Jethro. One of the main sellingpoints of Java is the cross-platform support. Nimbus emphasizes this in a good way to the users. Also the new painter style building of components which is used in Nimbus is very easy to understand and use for new Java users. With the eventual Nimbus Designer tool, which I hope will be released soon, new users can quickly and easily get hooked to Java. So Nimbus got all my votes!

The concept of Nimbus (being a fully multi-platform and fully scalable LAF) is a good one. But it looks ugly (sorry). Java software looks just beautifully under Gnome. (For windows I dont know). I voted for native LAF.

Please allow me to ask a (slightly off-topic) question: Does anyone know, how to make Java software use Gnome-LAF under KDE? (I have Gnome installed. Using it, Java apps look good, but under KDE, they’re are just ugly, no way to affect LAF)…

Native. This only matters to new developers when they create their first GUIs. Then it should look like they are used to, which is the platform they develop on. This will make them more comfortable and it will be one less new thing. Later, when they get the hang of Swing, they will have acquired enough knowledge to change it depending on if it is more important that it should look exactly the same on multiple platforms, or if the user should feel at home with the look.

I agree with Jeff Martin. I think in the browser (ie Applets), use Nimbus, and on the desktop, use native. The web is a world which typically doesn’t look like the desktop, and having a cross platform look and feel would benefit here, whereas on the desktop, it’s (obviously) a desktop app, and should fit that look and feel.

Definitely the native look and feel. Work has to be done on the last component that suck in Swing such as the JFileChooser. It itsn’t native and will never be, why not fix FileDialog instead. In my applications I’m currently using SWT’s FileDialog on Windows as it’s native and shows the right dialog each user expects (Vista vs XP). Nimbus is cool but it still has still some bugs such as menus with one letter accelerators.

I would generally pick the native LaF, but the problem with it is that it is a constantly moving target and it will never look quite right. For me the most important qualities for the default LaF should be: fast, good-looking, blending-in nicely with the rest. Right now Nimbus answers the first two, so with a twist it will probably be the right choice. The twist is that Nimbus should pick up the color palette of the native OS, and most importantly the DPI and fonts configuration.

Default PLAF should be OS native PLAF ! An additional combo box should be added to the Java Control Panel to enable user to change the default PLAF to use in Java application. Any application will be still free to override their PLAF as usual

My vote is for native look and feel by default (I’m thinking of Windows in particular). Although Sun’s Windows LAF needs work, it’s better than both Metal and Nimbus. Karsten Lentsch’s Windows LAF is superior to all three (buy his implementation and roll that into Java 7!).

My feeling is simply anything that isn’t Ocean/Metal will be an improvement! My preference would be for native, but given that the Gtk implementation isn’t as robust as the Linux, it’s a bit of a shame. Nimbus is a vast improvement, so it wouldn’t be a bad place to start, although I do prefer Jgoodies or Substance (not as grey or “bulky”).

I support bjb’s idea about having a setting in the Java control panel to allow people to choose their own preference.

The default look and feel should be the system/native look and feel. Unless there is a very good reason Java desktop apps should be indistinguishable from native apps. Not using a native look and feel has done as much harm as anything else with regards to poor acceptance of Java desktop applications. If there are problems with the native L&F on any platform then the problems should be fixed.

Nimbus has a significantly different mechanism for handling transparency than other look and feels.

i.e. jComponent.setOpaque(false) did the trick for others.

I tested one swing app that used this extensively and it looked horrible in Nimbus (requires re-coding).

For that reason, no to nimbus as default.

Use native for Windows. While the Ocean theme is nicer than Steel, end users seeing Metal only gives ammunition to the Java haters out there. Native fits in a lot better with Windows, though I was never impressed with the Gtk L&F implementation on Linux.

NB: The system look and feel falls back to Metal on KDE/non-gnome X11 desktops so…

Ivan: re the KDE setting, I believe an environment variable/system property is read – you’d need to check the UIManager source I think.

As far as applets go, browsers often have their own independent theming – maybe we need a XUL L&F for firefox?

Note that Nimbus is more strick than other L&F about creating and using components outside the Event Dispatch Thread. When testing it, I had to change my code to make it work. I think that several applications will break if changed to default.

Well, I voted for the native look&feel. Though I like that Nimbus offers better configurability (and hopefully by the time of JDK 7 even a visual designer), it’s current state, well, does not really match my visual preferences.

Nimbus looks nice, but to retrofit it to an existing app requires a lot of work going well beyond the layout changes. Font handling is one of the nuisance features, if an app specifies fonts for components then under Nimbus they can end up with the font changing as the mouse passes over the component or depending on the selection state. The asymmetric scroll bar visuals are another nuisance, no apparent way to correct them according to their position relative to the component. If Nimbus were to be the default rather than a deliberate selection it would need to play better with existing code.

Nimbus looks great, but is NOT 100% compatible with previous LaFs.
Several long used Swing properties are missing, and almost impossible to fix unless you fix your code to run on both paths : old swing and Nimbus.

As sad before, applications supporting Nimbus must be made from scrach, and with care to make it also works on native LaF.

I say fix the bugs in Numbus, then make it the default LF. Unfortunately, visual bugs filed for Nimbus are given low priority. For example, please get rid of row striping in JTables! (If I want striped rows, I’ll write them myself.) As it is, the stripes make it impossible to write my own renderer without losing the striping some columns. Many other people posting here have mentioned other Nimbus bugs that should also be fixed first. Aside from these bugs, Nimbus looks gorgeous.

There’s a good argument to be made for using the native PLAF, but any existing app that needs native is already set that way, so this change will only affect those that need a cross platform PLAF.

Even if we go with native, I like the idea of making a cross platform PLAF the default in browser apps.

As for the claim that we’ll give ammo to Swing critics when we don’t use the platform PLAF, I say those of us who know how to write a Swing app that runs smoothly and performs well should stick with cross platform UIs. Let people know Swing apps can run fast.