Weekly Edition
Return to the Press page
| |||||||||||||
|
| |||||||||||||
Dalvik: how Google routed around Sun's IP-based licensing restrictions on Java ME (Betaversion)
The Betaversion blog has an interesting discussion on Dalvik, the not-a-Java-VM which will run on Google's Android platform. "So, Android uses the syntax of the Java platform (the Java 'language', if you wish, which is enough to make java programmers feel at home and IDEs to support the editing smoothly) and the java SE class library but not the Java bytecode or the Java virtual machine to execute it on the phone (and, note, Android's implementation of the Java SE class library is, indeed, Apache Harmony's!)"
(Log in to post comments)
Can it be ported back to non-phone devices? Posted Nov 13, 2007 17:04 UTC (Tue) by epa (subscriber, #39769) [Link] If I understand the article correctly, Google have developed and released a better Java than Java. It's source-compatible with existing Java programs. It isn't bytecode-compatible, but who cares about that anyway? Any free program will have source available and most non-free programs are only 'certified' for a particular JVM, which they probably include with them. So, if Dalvik is any good, why not port it to desktop Linux distributions and adopt it as the standard Java toolchain? Now that the link between Java source and Java bytecode has definitely been broken (it was pretty weak before, with things like gcj), it might be worth adopting RMS's naming convention of calling the language java with a small J.
Can it be ported back to non-phone devices? Posted Nov 13, 2007 17:22 UTC (Tue) by daney (subscriber, #24551) [Link] There are several free JVMs available that are not controlled by Sun. I don't see what the upside is to creating something that is not compatible at the bytecode level. There is a lot of code out there that generates/manipulates things at the bytecode level. Being intentionally incompatible for no technical reason makes me think of the past actions of a large software company in Redmond...
A technical reason Posted Nov 13, 2007 17:29 UTC (Tue) by szoth (subscriber, #14825) [Link] It sounds like they are claiming that they have found a way to reduce memory use by changing the byte-code format. So I think they might have had a technical reason. I felt like the article was trying to say that by changing the byte-code format they had also found some kind of loophole to suns licensing. But I don't see how that could be.
Mamory is not the main reason, actually Posted Nov 13, 2007 21:48 UTC (Tue) by khim (guest, #9252) [Link] If you'll dig in Android SDK somewhat you'll find that it's using quite unusual approach to java: it loads and unloads whole applications with full java machine. Java machine starts slowly. No exceptions. And it loads classes slowly. So yes, they needed this streamlined format for technical reasons, not political ones. Of course it's always possible that political reasons played some role, but I don't think it was such a big role... P.S. BTW this approach makes lack of C/C++ support so much more suspicious: if they isolate all applications at the linux kernel level and not at java classloader level then why they refuse to support C/C++ ? It should be trivial...
Mamory is not the main reason, actually Posted Nov 13, 2007 23:45 UTC (Tue) by drag (subscriber, #31333) [Link] They probably refuse to support C/C++ because those programs are not portable on a binary-only code level. They are portable on a source code level, but not binaries. Since it's obvious that they want to allow for easy packaging and compatability between different architectures then it makes sense to go with Java, since Java can be portable across different cpus on the byte-code level and be able to keep the source code private. They are taking the web-thought approach of using Linux and open source as a base for launching rich proprietary applications. This is the classic Google approach and doesn't seem to be anything new to me. This may seem a negative at first blush if your a Free Software fan.. but if you think about it it's not so bad. This is the first time in history when the the modern approach of FLOSS software (as opposed to classic open source being used as research like early BSD and TCP) versus Microsoft/Wintel-style proprietary applications being able to compete with each other on a equal playing feild. (that is if this Android thing takes off) It's a new platform, a new approach at making highly human oriented mobile computing and both sides are starting off with a decent history, similar tools, open platform. If everything works out for Google and Android it can be a watershed momement in the history of computer science. Can Free software ideal work out and will it be attractive to the average person? Or will the capital that proprietary software can gather quickly be required for creating the innovative programs people desire and need? Android can potentially provide a platform for learning this answer in the real world.
Can it be ported back to non-phone devices? Posted Nov 13, 2007 17:30 UTC (Tue) by clugstj (subscriber, #4020) [Link] Please read the article. The incompatibility is not for a technical reason, it is for a legal reason. It allows them to make something that looks like Java ME, but isn't controlled by Sun.
Can it be ported back to non-phone devices? Posted Nov 13, 2007 17:34 UTC (Tue) by daney (subscriber, #24551) [Link] I did read the article. I just think the stated reason for the imcompatiblilty is bogus.
Can it be ported back to non-phone devices? Posted Nov 13, 2007 18:15 UTC (Tue) by sayler (guest, #3164) [Link] Or at least not the "only" reason -- or perhaps a happy side-effect..
Can it be ported back to non-phone devices? Posted Nov 14, 2007 9:09 UTC (Wed) by massimiliano (subscriber, #3048) [Link] Well, I've been told by a friend that works on JVMs at Nokia that the technical choices made in Dalvik are really important (and smart). For instance, the Dalvik file format allows direct execution mapping the file into memory (think mmap), without the need to create a truckload of data structures just to be able to load the file. Compare this with the Java "jar" and "class" formats, and think what it means for startup time... Of course the "political" reasons apply as well, but strictly speaking they are more economical (avoid licensing fees) than political, so even in this sense the choice seems very pragmatic.
Can it be ported back to non-phone devices? Posted Nov 25, 2007 2:01 UTC (Sun) by vonbrand (subscriber, #4458) [Link] I saw a comment somewhere to the effect that Java bytecode seemed designed to be impossible to interpret efficiently on "normal" hardware.
Dalvik: how Google routed around Sun's IP-based licensing restrictions on Java ME (Betaversion) Posted Nov 13, 2007 17:46 UTC (Tue) by ofeeley (subscriber, #36105) [Link] Sun have been pushing JavaSE over JavaME for exactly these sorts of applications though. http://www.artima.com/forums/flat.jsp?forum=276&threa...
Non-JVM VM Posted Nov 13, 2007 20:50 UTC (Tue) by ncm (subscriber, #165) [Link] The Java VM is renowned for its designers having chosen, in seemingly every case, the alternative more resistant to optimization. One not bound by those choices could produce a VM designed specifically to feed an optimizing code generator. (Indeed, MS's CLR is said to be implementable only that way, but otherwise annoyingly similar to JVM.) It would be most unfortunate if the VM were useful only for executing code compiled from Java. There are much more powerful languages.
Non-JVM VM Posted Nov 14, 2007 1:12 UTC (Wed) by captrb (subscriber, #2291) [Link] It sounds like the Dalvik compiler operates on Java bytecode, not the Java language, so I would assume that any language that can use Android's class library and can be compiled into JVM bytecode will be supported on this platform.
Non-JVM VM Posted Nov 14, 2007 2:36 UTC (Wed) by ncm (subscriber, #165) [Link] Java source gets compiled to ".dex" files by a program called "dx". The Davlik interpreter is "register-based", unlike JVM, which is stack-based, thus fundamentally incompatible. Therefore, it's possible, although far from certain, that it can execute programs that would be inexpressible in JVM bytecodes. All interesting languages are inexpressible in JVM bytecodes (except in the trivial sense that one could write an interpreter in Java). A Java bytecode -> .dex compiler might be possible, but that is also far from certain, depending on details of library dependencies.
Non-JVM VM Posted Nov 14, 2007 3:13 UTC (Wed) by ajross (subscriber, #4563) [Link] Register machines and stack machines are equivalent and turing-complete. There is no difference in expressiveness between the architectures. Register designs are more popular because they're more amenable to optimization. It's easier to generate code to store a temporary that needs to be used more than once in a register than it is to arrange the stack so it's at the top at the right time.
Non-JVM VM Posted Nov 14, 2007 4:22 UTC (Wed) by ncm (subscriber, #165) [Link] Obviously. But a design incompatible with JVM may also implement instructions that JVM doesn't. As an example, CLR implements the tail-call optimization. Turing-completeness is meaningless at this level. (If you insist on nitpicking, I will point out that nobody has ever implemented a Turing-complete execution environment, and nobody ever will.)
Non-JVM VM Posted Nov 14, 2007 2:42 UTC (Wed) by ncm (subscriber, #165) [Link] Oops, the "update" says that in fact "dx" does translate JVM bytecode files to ".dex" files. The rest of my comment stands. Apparently details of the Davlik VM remain secret.
Not even Sun believes in a "one true" Java VM Posted Nov 14, 2007 8:15 UTC (Wed) by jem (subscriber, #24231) [Link] A side remark: Even Sun has more than one Java VM. In addition to the standard VM Sun has specified the Java Card VM for use in smart cards. This VM is a subset of the "real" Java VM, with incompatible encodings for the instructions the two VMs have in common. The Java Card development environment takes the same path as Android: the Java source code is first compiled to class files using a regular Java compiler and the class file byte code is then converted to Java Card byte code.
|
|
||||||||||||