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




Mime
View raw message