Thanks to ‘_aa_‘ for this comment:

I beg to differ. Java is perfectly capable of handling all aspects of digital music production. Because it runs in a virtual machine, load times can be increased as the virtual machine is loaded, but actual application performance is no different than C or any other byte compiled language. If all the other applications for Android are written in Java, then the virtual machine will already be resident in memory and load times will be indistinguishable from any other language.

Long story short. Performance is not an issue for Java.

I would point to JSyn ( as an example of real-time audio synthesis in a purely Java based environment.

I’m certain processor specific modifications will be required, but it will not be an insurmountable challenge to modify JSyn, or develop a new real-time audio synthesis API for Android. All manner of other music applications already exist in Java form.

Google is right to embrace Java. Plus Android is built on linux, so there’s no reason C code won’t execute on it, just as there’s no reason for there to not be a JavaVM for the iPhone, but Apple is blocking Sun from implementing it.

I don’t know much about Java to be honest, but this does sound interesting. I shall have to look into it in more depth. In the past I’ve tried mobile processing, but haven’t done anything with it for a while.

I know there’s been a lot of talk about a Sun Microsystems JVM for iPhone, but that’s gone quiet. Also, the IBM Micro environment for Palm OS is no longer available. As for Windows Mobile, I don’t know about a JVM for that platform.

So, if we can access useful JVMs for a platform, then maybe Java could be a useful and simple language for mobile music.


  1. <>but actual application performance is no different than C or any other byte compiled language<>I don’t believe this is true (yet) and also C is not a byte compiled language! C, specially on embedded devices, is still a lot faster than java, as it compiles straight to assembler instructions and doesn’t need any VM to run. I do believe though that with better and multi-core cpu’s in the future, java performance will eventually surpass statically compiled C because of “late-optimization” that can be done at run time. I don’t think it’s quite there yet, so C is still the preferred choice for any kind of audio programming.

  2. JSyn actually uses native ‘C’ code to do the synthesis. That is because it was originally written in 1997 when Java was slow and there was no other way to get high fidelity audio I/O. But now the hot-spot Java optimizers are very good and give performance comparable to ‘C’ on desktops. So I am hoping to rewrite the JSyn engine in pure Java for its many advantages. Using Java will allow composer/users to easily extend the unit generator library with subclasses and make development faster and easier.Note: Florian Bomers developed a very high performance synthesis engine written in pure Java. He achieved very low latency using a “real-time” JVM. See: < HREF="" REL="nofollow">Metronome.Harmonicon<>

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.