<div>I agree with the Qt option, as it clearly produces some nice & performant music applications. But you're still programming in C++ which is tedious because of memory management; also "hard realtime" often precludes the use of Garbage collectors. Of course Java has RT garbage collectors available: <a href="http://java.sun.com/developer/technicalArticles/Programming/rt_pt2/" target="_blank">http://java.sun.com/developer/technicalArticles/Programming/rt_pt2/</a> although some may find "soft realtime" garbage collection as provided by the new G1 garbage collector sufficient: <a href="http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf">http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf</a> ... see also: <a href="http://blog.headius.com/2009/01/my-favorite-hotspot-jvm-flags.html">http://blog.headius.com/2009/01/my-favorite-hotspot-jvm-flags.html</a></div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><meta http-equiv="content-type" content="text/html; charset=utf-8">

<div><br></div><div>Lots of interesting Java-based music apps exist, with GUIs:</div><div><div><a href="http://jmusic.ci.qut.edu.au/applications.html" target="_blank">http://jmusic.ci.qut.edu.au/applications.html</a></div>
<div>
<a href="http://www.softsynth.com/links/java_music.html" target="_blank">http://www.softsynth.com/links/java_music.html</a></div>
</div><div><br></div>GUI application programming might be a little more forgiving in Java, although Java is a pain-in-the ass language, where you spend more time building and understanding scaffolding than you actually do programming... part of the scaffolding are the "design patterns" needed to work-around fundamental issues with primitive strongly typed languages like Java and C++ ( <a href="http://www.tiagoluchini.eu/2007/07/28/strategy-pattern-comparing-java-x-lisp/" target="_blank">http://www.tiagoluchini.eu/2007/07/28/strategy-pattern-comparing-java-x-lisp/</a> ). <div>
<br></div><div>The good thing is you don't need to use Java anymore, but can take advantage of its portability, security, advanced garbage-collection options,  and just-in-time compiler advances that may give it a performance advantage, these days.... But you don't have to program in Java, you write in <a href="http://groovy.codehaus.org/" target="_blank">http://groovy.codehaus.org/</a> or <a href="http://clojure.org" target="_blank">http://clojure.org</a> which means you can do really high-level things with just a few lines of groovy code ( <a href="http://lists.xwiki.org/pipermail/users/2009-August/016937.html" target="_blank">http://lists.xwiki.org/pipermail/users/2009-August/016937.html</a> ).</div>
<div>Fortunately, several million unfortunate souls have slogged through all the hard work and made a huge library of functionality for people to use, much of it open source. </div><div><div><br></div><div><a href="http://curious-attempt-bunny.blogspot.com/2009/01/simple-clojure-graphics-api.html">http://curious-attempt-bunny.blogspot.com/2009/01/simple-clojure-graphics-api.html</a> is a good example of the concision made possible by clojure...<br>
<div><br></div><div>Clojure may be of particular interest in realtime multiprocessor/multithreaded apps because of its high level., language-level support for concurrency and multithreaded programming ( <a href="http://clojure.org/concurrent_programming">http://clojure.org/concurrent_programming</a>  ) as well as potential support for Software Transactional Memory, which is analogous to garbage colleciton for threads ( <a href="http://www.stanford.edu/class/cs242/readings/TMvsGC.pdf">http://www.stanford.edu/class/cs242/readings/TMvsGC.pdf</a> </div>
<div><a href="http://java.ociweb.com/mark/stm/article.html">http://java.ociweb.com/mark/stm/article.html</a> ).<br><div><div><div><div><br></div><div>Niels<br><a href="http://nielsmayer.com" target="_blank">http://nielsmayer.com</a><br>


</div></div></div></div><div><br></div>
</div></div></div>