Hi Paul, I don't want to pour cold water on your idea but I would like to point out some counter-arguments.
> I'm thinking of a VM that would reuse Java's syntax (as Dalvik > does), but would not be tied to being 'Java' in the TCK/OpenJDK > sense. It would reuse de facto standard bytecodes (i.e. Dalvik's) > for 'run anywhere'. Porting of apps and frameworks might be done by > simple recompilation or by bytecode conversion as with > Java-to-Android for phone apps. Using a different bytecode imposes an extra step in the build chain, and perhaps more importantly raises an obstacle to bytecode engineering, especially at runtime. I see just these aspects becoming increasingly important in "beyond-Java" languages, particularly in the areas of aspect-oriented programming and highly dynamic or interactive languages. A lot of languages have already been developed with Java bytecode as a target, or have been ported to Java bytecode: http://en.wikipedia.org/wiki/List_of_JVM_languages I am not aware of such a list for Dalvik or other alternative virtual machines. Maybe if we build it they will come, but we are not going to be immediately able to plug into Scala and Fantom and all that stuff. Dalvik has been designed to run any program that can be written in Java (and even then there are some rough edges, ask the guys that ported an OSGi framework to Dalvik); I'm not sure that it's the case that any legitimate Java bytecode (i.e. anything which would survive verification) can be automatically translated to Dalvik. Maybe it can, but I would like to see a formal proof. > The sword of Damocles of patents would not then hang over the VM, This sword hangs over every line of code that has been written in the last 30+ years and every line of code that will be written in the foreseeable future, and Dalvik is no exception. When Dalvik was first announced I didn't buy the argument that Google would be able to circumvent all patent issues just by using a different VM and not calling it Java. I still don't. > Would this be feasible for Harmony as an alternative to a JVM > release or mouldering exile in the attic? Technically it is feasible, but I don't really see what problem it solves. For me it would be more interesting to come up with a minimal, stable set of Java class libraries which could be relied upon by JVM-based implementations of non-Java languages. Scala for example exposes underlying Java libraries which is fine except that the underlying JRE could be anywhere in the range 5 <= n < 9 if you see what I mean. I think that the developers of these languages would be much happier with the Apache way of life than with the JCP. Of course I'm interested in other VM instruction sets too, the JVM is very far from being the Last Word. But then I'm not sure that Java or JVM compatibility is a good starting point, it would be better to look at a more modern language design and see what kind of VM support it really needs. Kind regards Chris Gray
