[snorkel]

Two other reasons I avoid Java the dependencies ecosystem for a typical Java app is bloated and always changing, and it didn't really live up to the promise of write-once-run-anywhere. And by the way, the over-abstraction habit is really annoying when you're trying to write a simple util app and you can't just say foo = new Foo() instead you have to extra nonsense such as factory = new FooParamsFactory() then fooparams = factory.getFooParams() then then foo = new Foo(fooparams) ... it's nice to get away from that nonsense. I just find Java to the playpen of architecture astronauts who would rather design APIs than write apps.

[St-Clock]

"it didn't really live up to the promise of write-once-run-anywhere"

Care to explain this one? All the code I have written for the past 10 years do not need to be recompiled and can run on Windows/Linux/Mac/*BSD 32 bit/64 bit. And I used IO, NIO, sockets, threads, files (not necessarily high-level stuff).

[mechanical_fish]

It turns out that there is a level of abstraction where every desktop OS is just like every other. And Java evolved to exploit this common ground.

But the ultimate lesson was that the intersection of all operating systems is an awful place to live. Because Java's not-exactly-native widgets often have the wrong look, it feels generic. Because they often have subtly different semantics, it feels slightly alien. Because platform-specific behaviors like drag and drop generally don't work right, it feels like an outsider, even though it's running on your machine. And because the app requires a giant brick of a runtime that generally hasn't been preloaded by anything else, it starts so slowly that you can practically hear the gnomes turning the rusty crank on the starter motor.

And it's not as if these are fatal objections. Clearly, based on the success of the web, they are not. But the lesson has been: If you're going to run an idiosyncratically-designed slow-loading quirky app that's imprisoned in it's own window why not just run a web app. And that's what people do.

[mnutt]

For non-gui work it mostly lives up to that promise, but if you're building a consumer app you end up having to do a lot of tweaking per-platform.

[jtheory]

I've done my share of Java GUI programming (and still have Java applets running on a fairly active site... I can't replace them -- HTML5 and Flash aren't likely to support MIDI input, ever), and the "write once run anywhere" flaws are generally all in GUI programming.

But I think everyone has known for a long time now; that's not Java's sweet spot. It's do-able, but for obvious reasons it's harder to do cross-platform, and they made a few large missteps along the way trying to crack that particular nut.

Nowadays the vast majority of my Java work is server-side, and it all runs anywhere, without a hitch. The last time I had cross-platform Java issues with server-side code was on an AS/400.

[uriel]

I have maintained Java apps running on FreeBSD servers, it was a nightmare. And don't even dream of doing that in OpenBSD (which IMHO is the sanest BSD and even nix around).

[jtheory]

What kinds of problems did you run into?

I've deployed onto primarily Solaris and various flavors of Linux with no problems, but don't have much experience with *BSD... though I've generally assumed it would be a similar experience.

[uriel]

Problems like having to patch and build your own Java runtime because (if you are lucky and there is a working one) because Sun made it illegal to distribute modified Java distributions that had not passed the test-kit, and everyone should know that Sun/Oracle do not give access to the test-kit to anyone that doesn't pay them a ton of $$$.