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: roadmap suggestion
Date Thu, 23 Dec 2010 03:14:03 GMT
Hi Chris,
Regarding your points:
1) I presume that restrictions on how Dalvik is used within Android
would not necessarily apply to another VM implementing Dalvik
bytecode. Dalvik/Android needed to be a standard environment and to
make optimizations for immediate performant mobile use. Harmony
*could* provide similar API's to Android's for application
developers as one deployment profile, but it could also provide
other profiles e.g. for  non-Java language runtimes. Also, its
optimizations need not follow Dalvik's.

2) The patent infringements you link to (thanks!) relate to Dalvik,
which implements its own bytecode. So they represent the objections
Oracle has to a (non-OpenJDK-based) VM running Java using non-Java
bytecode. Apache would always need to make sure that similar
objections would not apply to Harmony's components, but
infringements are no more likely than with any software, and
problems can be tackled by adjusting component implementations.

But Oracle could have a much stronger, as yet unknown, objection
towards a VM based on Java bytecode: such a risk couldn't be
addressed at component implementation level.

Expert opinion most welcome.

Sorry, I wasn't clear about the compiler, I was trying to say that
if the VM were changed in future to use different bytecode then
there could be two-step compilation (ecj then conversion) initially
for Java, then, later, direct compilation by 'ecj II' to bytecode x
- and at the same time there would be corresponding changes needed
to other VM languages and aspect weaving that create bytecode on the
fly. As I said, I think if Harmony had enough momentum then the
interest would be there to adapt the dynamic language runtimes for
it.

Of course, if there's no problem likely with using Java bytecode, so
much the better. In that case the existing Harmony can fulfil the
role of a multiple-language VM, with Apache- or Oracle-specified
Java as the reference language, and maybe a shiny new strongly-typed
language in future.

Paul


----- PŮVODNÍ ZPRÁVA -----
Od: chris.gray@k-embedded-java.com
Komu: dev@harmony.apache.org
Předmět: Re: roadmap suggestion
Datum: 22.12.2010 - 23:43:06

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


Mime
View raw message