Slashdot Mirror
Tuning Java Swing apps for Mac OS X
tarkin writes "Sven Van Caekenberghe just finished a tutorial article, 'Tuning Java Swing applications for Mac OS X', that explains how to tune standard Java Swing applications to conform to the Mac OS X User Experience and make them virtually indistinguishable from native Mac OS X applications. Topics include handling basic Apple events, packaging applications, adding a custom icon, file dialogs, about boxes, preferences, customizing the menu bar, supporting Finder drag-and-drop, standard help, and basic multi-document support, as well as using MRJToolkit and MRJAppBuilder. The PDF of the article, as well as a Mac OS X disk image with a binary version of the two demo applications and the source code can downloaded from his home page."
OK, I'm an avid MacOS X user.....BUT:
The OS is slow.
Add to that the fact that Java is slow and you end up with a user experience that is nothing short of horrendous. Good examples are LimeWire and JEdit...fine apps by any standards, but they are so sluggy that they border on being unusable and bog down the entire OS.
I've tested LimeWire under different loads and settings and regardless it bogs down the entire window manager. Window live drags are slower, the overall OS is less responsive, etc. That's ONE Java app that grinds your system to a halt...and this is on a 500Mhz G4 Sawtooth of mine.
Developing Java apps for OS X is a hopeless case as of present. Even regular compiled Carbon and Cocoa C apps could do with a considerable speed boost. There is certainly no headway for slow, high-level stuff like Java. Well...sigh...maybe in a few years when those 2Ghz quad-G5's start shippings....=)
Yeah. Sure.
You don't know what you're talking about.
Applications can be slow. The OS is not slow.
Java on OSX is rather speedy, and compares favorably with the previous platform I've used it on, Linux.
Cocoa apps are totally speedy, as fast as C apps.
Carbon apps that are poorly made will be slow, and if they're really poor (like IE) they can slow the whole system down.
But your generalizations are just wrong.
Yeah, and you guys panned the ipod too: http://apple.slashdot.org/article.pl?sid=01/10/23
What about SWT, as used in eclipse?
pooptruck
I thought that is what you got with Java on the mac.
I've been doing mostly server side stuff so I can't say for sure, but it is my understanding that you write a Swing UI Java App on the Mac and on the Mac you get the Aqua look and feel. This is from conversations with an Apple developer who was the person who wrote it, but I may have misunderstood.
At the very least it should be one of the choices for looks that you get with swing (Remember windows, metalic, etc?)
So you write a swing app and on OS X it looks like OS X and on Windows it looks like Windows and on Linux it looks like Windows and on Solaris it looks like Swing.
You're right about apple optimizing their JVM etc. The reason 1.4 is delayed (so the rumors go) is that they are doing a complete rewrite. From what I saw with 1.3 they've done some great improvements on what Sun ships.
Wouldn't realbasic do what you want as well? One language-- though it has C support as well-- and deploy on at least Windows and Mac with the same UI.
Inherently when you make a multi-platform dynamically-chosen-look and feel, or consistent look and feel across all platforms, there WILL be compromises because the platforms are different.
So, I'm not sure what you're looking for-- if you think that someone can make one that dynamically picks the right UI without any compromises (java's slowness, or ui variations) then I think you're not quite understanding the problem correctly.
Personally, I have no desire to support the windows platform anymore, so I just do everything in Cocoa with Objective-C. And objective-c rocks. I thought Java was the paragon of perfect languages, but I have to admit I like objective-c better.
Yeah, and you guys panned the ipod too: http://apple.slashdot.org/article.pl?sid=01/10/23
Isn't part of the aim of Java apps not to know too much about their environment? Maybe I'm only thinking of Java applets, but it seems that if you're going to build stuff in Java, to run in a VM, you should be hoping for the benefit of cross-platform compatibility, not your ability to fake the look and feel of an OS you could have programmed natively for, in, say, C or somesuch. If it's going to be Java ... at least don't force it to look like it was built for only one platform. If MacOS users -really- hate your application because it doesn't look like everything else ... well ... KDE vs. Gnome users can just say "welcome to the club!" ...
One reason for using the Aqua L&F, though, is that it is better optimized for OS X. Try running a complex application in Metal on OS X and again in Aqua. In my experiance the difference was quite aparent. You have a point though that the feel of java apps on OS X is still not quite right, but using Metal isn't any better (it just makes things more ugly).
Cocoa apps have the same file path problem. NSDocument based apps now use FSRef's as well as NSURL's so they don't, but if you write a Cocoa app that doesn't use NSDocument, its up to you to do the FSRef magic you need to track files based on their HFS+ id number.
Can I Play With Madness?
They *try* to look like Aqua, but if used Mac OS X longer than a day you should notice the difference :)
And for LimeWire: Yes, it is awfully slow, but I use another Java App on Mac OS X: CrushFTP and FTP server. And I'm just happy with it's performance. I guess Java is not the problem, the programmers are.
eclipse took me a small amount of time to get used to, but to me, its the best Java IDE on the market. Of course, the availability of refactoring is the bar to clear to even enter the competition, so that limits things a bit. JBuilder blows goats in comparison. My recommendation would be to create your own project in eclipse and start using it, rather than using sample apps.
To be fair, I haven't tried eclipse for Mac OS X, but all new builds of the 2.1 series are being created for Mac OS X as well, including the stable Milestone 1.
Is it the same as what Microsoft did? I don't think so. I'm pretty sure you had to use MS's JVM to run Microsoft "Java". SWT will work with any JVM, provided the appropriate native libraries are installed. I am a little disheartened by the limited number of alternate platforms available, but more keep coming. Give it time.
pooptruck
You don't know what you're talking about.
Applications can be slow. The OS is not slow.
When I say the OS is slow I am, of course, referring to the general responsiveness of the UI. MacOS X is a speed demon in many things...but falls far short of Linux, Windows and MacOS Classic when it comes to UI responsiveness. When I use these other OSes I feel like I've just received an adrenaline injection after extended periods with OS X. This is a problem that needs to be fixed, either with some heavy low-level modifications to the GUI or, more probably,...with faster hardware.
Java on OSX is rather speedy, and compares favorably with the previous platform I've used it on, Linux.
That's not saying much...=). Java in general is sloooow...painfully so..and GUI apps for all platforms leave plenty to be desired. I haven't made a comprehensive comparison of Java GUI speed between platforms, but I know this: the responsiveness of Java apps in MacOS X is terrible. Not bad but terrible. On my 500Mhz G4, I find most, if not all Java apps bordering on unusable and avoid running them unless literally forced to. Much to my relief I discovered Acquisition recently, and can replace LimeWire with a Gnutella client that doesn't bog down my system.
Cocoa apps are totally speedy, as fast as C apps. Carbon apps that are poorly made will be slow, and if they're really poor (like IE) they can slow the whole system down.
Any app that is poorly programmed will be slow, regardless of whether it is programmed with the Cocoa or Carbon APIs. My point in the post you replied to is that EVEN these Cocoa and Carbon apps for OS X leave something to be desired.
But your generalizations are just wrong.
I don't think so. It's not as if I'm ignorantly bashing OS X here. I've made studied various aspects of OS X comprehensively and found considerable shortcomings in MacOS X in terms of GUI speed performance. I believe I'm addressing here genuine concerns mirrored by the OS X community as a whole. I want OS X to be the greatest UNIX ever and I think it has the potential to become so. But that doesn't mean I'll close my eyes to obvious problems and pretend that nothing is wrong.
Sveinbjorn Thordarson
http://www.raunvis.hi.is/~ssv
The advantage of using a non-Aqua theme for Swing apps is you don't get confused. You see a Metal app you expect Swing behavior, then you see an Aqua app you expect Aqua behavior.
Your assessment of Cocoa apps is correct except I would add that FSRefs also work on UFS volumes (and probably others) with the one caveat that you can't pass an FSRef to another process.
What Apple ought to do is what they did with the Toolbox more then a dacade ago which is to say deprecate functions (methods) which use file paths as arguments. Instead they ought to use something equivalent to an NSFSRef as a simple file primitive. They should also revise the Aqua HI Guidelines to clarify the behavior of "Save" and "Revert" to reflect the proper Mac behavior which can currently be had by using NSDocuments or FSRefs. They should also clarify that a file's path is variable, not constant.
Ironically Swing apps behave more like Cocoa apps in at least one aspect: the behavior of text views. NSLayoutManager doesn't behave correctly. For example selecting down on the right side will select the trailing linefeed of the last line selected which doesn't follow the Mac convention.
Unfortunately these problems are NOT going to be fixed unless more people send Apple feedback and bug reports.
>80 column hard wrapped e-mail is not a sign of intelligent
>life