As i was looking through the folder structure of the latest Mustang Update N, a thought occurred to me to look inside the rt.jar. There are some interesting things there, and this entry will look at the class names of Nimbus look and feel.

The Nimbus classes are located in the sun.swing.plaf.nimbus package, and as Jasper already mentioned, most of the code is generated from a designer tool. While the source code of Update N is not yet available, you can still see some quirks of the auto-generated code. Let’s run a simple utility that prints out the top ten list of JRE classes with the longest names:

92:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState
91:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneIconifyButtonWindowNotFocusedState
91:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowMaximizedState
89:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneCloseButtonWindowNotFocusedState
88:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMenuButtonWindowNotFocusedState
78:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter
77:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneIconifyButtonPainter
75:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneCloseButtonPainter
74:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMenuButtonPainter
61:java_beans_beancontext_BeanContextSupport_PersistenceDelegate

Restricting this list to public classes only (classes with public modifier, which can still be in internal sun packages), we get

78:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter
77:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneIconifyButtonPainter
75:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneCloseButtonPainter
74:InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMenuButtonPainter
53:OptionPaneOptionPaneMessageAreaOptionPaneLabelPainter
45:MemberSubmissionAddressingWSDLParserExtension
40:ContentHandlerAlreadyRegisteredException
40:SQLIntegrityConstraintViolationException
40:SocketFactoryContactInfoListIteratorImpl
39:SpinnerSpinnerFormattedTextFieldPainter

Obviously, the class name length has nothing to do with the functionality itself. It just shows how easy it is to overlook something when you’re auto-generating code.

Going a little back to Mustang update 2, the first list looks like this:

61:java_beans_beancontext_BeanContextSupport_PersistenceDelegate
59:javax_swing_tree_DefaultMutableTreeNode_PersistenceDelegate
52:javax_swing_DefaultComboBoxModel_PersistenceDelegate
50:javax_swing_border_MatteBorder_PersistenceDelegate
48:java_util_AbstractCollection_PersistenceDelegate
48:javax_swing_DefaultListModel_PersistenceDelegate
47:UnsafeQualifiedStaticCharacterFieldAccessorImpl
47:java_awt_GridBagConstraints_PersistenceDelegate
47:java_awt_font_TextAttribute_PersistenceDelegate
46:javax_swing_ToolTipManager_PersistenceDelegate

and the second list looks like this

40:ContentHandlerAlreadyRegisteredException
40:SQLIntegrityConstraintViolationException
40:SocketFactoryContactInfoListIteratorImpl
38:DOM2DTMdefaultNamespaceDeclarationNode
38:FormatFlagsConversionMismatchException
38:TaggedProfileTemplateFactoryFinderImpl
37:Canonicalizer20010315ExclOmitComments
37:Canonicalizer20010315ExclWithComments
37:IEEE754FloatingPointEncodingAlgorithm
37:RelationServiceNotRegisteredException

So, what is your best example of the longest Java class name that you have ever seen? Can anybody beat 92 characters? .NET comes quite close with 86 characters :)

It looks like anywhere you go in the Java blogosphere, people are only talking about Java 6 (or lack of thereof) on Leopard. Some say that the only reason they bought Leopard was for Java 6, some say that their honeymoon with Apple is over, and some say that Java 6 will be available shortly as a separate download. And 99% of the postings and the comments seem to agree – Java 6 should have been included in the golden master of Leopard.

I thought about it over the weekend, and time and time again i reach the same pragmatical conclusion – i don’t care about Java 6 on OS X, and for that matter i don’t care about OS X as a Java development platform. While that may sound as a harsh statement, allow me just a few minutes of your time.

I’ve already written that for me, an operating system is just another layer in my development platform. I’m more interested in the tools that i’m using and the applications that i’m developing. The things that i said 30 months ago are still true – i’m perfectly OK with my Windows machines, because i rarely directly interact with the operating system. I might have switched to Linux, but pragmatically speaking, it is not a good business proposition. Between 150$ for the OEM version of Vista and spending 12 hours to download and install OS and configuring the Java environment (on my free time during the weekend away from the family), i choose Vista any given day.

Now, let’s talk some numbers. The market share for Windows is somewhere in 90-95% range, and while sales of Mac machines rise on the quarterly basis, so do sales of Windows boxes. One might say that these numbers are for all the machines, including corporate environments and home machines for non-IT people. I’m looking at the visitor stats of this blog, which is has a very specific technical orientation, and the numbers are a little surpising:

• Windows has 75.6%
• Linux has 14.4%
• Mac has 9.6%

Yes, even for such a narrowly oriented site that mainly talks about Swing, Java2D and other UI topics in Java land, Mac doesn’t even cross into double digits. While you do see most of JavaOne presenters use Mac laptops, it doesn’t really extrapolate to the wider audience of JavaOne attendees, and most certainly it doesn’t extrapolate to the much wider audience of Java developers. The same applies to the blogosphere numbers – i’m sure i have seen about 20-30 rant entries on this subject over the past three days. Let’s be generous and say it’s an even hundred. Is that a lot? It is a lot of noise, but compared to the number of blogs tracked by JavaBlogs (2261) it’s not that much.

Looking at the bug reports for my open-source projects over the past three years, i see only two Linux-specific bugs and one Mac-specific bug. Yes, about 500 bugs reported via the bug trackers, forums, mailing lists and direct mail, and only one Mac-specific bug. Of course, most of these bugs were cross-platform, but so have been the bug fixes.

Now, your numbers might be different. If you’re developing a commercial product that is targeting multiple OSes, you might not be in a position similar to mine. However, if you spend more money to provide support for Mac than what you make from product sales on Mac, that is a bad business proposition. In this case, you might as well say that your product is for Windows only (like the vast majority of all the applications out there) and don’t mention that it’s in Java (so you don’t get blog-flamed about lack of cross-platform support). Of course, in this case you might as well switch to Win32, MFC, WinForms, WPF or whatever technology is pimped that year, but that is a topic for another blog entry.

This is, of course, my personal subjective opinion. I never had a Mac, and this fact alone might severely skew my judgement. But on the other hand, i never had to have a Mac as a Java developer. And this most certainly doesn’t change now with Leopard. Windows (in its various flavors) was and remains my only Java development platform (both at work and at home), with Linux and Mac delegated to what they really are at this point in time – alternative OSes with minor penetration to be installed for platform-specific bug fixes. Will this change in the future? I’m a pragmatic person, so i don’t say “no”.

This should be an incredibly useful feature to any serious Eclipse plugin developer. The latest milestone of the next Eclipse 3.4 release (available starting September 21st) added a “plug-in spy” feature that shows information on the currently active selections, editors, views and more. This is going to be a great time-saver. No more wading through Eclipse source code trying to figure out which class you should extend and why your plugin doesn’t seem to work as you expect it to. Here is how it looks like:

Many thanks to the Eclipse developers for adding this feature. A pity that our project is mandated to use 3.2.1 :(

It’s been about three months since Sun has announced JavaFX “family of products” at JavaOne. Based on the original work by Chris Oliver, it has been picked up by the powers-to-decide, fed into the relentless PR machine and since then touted as the next big thing on the desktop. It certainly has the technical potential with all the engineers working on it (more on that later). And the aspirations are most surely lofty, positioning JavaFX against Flash, Flex, Apollo and SilverLight. My main concern is with the name.

Why does it have to have “Java” in it? The end customer doesn’t care how the application is written. He cares that it’s easy to install. He cares that it starts fast. He cares that it runs fast. He cares that it doesn’t crash on him. He cares that it doesn’t lose his data. He cares that it does what it is supposed to be doing.

Let’s look at the competition. Does anybody outside the development teams of the respective products know what language are Flex, Apollo and SilverLight written? I guess some mix of C with other languages. Do i care when i see a nice Flex / Flash site? Of course not. Do you ever hear Adobe talking about “bringing the full power of language X to the desktop”? What do users know about the full power of this language? Or, to be more precise, what do they care? As long as it’s a one-click user-friendly installer, immediate startup time, and no crashing, they don’t care at all.

Another rule that JavaFX is blatantly violating is the “underpromise and overdeliver”. No designer-friendly content authoring tools, buggy IDE plugins, excruciatingly slow runtime and constantly changing language definition. Of course, these are all coming (or at least promised to come), but promises are just words. While the competition is smart enough to talk about features after they are implemented, Sun’s marketing machine is effectively ruining any chance that JavaFX had to compete by selling promises.

The developers are, of course, eager to download the bits and play with them. Quick frustration and “i hope it would be better” ensue. Does that remind you of anything? Swing still carries the burden of perceived as slow, buggy and odd-looking, even after all the effort that went into it in Tiger and Mustang. NetBeans has long ago lost the “war” to Eclipse and the attempts of catching up in the latest 6.0 version are not going to change that. If Sun wanted JavaFX to follow the same perception patterns, it most surely succeeded.

What can be done? First of all, a major shakeup in the PR / marketing department. Talk about things that are done, not about the things that you’re going to do. The later might work when you’re working on a product that doesn’t have any competition (brand new market place), but doing this in a saturated market with very experienced players will quickly backfire and you will carry the burden of bad reputation for a very long time. Second, don’t focus on the technology behind the product. Rebrand it and lose the word “Java”. And while you’re at it, lose the “FX” as well. Third, stabilize the language, squeeze every bit of performance out of it and create a comprehensive suite of tools. All this before you make any public announcement (look at Apple if you need to). When creating the tools, have graphic designers on your team. Learn from Microsoft that had a professional designer as a part of Blend team. If you want to compete against Adobe and Microsoft, do not let the developers design content authoring tools.

And by the way, while we’re at it, don’t rename your stock ticker as well.