But still, I don't see the advantage of targeting the Java VM, unless you want to write slow and resource hungry desktop apps with a non-native/Swing-Look & Feel (just think Netbeans here). Java still sucks for desktop apps; it's a server platform and won't grow out of that niche anymore.
That might have been true years ago, but it's certainly not the case anymore. JIT compiled Java programs run fast enough, especially on modern hardware, to execute at acceptable speeds.
One of my favorite IDEs is written in Java.
But the real concern here is games, right?
look here...
http://www.youtube.com/watch?v=at_4jBuwJ28
here...
http://youtube.com/watch?v=VOUpzzo5ykM&feature=related
or if you're interested in 2D, here...
http://www.groovyrobot.com/
and there are more demos out there if you are curious enough to search...
These examples are easily on par with something that could be created today with BlitzMax and have roughly the same dependencies (OpenGL, OpenAL, etc). If you could write those in Blitz, and have them target the Java compiler, you've arguably hit a large number of platforms above those that Blitz currently supports (including 64-bit, and mobile--though that would need some tweaking) At the same time, it puts the burden of native-code compiler support outside of BRL. If it went a step further to spit out .Net code, support could extend to Xbox, DirectX9/10 on windows and Zune. On top of that, the user wouldn't have to learn C# or Java to do it.
Java's interpretted origins have given it a bad rep. What many fail to realize is that JIT applications (both in java and .net) haven't been interpretted for years (.net never has been), and are executed as native code at runtime. The major difference is that it's compiled on the fly, and the code is usually optimized and scales to the state of the machine it's executed on. No pre-generated native code is going to ever be able to produce more or less code to make an application run efficiently (well, not without bloating the code with all the possible execution cases, anyway).
No - BlitzMax applications should be able to run by themselves with little or no framework other than the OS/Graphics API.
And why is that? I can't think of a single good reason in 2008 why this should be a requirement.
BlitzMax's module system itself is a framework that abstracts away from the underlying operating system. The only difference is that the modules get distributed with the app on an as-needed basis. While there is some benefits to this, you do distribute copies of shared libraries over and over. It would sort of be akin to shipping internet explorer with every document you create. The frameworks should be looked at in the same light (and already have by those that are behind the technology):
Just like IE, .Net is pre-installed on Vista. Java is pre-installed on linux and MacOS. Most mobile phones include Java (rumor has it, the next iPhone will have it as well. Android OS phones will definitely have it) Worrying about pre-requisites is a mindset that attempts to sympathize with a dying demographic. Is it a concern now? Sure, to a minor extent. But it's a concern that shrinks daily.
And there are ways of silently embedding the java compiler into your application in such a way that only your application will utilize it.
Besides, one could argue that getting the latest OpenGL driver for your PC's video configuration is usually magnitudes harder than getting the latest JVM or .Net framework. Your installer can tell your clients where they need to go and possibly even automate the process.