Funny thing is, one of my favorite Mac apps was/is written in Java: Cyberduck FTP client.
Cyberduck is an open source app originally written using the Java/Cocoa bridge, then using some hybrid of Cocoa and Java. But the thing is, the end user has absolutely no idea that it's a Java application. The only reason I know it's written in Java is because I looked at their source code to see how they implemented Quick Look (before it was a public API), and boom, the damn thing's in Java! As a longtime hater of Java desktop apps, I was flabbergasted.
As far as I'm concerned, OS X was the only desktop platform where Java had any sort of chance for user acceptance, but it never caught on with developers. As such, Java has been effectively dead as an option for desktop development since OS X Leopard.
The main point seems to be: They don't use any of the Java GUI frameworks. They instead use some Cocoa bindings.
See here: http://trac.cyberduck.ch/browser/trunk/source/ch/cyberduck/u...
Actually, I wonder why that is. I always thought that it is Java itself which makes Java applications feel slow. But I haven't noticed this in Cyberduck. So maybe it is just AWT.
I wonder why that might be. Maybe because AWT does all the drawing itself, which is much slower compared to the native toolkit?
My belief is that apart form some overhead in AWT against native toolkit, 90% of the laggish experience in java apps is due to poor coding.
In turn, this is probably a byproduct of the java platform/language (abuse threads cause they are easier than an event loop, abuse locking cause synchronized is more obvious than util.concurrent, avoid thinking of memory management cause you have a GC, do not pay attention to proper data structures cause you can get away with builtin collections etc)
Specific examples from your experience?
First one I think of (cause I redid it today, in ruby :) is:
you need to keep a list of lines you already processed in a large log analysis. I'd just use a Set (which is a hash underneath) and get done, although I'd have saved a bunch of overhead (memory allocations, gc pressure) using a bloom filter.
Using a (hash)set instead of a bloom filter caused memory usage to explode, which in turn led to memory thrashing/swapping which in turn led to slow processing times.
The rest of the code runs in constant time (well, linear in the size of the item, with num(items) >> size(items[n]) ) and it did work fine for smaller inputs.
How can one look at the deprecation of a particular runtime in isolation from (a) Apple's simultaneous announcement of increasing commonality of iOS and OSX, and (b) Oracle's aggressive enforcement of comm-related java libraries?
Since Apple sells and approves all app-store products, they bear plausible liability for an iOS app, if Oracle was lawsuit-minded. I would hardly be surprised to learn that Oracle will NOT sue Apple over runtimes that could trip up Google, thanks to Apple's agreement to remove possibly-offending code.
Or, alternatively, if you have an iOS app that wants to do comm in java, how could Apple field an alternative library to one that Oracle claims is theirs?
This makes Apple-supplied java runtimes a dead end. We'll see how interested Oracle is in licensing alternatives.
I think the difference is that Apple licenses/d Java and bundles a standard VM and framework, while Google did not do so - they just used the language with their own VM and framework distinctly different from, say, J2ME.