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

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

Many developers have shunned Mono and now Java is suffering similar
concerns.
Dalvik is improving but is not commonly available as a standalone
package independent from Android and without bare metal
optimizations.

There's a huge opportunity for a widely-ported VM that implements a
de facto standard open bytecode (e.g. Dalvik's), builds on
performance experience from JVM's, is Apache licensed (for community
trust), and can be used for running other languages such as Scala
and JRuby. An Apache-defined subset of Java class libraries, or even
an Apache-specified set with a test kit, would be enough to do that
- the VM would not need all the class libraries to be useful. In the
Linux world it might become popular on the desktop where Java never
did - Vala has brought gtk programming up-to-date, but Harmony could
succeed with qt etc. too.

An Apache-licensed modular universal VM with popular languages and
enough of a well-defined class library to base them on would be a
huge force - even better if it were OSGi-based. Could this be done
and would it attract developers? Why try to make Harmony 'Java' at
all? Forget the attic!

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.

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

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. 

Java developers' knowledge and IDE support would continue to be a
vital base, and a lot of developers would also code in other VM
language implementations on top of the class libraries, so Java's
syntax wouldn't be limiting. Stability and features would depend on
the Harmony team.

The sword of Damocles of patents would not then hang over the VM,
and the community would have freedom to take the VM forward in the
Dalvik spirit and escape the stagnation of the JVM. Apache has the
credibility and talent pool to do this and the nuts and bolts are
all there already. The relative priorities for VM porting would
depend on needs such as embedded/mobile, servers, etc.

I would love to see such a VM for server-side apps; and for
desktop/embedded Linux apps too if the performance and widget
bindings were good, and if there was VM support for languages like
JPython.

Would this be feasible for Harmony as an alternative to a JVM
release or mouldering exile in the attic?

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

[Volker Berlin <vo...@goebel-clan.de>]

Nice idea. But the core questions are:

Why Mono was shunned? My opinion:
* All my test have show that it is not compatible.
* There is no good IDE.

Why Java can be shunned in the future? My opinion:
* In every new Java update there are new bugs which need hacks in my application.
* The improvent is small.
* The interaction with a specific OS is very bad.

What are my dreams for a programming language.
* It must be platform independent for the main features. I want that my application run on many systemes. (+Java; -Mono)
* There should have extentions for different platforms that I can use easy. (-Java, +Mono)
* It should be stable. Bug fixes should not produce new bugs. (-Java, Mono?)
* There should be a modern IDE with all the modern Features like easy debugging, refactoring, etc. (+Java, -Mono)
* A good syntax which prevent boiler plate code (-Java, +Mono)
* A continue development and improvment (-Java, +Mono)

If you see my dreams then you see the problem with your idea. If you create an own VM based on an own language(s) then
it requiered very many developers. Your new VM must have many advantages over the existing VMs. Else never will port
existing libraries/applications.

My two cents

Volker

> -----Ursprungliche Nachricht-----
> Von: Paul Anderson [mailto:p_j_anderson@volny.cz] 
> Gesendet: Donnerstag, 16. Dezember 2010 19:02
> An: dev@harmony.apache.org
> Betreff: Harmony could be a world beater with the right 
> strategy, not rot in the attic!
> 
> Many developers have shunned Mono and now Java is suffering similar
> concerns.
> Dalvik is improving but is not commonly available as a standalone
> package independent from Android and without bare metal
> optimizations.
> 
> There's a huge opportunity for a widely-ported VM that implements a
> de facto standard open bytecode (e.g. Dalvik's), builds on
> performance experience from JVM's, is Apache licensed (for community
> trust), and can be used for running other languages such as Scala
> and JRuby. An Apache-defined subset of Java class libraries, or even
> an Apache-specified set with a test kit, would be enough to do that
> - the VM would not need all the class libraries to be useful. In the
> Linux world it might become popular on the desktop where Java never
> did - Vala has brought gtk programming up-to-date, but Harmony could
> succeed with qt etc. too.
> 
> An Apache-licensed modular universal VM with popular languages and
> enough of a well-defined class library to base them on would be a
> huge force - even better if it were OSGi-based. Could this be done
> and would it attract developers? Why try to make Harmony 'Java' at
> all? Forget the attic!
>