Re: AW: Harmony could be a world beater with the right strategy, not rot in the attic!

[ch...@k-embedded-java.com]

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

Re: AW: Harmony could be a world beater with the right strategy, not rot in the attic!

[Paul Anderson <p_...@volny.cz>]

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.