Hi Paul,
> Exactly.I suggested additionally that if it avoids patent problems,
alternative bytecode could be used instead (like Dalvik's, since it's
already widespread) as long as that doesn't block performant support of
non-Java languages on the VM - while reusing as much of Harmony's
existing guts as possible.
Well, at the risk of repeating myself: I suspect that switching to a
different bytecode (1) would raise an obstacle to migrating languages
which currently target the JVM to the proposed neo-Harmony and (2) would
not necessarily solve any patent problems.
1) Although application developers are flocking to the Android APIs, I
don't see language developers flocking to Dalvik - on the contrary, the
apparent restriction to Dalvik and the operating environment it expects
are often perceived as disadvantages of Android. Does anybody have a
different impression?
2) Of the seven patents which Oracle claims Google is infringing:
http://en.swpat.org/wiki/Oracle_v._Google_(2010,_USA)#The_patents
I don't see one which would be circumvented by using a different bytecode,
but SFAICS it is possible to build a JVM without infringing any of them.
The same goes for the patents which are explicitly mentioned in the JVM
spec - they relate to optimisations and not to the bytecode itself. Did I
miss something?
> [...]
> - In the short term, could Harmony be released as it is, certified only
for its ability to run the runtimes of a set of VM languages like Python
and Ruby? Its class library implementation is surely solid enough. The
bytecode output of the compiler could be changed later to match an
updated VM if needed, perhaps with a temporary intermediate step, after
the corresponding work on the language
> runtimes.
By "the compiler" do you mean the compiler of the non-Java language which
has the Harmony VM as target? Or do you mean that ecj should emit Dalvik
(or some other) bytecode?
Best regards
Chris
