Hi Chris, > Using a different bytecode imposes an extra step > in the build chain If I understand you correctly, this would be true only in the absence of a native compiler. > bytecode engineering, > aspect-oriented programming and highly dynamic or > interactive languages. 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. Indeed, a lot of work would be needed to get these working on a new VM, but I think the interest would be there (Apache people are too modest!). Also, where Dalvik seems to have inherent problems with such languages, Harmony may prove more amenable.
> 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. I don't think it would matter: bytecode conversion might simply be a useful alternative to recompilation for some profiles of application. > > 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. > Vala is very C#-like, for example, but I haven't heard any resulting worries about it. If just being able to compile and run Java-syntax programs would be a problem, other VM languages could be used to build applications. Then, as I mentioned, it would be a question of having a suitable subset of Java or a newly Apache-defined set of class libraries to support those languages' runtimes. Surely being a VM would not in itself bring patent problems, especially if an open bytecode standard is used - and the Harmony class libraries and VM are clean room implementations. Possible patent problems might arise because of implementations of individual components, but that would be no more of a risk than for any software (i.e. not specific to Java's problems), and easily addressed on the level of components - not a threat to the VM as a whole. Guaranteeing the Java interfaces that Scala exposes for different profiles of VM would be a problem for the Scala runtime implementers, the same as for any other VM language. This would need to be addressed when deciding standard profiles of the VM's runtime - but mechanisms like OSGi allows precise definition of dependencies. And it seems Scala already runs on Dalvik, though slowly? 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. Agreed - why not look at that as a subsequent step - use the Harmony components to build a next generation VM? But for now at least Dalvik bytecode has a well-studied mapping from JVM bytecode and is widespread. Also, Harmony's JVM roots mean that the project can draw on plenty of industry experience with performance of JVM's.
