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