harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Anderson" <p_j_ander...@volny.cz>
Subject Re: AW: Harmony could be a world beater with the right strategy, not rot in the attic!
Date Thu, 16 Dec 2010 23:30:27 GMT
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

> > 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

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

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.

View raw message