Can it be ported back to non-phone devices? [LWN.net]

Can it be ported back to non-phone devices?

Posted Nov 13, 2007 17:04 UTC (Tue) by epa (subscriber, #39769)
Parent article: Dalvik: how Google routed around Sun's IP-based licensing restrictions on Java ME (Betaversion)

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.

(Log in to post comments)

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 (subscriber, #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 (subscriber, #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.