Must-read: Chris Adamson, one of the few developers with real experience with Java and multimedia, lays out just how bad the situation is with Java on the Mac:
shoes[1].drop();

I think the problems here are not insurmountable – it’s just a matter spending energy on the future of development in Java, not ranting at Steve Jobs – or simply moving on to other alternatives if they’re better-suited to your task anyway.

Chris actually knows what he’s talking about, whereas I rant into the ether in the hopes that people who know what they’re talking about set me straight.

But I am confident of one thing. As I said last week, there are two scenarios here: one, Oracle steps in with their own implementation, and two, the OpenJDK community does. Unfortunately, right now, both scenarios are seeming unlikely. Chris does a nice reality-check on just how far OpenJDK on the Mac is from doing what’s necessary. Short list:

  • The UI.
  • Sound.
  • Mac integration.

(Hint: those are not exactly minor problems.) Oh, yeah, and then there’s the fact that, as Chris puts it, “Java’s desktop packages – AWT, Swing, javax.sound, etc. – are very much a white elephant.”

Or to put it another way, “Desktop Java is a ruinously expensive legacy that they need to do something about.”

One of the reasons Processing made it to Android so quickly, by the way, is that Processing doesn’t really invest in that expensive UI legacy. Switch the output to OpenGL and move on. But that doesn’t solve the problem of getting audio to work — which Chris puts at about a $20k cost, and for a set of packages (JavaSound) with their own set of legacy problems. And doing away with UI widgets entirely isn’t a solution, either; it’s not clear what will now happen to the many applications that rely on those, like Eclipse. (Some people were predicting the demise of the Android SDK, but remember that the core SDK is all based on command-line tools. In other words – don’t panic about that.)

Chris has at least successfully dissuaded me that Apple contributing to OpenJDK is more or less legally impossible, even if they had a desire to do so. I still think a version of OpenJDK not weighed down by these issues could have a future. Too bad Oracle dominates the OpenJDK process.

Someone at Oracle realizes this is a problem, right? They’re waiting in the wings with a Java implementation for the Mac?

Bottom line is, between the Apple deprecation, decade-old political and technical problems, and Oracle going on an IP rampage with Google, it’s hard to be optimistic about Java in general. I hope that artists and creative people begin to look at other alternatives. C/C++ is there, of course, but that’s not always the right solution for everything. Python, anyone?

Side notes… In all seriousness, considering alternatives is a good idea with or without a crisis, and commenters do just that. (LuaAV is worth a look, in other words.) I think it’s reasonable to ask Oracle to do a Java implementation, and complaints should be at their doorstep, not Apple’s. Waiting for anyone is never a reasonable answer, on the other hand. Apple’s Java implementation appears to be included in 10.7 Tiger, even though it’s deprecated, so there’s some time to work on OpenJDK. Those who don’t need legacy UI widgets have a distinct advantage, and I would question Chris’ own “$20,000″ sound example – because to me, porting JavaSound seems like a terrible idea. Instead, it seems Java just needs a simple callback audio I/O implementation that works, not a kitchen-sink audio library that doesn’t.

Sure enough, running on OpenJDK isn’t impossible. Eclipse + SoyLatte + Mac works. Have a look at this blog post and check the screenshot above. That means you can be reasonably sure you’re not losing your entire IDE, or the ability to make Android apps on the Mac. And with adjustment, I think it could also mean that the next major milestone of Processing could run on OpenJDK. (I’ve accidentally run Processing on OpenJDK without incident because of forgetting to switch default Java on Linux a couple of times – and was surprised when nearly everything worked. So it’s time to go see what breaks, and un-break it. What I don’t know is how much of a hit on the Mac the lack of Apple’s AWT enhancements cause. But at least Processing doesn’t use Swing.)

Eclipse on SoyLatte without X11

  • Gilbert Bernstein

    I'm not quite sure what the current hubbub is about, but I don't think that either Python or C/C++ are reasonable replacements for Java. I've heard that Python is usually estimated to run about 2 order of magnitude slower than C/C++ code and Java is about 2x slower as rules of thumb. 2x is a very reasonable cost to pay in order to not have to worry about manual memory management etc. However, I suspect that a Processing-like environment would be much more frustrating to use for complicated projects if it ran approximately 50x slower.

  • Peter Kirn

    Well, I think the hubbub is about the fact that there isn't a sense of a strong replacement for Java. Python, to use that example, is happier with a healthy VM.

  • Marc Sciglimpaglia

    For those who are looking for something faster than Python/Ruby/et alia, you might consider Lua. I've made some bindings to OpenFrameworks for a project I'm working on with considerable success, and the speed has been quite acceptable, even considering that I'm not currently using the LLVM-based native JIT compiler.

    It's not as much of a drop-in solution as Processing, as you'd still need to generate the bindings yourself, though maybe some enterprising soul will publish a pre-rolled distribution one of these days. Frankly, I think Java is a somewhat obnoxious language for the kind of rapid prototyping that Processing is intended for anyway. YMMV, of course.

    There is also the ambitious LuaAV project, although IMHO it's not quite mature enough to warrant using it for anything serious at this juncture.

    http://www.lua.org http://lua-av.mat.ucsb.edu/about.html http://code.google.com/p/llvm-lua

  • Peter Kirn

    Yeah, absolutely. Lua is a huge contender.

    Python can be a contender, too, for the stuff we do, just because a lot of time you're just wrapping some logic around native code. In fact, it may even be on the GPU, not CPU bound. Ditto JavaScript. Changes in coding styles make this a bit less painful.

  • Marc Sciglimpaglia

    BTW, I may have spoken too quickly about LuaAV. It's been a while since I've checked it out, and it looks like it's made a lot of progress (how time flies in tech). Definitely worth a look if you're looking for a Processing-esque integrated framework.

  • Marc Sciglimpaglia

    That's a good point, Peter. One could make a pretty sweet video effects rack just using GLSL shaders, for instance, in which case the performance penalty of using Python vs C++ would be negligible. I expect that we'll probably be working more and more with the GPU in the future, regardless.

    One advantage of Lua here, not that I imagine I'd need to convince you, is that creating bindings around native libraries is breathtakingly easy, even compared to what you have to do to create an equivalent binding in, say, Python. This encourages more application-specific choices of what native libraries to use, which I think is probably a good thing in the long run.

  • http://thefactoryfactory.com Joshua Noble

    Just my quick 2c: I think that both Python and Lua can provide a linguistic clarity simplicity that Processing/OF/etc want but don't provide because of their core language allegiance. I've taught beginners Java/C++/C dozens of times and usually it's just not that much fun for them. This might be an interesting opportunity for everyone to think about what the goals of creative computing should be and how those goals can be achieved. Java doesn't really have the raw speed and extensibility of C and it's not as friendly as Python/Lua/Ruby, etc, so it might simply be the end of it's time (as much as I hate saying that, honestly). This could end up being a good thing that helps us (i.e. everyone making/thining/teaching in this space) think about the needs of creative computers from beginners to advanced. There isn't a clear answer, and that could be a good thing, because I think a lot of projects are going to get accelerated/attended to, very quickly.

  • Peter Kirn

    Oh, now, come on — let's not let this devolve into language snobbery. Let's rephrase that:

    There's no reason that going forward platforms like Python and Lua can't teach programming and empower artists in the way Java has in the past.

    And that much I'd certainly agree with. I think the bigger issue is what happens to all this software that has Java dependencies. And the Java community had thought it won a battle to open source Java in 2006, with some significant gains for the larger computing community. So, someone ought to be at least a little alarmed that now, in 2010, we're still dependent on Oracle's JDK, Apple's dropping their Java completely, and the biggest new open source implementation of Java (Google's Dalvik) is embroiled in a legal battle.

  • Peter Kirn

    Also, see above — added to the post. Apps that don't use a lot of Java's broken legacy code aren't so doomed. Why anyone in their right mind would want to port JavaSound to OpenJDK is beyond me. (When last I checked, OpenJDK had its own audio pipeline, using code derived from Tritonus.) What may be a longer road is rebuilding optimizations to performance – OpenJDK is likely to feel like a step backward before it feels like a step forward. But maybe now this kick in the pants will help people take those steps.

  • http://zsolttorok.com Zsolt Törö

    The Eclipse IDE and other Eclipse-based applications use the SWT GUI toolkit as opposed to Swing, so making them work on OpenJDK is somewhat easier. SWT uses the native widgets of your windowing system (in this case Cocoa), so the platform specific bindings are already done. I'm sure there are minor quirks to work out, but Eclipse on the Mac using OpenJDK sounds very likely to work just fine, as demonstrated by the screenshot in the article.

  • Peter Kirn

    Yep, that's it exactly. So… if Chris' main problem is Swing and JavaSound, this just seems to me yet another reason to dump Swing and JavaSound, which have produced endless problems as it is.

  • http://thefactoryfactory.com Joshua Noble

    I didn't mean to be a language snob or, em, linguistic fight picker, though I could see how my post sounded like I was. I was conflating the JVM and the Java language itself and that was, well, silly.

  • Peter Dines

    Apple may shy away from contributing source to OpenJDK but could it still be possible for them to license or donate it to Oracle as closed source? Then again they might not want to reveal their non public APIs at all and Oracle might not want to wade into a codebase that requires a lot of Apple specific knowledge. *shrug*

    But I suppose the take home lesson is to choose open and unencumbered technology going forward. As a great thinker once said, fool me once, shame on you; fool me twice… can't get fooled again!

  • http://www.studioimaginaire.com Nat

    I just want to chime in about Python. People often say it's a slow language, that's true, but as Peter said, most of the time you are wrapping native code which is pretty fast. It's the same thing with Max/MSP, you can code an abstraction in Max or code it directly in C which will be much faster.

    In Python you can create bindings to existing C/C++ libraries or use the native Python SDK to create C Python module. Wrapping existing libraries usually works well, the trade off is that the code is not very "Pythonic". Using the SDK usually results in libraries easier to code in. A good example is Olivier Bélanger's pyo module, it's a sound processing/synthesis library written in C using the Python SDK, in my opinion it's very elegant and it's pretty fast. For the curious : http://code.google.com/p/pyo/

  • http://privatefunction.net Silentium

    Oracle and Apple Announce OpenJDK Project for Mac OS X
    http://www.apple.com/pr/library/2010/11/12openjdk

  • Pingback: Create Digital Motion » Java on the Mac is Oracle’s Problem Now; OpenJDK the Path Forward