Java loves music and multimedia, but — well, we may actually have to let it die on the Mac in order for it to be reborn. (For the uninitiated, that triangular thing is the open-sourced Java mascot, Duke. Shown here with Project LookingGlass’ brilliant creator.) Photo: yuichi.sakuraba, via Flickr.

Java may not be on the radar of the average Mac user, but to the Java development community, Leopard has been a bombshell. Apple’s been slow with Java releases before, but something’s different this time: there’s been almost no information on the topic, and Apple has even pulled an existing Java 6 development build (released for Linux, Windows, Solaris, and every OS on Earth late last year). While Java and Apple apologists alike bend over to explain why this doesn’t matter / isn’t really an issue, we received an interesting comment here on CDMusic that suggests something big has happened they’ve all missed. This tipster argues Apple has all but eliminated its Java development team, and future development may (finally) fall to Sun. From our comments:

i had a long chat with a sun engineer over tea today where this issue came up as well. he was basically saying:

  • apple has moved all developers from the java team to the ical team except for one poor bloke who is mainly working on a stable java 1.5 version
  • the guy doing the actual 1.6 port left apple, apparently finishing the port is just a piece of cake, could be done in a few days but for legal reasons he cant do it anymore.
  • apple will most likely never release an opensource version of their vm because it is a big dirty mess using various old frameworks all tied together in spaghetti code/ secondly it seems to require sourcecode access to the mac os x standard frameworks sources e.g. coreservices etc.
  • some people at the java fx team at sun have started making their own java 1.7 runtime for os x which hints that eventually sun might take java for mac back under its control
  • speaking of sound and other java things missing in osx – the answer is: wait for java fx! its very promising, you’ll be surprised.

Why this sort of rumor may be wrong: Note that it’s not clear how much of this is an accurate picture. Java isn’t dead in Leopard — on the contrary, Java 5 has been updated for the new OS, even if Java 6 is missing. And there are still developers at Apple working on Java, as they regularly appear on the java-dev list — and there’s more than one person. Even among Java developers frustrated with Apple’s progress, it’s clear that those engineers do a terrific job — though they may need more resources, and it is unclear whether it’s still advantageous for Apple to be maintaining Java in place of Sun in the first place.

Java everywhere, media everywhere: Why bother putting this on a site called Create Digital Music, and not, you know, Create Digital Java Applications? Because Java is a key, cross-platform development platform for music and multimedia, in the form of tools like the open-source coding-for-artists platform Processing, and a significant amount of media research. The alternative is generally less-elegant, more time-intensive C and C++ code; Ruby, C#, Python, and others haven’t really proven themselves for multimedia applications.

That said, this tip — if accurate — promises some hope for future cross-platform multimedia development. The issue is, Java in its current state has multimedia issues on all platforms. JavaSound is way behind on Mac OS X, but it’s also fairly limited for synthesis and audio performance on other platforms; that’s why virtually all cross-platform audio development is based on C/C++. If Sun is serious about multimedia support in JavaFX, we could finally have a more accessible cross-platform environment for doing sound and video coding. And, quite frankly, that could mean Java 7 developed by Sun on Mac would be better than the missing Java 6 from Apple. Not to mention, having Java in sync on Mac, Windows, and Linux is kind of the whole point.

All of this is speculative, because there’s been no official statement from Apple or Sun about Mac OS X and Java. So, here’s our plea — and part of why I would even reprint such a rumor — let’s get some official information out there. Java 7 is still in development, but surely Apple and Sun can start communicating about Java 5 and Java 6.

Related: what is in Java 5 for Mac/Leopard, including the major addition of a 64-bit virtual machine, though nothing directly relevant to audio development.

  • Decaffinated In Detr

    "Create Digital Java Applications? Because Java is a key, cross-platform development platform for music and multimedia"

    Care to elaborate? I understand Processing exists, but there are a lot of other technologies with just as good multimedia capabilities, and cross-platform is not an art beholden only to Java development. In fact, Java itself is a bit sluggish in some areas and is not well known for quality interfaces to hardware — i.e. you don't see a lot of commercial games being written in it. Perhaps you are talking about Java being a key need for certain projects instead, that just happen to use it as a language?

    Personally I'm happy about inclusion of Rails in OS X, not because I use rails, but hopefully this means that Apple will start tracking closer to more recent versions of Ruby and Python alike.

  • Java is far, far, far from perfect, but in terms of cross-platform platforms + languages, I don't see a direct competitor — i.e., Java has a ways to go, but it also has the greatest potential.

    Flash/AIR/Flex: Limited to ActionScript. No 3D. Extremely limited synthesis, DSP, and image/video processing capabilities (and since you can't incorporate C/C++ code unless you happen to work for Adobe, you're out of luck there, too). No real hardware integration. Limited larger platform / libraries.

    Max/MSP/Jitter, Pd, and the like: interesting development platforms, but getting into actual code can be a pain. Max is proprietary and doesn't run on Linux. Pd runs great on Linux, less great on Mac, much less great on Windows.

    Ruby, Python, language of the week: all great languages for some tasks, and even some potential for desktop apps — but also so far unproven for desktop development and lacking in the multimedia department (and, not incidentally, in multimedia performance).

    C#/.net/Mono: Interesting, but suffers from the performance problems of Java (ie, garbage collection) without the real-time remedies available for Java. And far fewer libraries / far less community support as far as multimedia. Also, some parity issues between Microsoft's proprietary tools and the open-source Mono project, whereas the Sun-OpenJDK gap is closing, and Java is already fully multi-platform.

    As for performance, I agree Java has some performance kinks to work out, still, but Sun and OpenJDK are attacking many of these, and real-time Java has already been demonstrated with terrific audio performance. Real-time Java isn't here yet, but I think it's coming — and faster than some of its competitors. Also, as far as adding capabilities like networking or managing large projects, Java is much easier to work with than C/C++.

    As for gaming, I don't think Java gaming has been lacking because of poor interfacing with hardware. I think this is the power of Microsoft's platforms, and the consoles.

    If you have the time to code in platform-native tools or work with C/C++, then, yeah, Java may fall short. But I guess that would be my other point — "professional" development is no longer the whole sphere. You've got students, researchers, hobbyists, artists. A lot of the Web technologies have demonstrated that cool things happen when you go beyond the traditional programmer to rapid development, rapid prototyping, and designers collaborating on code. (Okay, those things CAN be disastrous … but so can projects with traditional programmers, and there are ways of making these work.)

    Java has opened development to many of these folks already, and has the potential to open up to many more. But that's why I think you have to look at this as part of a bigger picture, the maturation of Java itself. Apple's been part of the problem there, but the solution may go beyond what Java currently looks like on any OS. (Or, at least, we hope so.)

  • THEj

    Having SUN do the MAC OS X Java Vm makes a lot of sense now that Leopard is a Certified UNIX. This should make it easier for SUN to use the Solaris VM on Mac OS X.

  • Nat

    Peter: We did all the TamTam suite for OLPC using Python/Csound and it works great. (and that's on an underpowered 433mhz machine) Furthermore, we're working on a general Python/Csound library that will be really interesting. I think Python is a great language for multimedia… But it is true not a lot of apps are using it right now, I hope it will change.

  • Hey Nat — very interesting to here.

    Well, and I should say Java is *a* good choice, not necessarily *the* choice; I think what it does have going for it is this broad base of support. Synthesis has been an issue.

    In your case, is the synthesis library native Python or native C, though; i.e., what's actually doing the synthesis?

  • Pingback: Create Digital Motion » Apple Chose iCal Over Java? (And Why it Could Be Good News for Processing)()

  • Nat

    Peter: Csound is doing all the audio. Python does all the GUI/Music generation/Logic. The nice thing about this approach is that Python is a very easy/fast language to program in. By using a library like Csound, we get all the power (and speed) of C but the ease of use of Python to call our Csound code. The other nice thing is that it is quite easy to extend Python with C/C++ code, so if something is too slow in Python, we can code that small part in C and call it from our Python code (similar to coding a C object for Max and using it in a patch) The same paradigm could be used for video by using a library like OpenGL (which already works with Python)

  • Fintain

    Java's like communism, looks good on paper but never works in the real world 🙂

  • Nat: I'll definitely have to check out more of what you're doing — I agree this could be a good approach. And it might bear examination for the Java world, too.

    The other possibility I think is interesting is the possibility of synthesis in pure Java. Unfortunately, I think Java the language has gotten a poor rap because of the capabilities of Java the platform as most people know it (and a lot of people are basing their impressions on old versions of the platform, making it worse). It's certainly possible to write an all-new synthesis library in pure Java. That's not to take away from the efforts with Csound, at all; on the contrary, Csound's longevity demonstrates the value in taking the long view when it comes to these kinds of tools. So I'm personally interested in what sort of form a next-generation synthesis library of this type might take. But certainly, in the meantime, it's absolutely possible to incorporate C/C++ code in Java via JNI; very popular with video in particular.

    And, again, it's worth supporting people's language choice. If I were suggesting Java in the exclusion of other things, well, then that would be a little more Communist. 🙂 And that's all the more reason to give Java a stronger base on the Mac.

  • Nat

    I think it might be a good thing if sun develops it's own runtime for the mac, like it did with Windows a few years back. The Python Cocoa bindings are quite interesting. We made TamTam using GTK and unfortunately GTK is a pain in OSX. Could be nice to make a Cocoa port some day. WxWidgets is worth investigating also since it's one of the only truly cross-platform GUI toolkit. (Mozilla is another nice one) though I keep hearing bad things about WxWidgets. I'm pretty sure the future is bright 🙂

  • Nat, I should add — there’s talk in Javaland about trying to get OpenJDK on the OLPC. There is now unencumbered code for JavaSound, and it runs very well. Don’t know the status of that discussion, and clearly your project made the choices that were best for that — guess my point is, the future for genuine open source development is looking brighter all the time.

    And, ahem, there’s no reason the Mac shouldn’t benefit in every way possible from what’s happening with that open source development. Whatever people want to argue about Apple, the Mac user base has a long history of embracing new software on both the proprietary and open source side. So, yes, good to see Python hooking into Cocoa, sad to see Java again getting the short end of the stick, there has to be a way to improve the situation for everybody on the Mac and Apple doesn’t have to be the only company involved.

  • busoni


    i recently had the chance to play around with an OLPC for an hour and while the overall software concept and design was impressive, the starting and also closing process of applications was extremely slow. it takes minutes (at least it felt like that, it may actually have been only 30 seconds) to switch between programs – way to slow for fluid operation. the apps themselves are not exactly slow but not too resonsive either. it was quite surprising to see tamtam was capable of relatively complex operations once everything was loaded, giving a hint that it's not the hardware that's underpowered..

    i was told the lousy GUI performance is due to the use of python and that this is the price you pay for having well readable and easy to modify code. i think it's a bad decision to sacrify performance for programming convenience. the project would probably be better off with a fast GUI written in C, there could still be a python sandbox for user experiments.


    java may not be the best for multimedia in general, but it is certainly the best platform for audio within the browser. javascript, flash and others have very limited audio functions, java is the only one which can stream audio – the base for any serious audio app such as synths and sequencers.

  • jah

    Some years ago I tried coding audio stuff in Java on my WinXP machine but I found JavaSound to be horrible. I ended up doing off-line processing cause I could not attain low latency. Then I've used jvstwrapper to build a vst plugin which is all right but all in all, Peter, is Java really such a good platform for realtime applications like audio? I must admit I havent tried Processing that much.

  • @Decaffeinated: my point re: "pure Java" is just that you could code synthesis in Java, not C. We need a different term. "Puresque"? "More Java-y?"

    And yes, I was even going to point out the possible use of Python, Lua, etc., in this way. There's nothing stopping you from having a Lua-scripted, Csound-based synthesis engine. But I also think it's clear that the Java platform has richness in terms of development tools, class libraries, third-party libraries, integration, etc. that's not marketing hype. Now, some people *hate* the result — and sometimes the result isn't the right tool for the job. So that's why it's good to have choices.

    @busoni: may be time to point out that Java and Python implementations currently in wide use are *not* interpreted; they run as native, compiled code. I'm not as familiar with Python benchmarks, but I do know that Java can theoretically run as fast or faster than languages like C and C++. Before I start sounding like the Java marketing, the important caveat is that very often it *doesn't* in practice, and that's where we get into issues with the Garbage Collector, and in other cases, just issues of the aforementioned platform code not running very well.

    However, it's worth saying that the latter of those impacts code in other languages. Optimizing performance is never something that happens automatically.

    Anyway, I don't think the "it must be Java" mythos is shackling the development world nearly as much as the "Java is slow", "Python is weak", "no one uses xx", "it's impossible to do cross-platform development", and "I don't care that this is running so slow" mythos. 🙂

    Cross-platform development is tough, it's true, but it is possible to do speedy, multimedia development and make it work cross-platform by going lightweight and avoiding platform-specific tools, as Nat's team did with Python/Csound, and as I think it'll be increasingly possible to do with Java.

  • Right, but again — Java, Python run native. So it's not the lack of bytecode that's making things slow. And launch time may be a different issue altogether.

  • Fintain

    Is anyone aware of JUCE, the C++ framework for developing cross platform audio applications?

  • Yeah, JUCE is cool … see also OpenFrameworks for C++, not necessarily for full-blown apps but as something for artists. It is interesting to me that these were both inspired by Java projects, which says the ideas in Java have been right and something's lacking in execution.

  • Nat

    Just to clarify things, Python does not run "Native" Meaning it doesn't run at the same speed as C for sure. The PYC files are compiled, but only in order to make the interpreter parse the file faster. The C functions that python calls run native, obviously.

    Regarding the OLPC vs normal PC speed issue, to give an idea, TamTam takes 2-3 seconds to load on my MacBook (under Parallels) but takes 30-45 seconds to load on the XO. What needs to be taken into account is that TamTam is a very rich applications in terms of the GUI. We use raster images with transparency and do a lot of custom drawings. I doubt that the GUI of Pocket PC applications are as complex (I have one myself and the GUI is very basic in general).

    So basically if you ask me, was using an interpreted language to create full GUI apps a good idea 10 years ago ? No. Is it now, totally.

  • Hmmm… my sense is, for what it's worth, it is possible to get around some of those performance bottlenecks with Java. It's not hard to imagine full-blown Java apps running on mobile devices in the near future. But I haven't played enough with Tam Tam / Python to know for sure. And I know Python works a little differently from Java in terms of compiling… I think the gulf between real-world and theoretical Java performance is interesting, because it demonstrates just how much you can screw up performance in the real world, not as a language issue (Java apps do run nearly native, if on a virtual machine) as an issue of all this other gunk we layer on top and the way it's implemented.

  • @jah: JavaSound was substantially recoded by Florian Bomers, possibly *after* you worked with JavaSound.

    There's really quite a lot more work to be done, but I also think it's a) possible to do some very interesting stuff now and b) already some concrete progress on getting it further and c) Java is further along than some of the alternatives that aren't C/C++. 😉

    For synthesis alone, Java is a long way from making sense. But as one platform for integrating other features, like 3D, networking, etc., it gets more interesting. There's never going to be one tool for everything, anyway. That'd *be* C++, except that it can be really painful for certain kinds of development, especially with individuals / hobbyists / students, who I think are important, if often-overlooked.

  • busoni

    "So basically if you ask me, was using an interpreted language to create full GUI apps a good idea 10 years ago ? No. Is it now, totally."

    performance-wise, the OLPC is much like a 10 years old PC. is it a good idea to use an interpreted language to create apps for it? is it the right place for transparency and a lot of custom drawings? couldn't fresh ideas for educative and entertaining programs be implemented with the basic GUI type that can be found in most mobile and PDA apps?

  • Nat

    busoni: probably, but that was not my call 😉

  • Nat

    busoni: while it is true programs on the OLPC aren’t super fast, most of the applications are still undergoing optimization phases and it’s getting speedier every day. The fact is, if all the programs were written in C, we wouldn’t be there today for sure. Also, if you run the the OLPC Window manager and applications on a modern PC, you won’t notice the slowdowns, making it less of an issue for modern machines.

  • Decaffinated in Detroit

    Nat — wxWidgets is quite awesome, especially if you are stuck on Windows/OSX and don’t have a nice API like GTK. And it is much much more tolerable to use than Swing IMHO.

    @busoni — “i was told the lousy GUI performance is due to the use of python and that this is the price you pay for having well readable and easy to modify code.” You were told incorrectly 🙂 wx or GTK python GUI apps are just as fast as any java app can be. Look at many of the config tools in Fedora, for instance. There are also a number of excellent examples of commercial game apps being powered by Python. Further, check out the Lua integration in multimedia-heavy Adobe Lightroom. All of these are powerful dynamic languages, and also easy to read/develop 🙂

    The aforementioned “Pure Java” thing really does not really exist, they are all reliant on class libraries that ship with the VM, of course written in Native code. This is true of pretty much any non-C/C++ language/runtime out there, and there is of course nothing wrong with that. However, “Pure Java” needs to be remembered as a marketing term. If the default class library does start to ship with better tools around things like MIDI and OSC, that’s great though.

    Development doesn’t come for free. “Write once, test everywhere” is true in Java .. and it is true everywhere else as well. The differences in bugs/behaviors between VMs can be quite substantial — often just as hard as porting your favorite other language or C app.

    “and real-time Java has already been demonstrated with terrific audio performance”. This is true. I’ve seen it demo’ed, even. However it should be noted that Realtime Java is primarily there to address problems in the Java garbage collector and also requires a realtime kernel. If you are running a realtime kernel, you can get those benefits using straight-up regular C (or anything else), without needing a special programming language. The main problem is just in making the GC run more often, not less, so things are predictable. The realtime kernels are also several versions back and it’s going to take a while to get that jumpstarted.

    Anyhow, I would completely agree that having more options out there is a good thing, but just wanted to point out the “if you want cross platform, it must be java” mythos is shackling the development industry and limiting opportunity. We don’t want to limit kids from hacking things up in something like Python/CSound/etc because we’ve been telling them the same Sun marketing terms again and again.

  • busoni

    “You were told incorrectly 🙂 wx or GTK python GUI apps are just as fast as any java app can be.”
    i wasn’t comparing it to java but native c, i’m sorry for getting a little off topic here. on a modern computer performance is certainly not so much an issue and one can afford the luxory of interpreted languages (though you still often can feel the difference and you can easily tell wether an app is native or java), but on the OLPC it is killing the whole experience – at least on that not yet completely optimized system i played with.
    433 mhz is not necessarily underpowered, my pocker PC runs at about the same speed and can open/close apps in less than a second. a similar speed should be possible on the OLPC too.

  • One other note on Python: I’m seeing from those who know that effort on Mac that both Python and Rails were efforts initiated outside Apple with basic Apple support. And, ironically, that’s probably a better model for Java in the future than this Apple-does-everything approach. Apple either doesn’t have or doesn’t want to use the resources neessary for that.

    And I’d say the success of Rails and Python demonstrates the importance of developers getting to choose the tools that make sense for them.

  • busoni

    i didn’t intend to say “python is slow”, i just saw that the OLPC prototype i tried was terribly slow.
    wether interpreted or not, there seems to be a lot of overhead in the current implementation, resulting in a hardly usable system. i understand that it’s maybe just too complicated to write everything in native/lowlevel code and that the whole design is much better understandable and easier to extend with python. but again, it’s just not fun to work with a system where closing a program and starting another one takes one minute.

  • Having SUN do the MAC OS X Java Vm makes a lot of sense now that Leopard is a Certified UNIX. This should make it easier for SUN to use the Solaris VM on Mac OS X.

    Visit here for more info …