Java?! More like molasses.

December 23, 2006 8:40 PM

Why are java apps so slow on OS X?

I'm forced to use an imaging app for raw file conversions that is written in java and it is painfully slow. I'm using a Mac dual G5 1.8 with 4 gigs of RAM and no matter what I do the app is unusable. It's been my experience that anything written in java and run on a Mac is sluggish at best. Does the same hold true for Windows PC's or is this a Mac specific problem?

posted by photoslob to computers & internet (16 answers total)

What are you running? ImageJ?
posted by Blazecock Pileon at 8:54 PM on December 23, 2006

My experience with Java on OSX is more or less the opposite of yours. Apple has done a fairly nice job with the Java runtime, at least the PPC version I'm familiar with, and I find performance and UI responsiveness of Java applications to be far better under OSX than under Windows.

Java used to be really very painful on the Macintosh platform, in the pre-Unix days, due to a fairly heinous Apple runtime for the MacOS. That doesn't hold true any more, or at least it shouldn't unless you're using Classic to run your Java applications (which is not a good idea at all).
posted by majick at 8:55 PM on December 23, 2006

The app I'm running is Leaf Capture v10 and most people I've come into contact who are using it complain of the same thing. The previous version of the softtware was not java and is very fast and stable.

My opinion of java being slow also comes from working at a company that has rolled out part of it's pagination system driven by java apps and they're stupidly slow and unstable.
posted by photoslob at 9:02 PM on December 23, 2006

I've found that Java, in general, no matter what platform you're running on, is slow and unreliable. Remember that Java is only half-compiled, and is running on a virtual machine (that is, the Java Runtime Environment is kind of like running a separate computer within your computer). If you can avoid Java, by all means do so, unless you can run it on a Sun mainframe.
posted by fvox13 at 9:05 PM on December 23, 2006

Wow. They rewrote their entire program in a different language? Sounds like a candidate for TheDailyWTF.

As far as I can tell, Java isn't any slower on OS X than it is on any other platform. For example, parts of Cyberduck are writen in Java, and I don't have any problem running it. I've occasionally run Azureus for torrents, and while it's a behemoth, it seems pretty responsive.

The problem with Java isn't the language but Java programmers. Some really horrible coding practices that are forgivable in other languages just grind Java to a halt. For example, many people aren't conscious of the overhead immutable string manipulation entails (or that String is immutable to begin with). When they should be using StringBuffer or StringBuilder, they're throwing +'s everywhere instead. Languages like C encourage you to allocate one large buffer and just hope it remains big enough; Java guarantees the buffer is always large enough, but you're constantly reallocating.

That's just one example; there are others. The fact that this company just rewrote their entire application makes me believe that (a) they aren't comfortable with Java yet, leading to (b) they did a piss poor job in the rush to ship a product.

Ohhh... the examples I could show you in just about any language. PHP/MySQL users are frequent offenders. You wouldn't believe some of the ways people abuse or just outright ignore easy SQL optimizations. And just a year ago I saw some horrible C++ code that begs for lock contentions, network timeouts, and faux non-deterministic behavior. And Lord Almighty, you wouldn't believe this one project that involved shell scripts.

Point is, the problem aint Java. Sorry your program sucks, but I doubt there's much you can do about it.
posted by sbutler at 10:03 PM on December 23, 2006

Remember that Java is only half-compiled, and is running on a virtual machine (that is, the Java Runtime Environment is kind of like running a separate computer within your computer)

What a complete load of FUD. I guess you've never heard of Hotspot which compiles bytecode into native machine code on the fly, which then runs at full speed with no interpreter overhead. Java may have a number of flaws but "it's not compiled" is not one of them.
posted by Rhomboid at 10:19 PM on December 23, 2006

If an app massively thrashes the heap, it's entirely possible for performance to go to hell in this kind of language, JIT compiler or no. The string manipulation that sbutler describes is one example of that, but languages like Java tend to encourage other ways of abusing the heap, and programmers who don't really understand how a heap really works can produce code which pretty much cannot run rapidly on any computer, because the Java runtime system spends entirely too much time doing garbage collection and reallocation.

Whether that's a fault of the Java language specification or a matter of ill-trained app programmers is a question left to the student to answer.
posted by Steven C. Den Beste at 10:31 PM on December 23, 2006

I've found that Java, in general, no matter what platform you're running on, is slow and unreliable. Remember that Java is only half-compiled, and is running on a virtual machine (that is, the Java Runtime Environment is kind of like running a separate computer within your computer). If you can avoid Java, by all means do so, unless you can run it on a Sun mainframe.

That's an absurd statement.

As others said, it's not the runtime, it's the program. Another problem with Java programs. I imagine they're probably doing something rather disgusting with the way they're storing images in memory, probably causing lots of copies of the images to be garbage collected. They're probably not doing too much string manipulation in an image app.

Java is pretty fast, but some of the APIs (and the string library) make it easy to write slow code. It would probably be just as slow if compiled with something like GCJ
posted by delmoi at 11:13 PM on December 23, 2006

By the way, if you're going to dismiss a language for using bytecode and a VM then in addition to Java you have to condemn Python, Parrot (aka Perl 6), PHP, .NET CIL (C#, VB .NET, J#, Managed C++, etc), and many other languages. It's extremely common.

To the original poster, are you using the latest version of the JRE? That has always been the first thing I do when encountering performance issues. According to apple's site that's J2SE 5.0 Release 4. If you are currently using something like 1.4 I would expect a great improvement. There are also a number of VM options to tweak that might speed things up.
posted by Rhomboid at 1:52 AM on December 24, 2006

When they should be using StringBuffer or StringBuilder, they're throwing +'s everywhere instead.

Actually, the compiler will convert +'s to StringBuffer.append's in its built-in optimization strategies.

I would recommend getting the latest JRE (Java 6). It has shown a very noticeable improvement in speed over 1.5.
posted by Civil_Disobedient at 7:18 AM on December 24, 2006

Civil_Disobedient: Is that JRE available for OS X? Doesn't seem to be from the linked page.
posted by adamrice at 7:38 AM on December 24, 2006

I'm installing the J2SE release for PPC as I type this. What specific tweaks should I be trying from the VM options page? My guess would be to increase the heap size? What else. TIA and Happy Holidays!
posted by photoslob at 8:41 AM on December 24, 2006

Last I checked, Apple was fond of writing its own JRE/JVM for OS X, rather than letting Sun do it. Maybe this is how they sort of make native widgets available in Java apps? But suffice to say, it means they're always many months behind the official Sun releases.
posted by heresiarch at 1:09 PM on December 24, 2006

The J2SE 5 release I downloaded seemed to make a difference. I tweaked a few VM options and I think things are faster. Certainly feels faster. Anyone have any advice on tweaking VM options?
posted by photoslob at 1:46 PM on December 24, 2006

I don't know enough about OS X to say whether Apple is just repackaging the Sun JRE with enchancements/extensions or is actually writing their own, but it appears to be the former. It looks like you can try a developer preview of Java SE 6.0 if you log on to the ADC site. Although this is beta software and seems like it might not be fully stable:

Java SE 6 Release 1 is based on JDK 1.6.0_b88 and brings enhanced functionality to the Java SE platform on Mac OS X v10.4 Tiger. The preview supports both Intel-based and PowerPC-based Macintosh computers and is not removable. Please see the release notes for more information. This is Developer Preview 6 of Java SE 6 Release 1 for Mac OS X Tiger.

Regarding twaking VM settings, I'm at a loss as I'm no Java expert and it looks like it's the kind of thing that depends a lot on the details of how the application was written. The only experience I've had is by trying the settings given on the Azureus wiki for reducing its memory usage, which may or may not be applicable as a starting point.

If this Leaf Capture application has a user community or unofficial support forum of some kind you might try searching to see if anyone else has had success with different heap/GC settings.
posted by Rhomboid at 8:18 PM on December 24, 2006

No one in the photo community knows about java and most folks have abandoned this app for Lightroom or Iridium Raw Developer. Problem is that these other apps don't allow you to shoot tethered so most photogs are just using the older version of Leaf Capture when necessary.

I'm probably the first person who's gone outside the support forums and community to ask questions about java and I'll be reporting back what I've learned here.

Thanks for the helpful info. AskMeFi rocks.
posted by photoslob at 8:26 AM on December 25, 2006