«

The Android Builders Summit
<http://free-electrons.com/blog/abs-2011-videos/> had some interesting
presentations, in particular Karim Yaghmour’s delving into the internals of
Android, and Aleksander Gargenta’s “A Walk Through The Android Stack”.

From 48:00 onwards, Gargenta explains why Android uses the Dalvik VM instead
of the Java VM.

* Why not Java SE? Too bloated, not suitable for low-power applications.
* Why not Java ME? Too expensive, everything runs in one VM => lousy
security. And you don’t get the necessary hardware access.

Dalvik is purpose-built from the ground up; its .dex code is, even
uncompressed, slightly smaller than a compressed .jar file. This simplifies
class loading—a .apk file can be opened and mmap’d, and the code is ready
for execution. (This is why zipalign is so important when building an
Android app.)

Dalvik is also register-based, not stack based, for higher performance.

On Sun, 29 May 2011 12:48:48 +1200, Lawrence D'Oliveiro
<_zealand> wrote, quoted or indirectly quoted
someone who said :

>
>Dalvik is also register-based, not stack based, for higher performance.

I'll make some guesses.

Dalvik was designed solely for a family of CPUs with similar RAM.
Oracle Java wanted to run everywhere.

With Oracle Java, the licence forces users to provide the full
enchilada. I suspect with Dalvik they were able to prune it back just
to what they needed.

They are doing the old IBM lockin game. They don't want Android apps
running elsewhere or being easily ported there.
--
Roedy Green Canadian Mind Products
http://mindprod.com
How long did it take after the car was invented before owners understood
cars would not work unless you regularly changed the oil and the tires?
We have gone 33 years and still it is rare to uncover a user who
understands computers don't work without regular backups.

In message <>, Roedy Green wrote:

> They are doing the old IBM lockin game. They don't want Android apps
> running elsewhere or being easily ported there.

Android is already running on a bewildering variety of devices—e-book
readers, game console, media players, TVs, smartphones and tablets (of
course)—even a washing machine. There have been a number of devices that
dual-boot between Android and Windows; there is even a company looking at
implementing it as a stack running directly on top of Windows (good luck to
them).

There is no “lockin” anywhere. Android is being so wildly successful
precisely because it is so open and flexible. Google may not be keen on all
the things being done with it, but the beauty of it is it’s not their
decision.

On 5/28/2011 9:56 PM, Lawrence D'Oliveiro wrote:
> In message< >, Roedy Green wrote:
>
>> They are doing the old IBM lockin game. They don't want Android apps
>> running elsewhere or being easily ported there.
>
> Android is already running on a bewildering variety of devices—e-book
> readers, game console, media players, TVs, smartphones and tablets (of
> course)—even a washing machine. There have been a number of devices that
> dual-boot between Android and Windows; there is even a company looking at
> implementing it as a stack running directly on top of Windows (good luck to
> them).
>
> There is no “lockin” anywhere. Android is being so wildly successful
> precisely because it is so open and flexible. Google may not be keen on all
> the things being done with it, but the beauty of it is it’s not their
> decision.

Hello;

I do not know anything about Andriod version of Java. But if one
writes an Andriod application, can one take the Java source code
and compile it with Java (the standard Java) and run it on say
window 7 or linux or the mac?

thanks
--Nasser

Nasser M. Abbasi wrote:
> I do not know anything about Andriod [sic] version of Java. But if one
> writes an Andriod [sic] application, can one take the Java source code
> and compile it with Java (the standard Java) and run it on say
> window 7 or linux [sic] or the mac [sic]?

Not unless one has the API ported to the other platforms. Even during
compilation Java requires that class references be satisfied, and of course
those libraries must be present to run the code.

Side note (that doesn't affect your question, really): there is more than one
"standard" Java. One assumes you mean Java SE, and further, a current version
thereof.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg

On 5/28/2011 9:28 PM, Roedy Green wrote:
> On Sun, 29 May 2011 12:48:48 +1200, Lawrence D'Oliveiro
> <_zealand> wrote, quoted or indirectly quoted
> someone who said :
>
>>
>> Dalvik is also register-based, not stack based, for higher performance.
>
> I'll make some guesses.
>
> Dalvik was designed solely for a family of CPUs with similar RAM.
> Oracle Java wanted to run everywhere.
>

well, it is possible, but register-based VMs are not necessarily
non-portable, just the performance argument is a bit weak, especially on
x86, since in both cases "register" and "stack" one generally ends up
having to map things to memory anyways.

likewise, many of my JITs will often map stack elements to registers in
many cases as well (when appropriate) so IMO the performance argument of
register VMs is a bit weak.

for a pure interpreter, it is a bit "who knows" and which is faster
ultimately comes down to a lot of micro-optimization and hand-waving.

my own experience has been that often the logic for dispatching to the
correct opcode itself becomes the main slowdown for an interpreter
(rather than messing with the stack), and that usually the way around
this is to have a number of "super opcodes" which include a sequence of
common smaller opcodes into themselves (such as combined
load+compare+jump opcodes, ...).


also, IME, register VMs are more of a pain to target than stack-machines
(and also often a little more complex). the result being that personally
I have usually ended up with stack machines.


> With Oracle Java, the licence forces users to provide the full
> enchilada. I suspect with Dalvik they were able to prune it back just
> to what they needed.
>

partly, yes.

they do omit a few parts from a standard JVM... such as the
classloader... (AFAIK, the "Class" and "ClassLoader" classes are mostly
just stubs, ...).


although they still use the Java language, which could itself be a
factor in a legal sense (the alternative would have been to develop
"some language X" which "just happens to look mostly like Java and is
largely source-compatible").


> They are doing the old IBM lockin game. They don't want Android apps
> running elsewhere or being easily ported there.

possible...

however, given that Android apps are still (language level) mostly plain
Java, it is not so strong of an argument portability-wise.

it is much like how C is generally regarded as portable, despite the
fact that binaries will not generally work between one type of system
and another.


a much bigger problem then is likely any Android-specific library
dependencies, and Java's lack of a mechanism similar to C's "ifdef"...

yes... ifdef is kind of nasty, and is used/needed a bit more than is
ideal, but is a decent part of C-style portability (rather than asking
for a more-or-less homogeneous environment).

then any classes/methods/... related to specific GUI APIs and similar
would appear and disappear as needed.



oh well, if it matters:
I have long since given up my attempts to "bastardize" the Java/JVM
architecture with more features in my own implementation, and have
instead opted mostly with using my own language/VM for a lot of this
(this itself is gets a bit hairy in the details).

after all, if I pile on piles of new features/... then it is not really
the same language anymore anyways, even if the core syntax/... was
mostly similar.

but, yes, it is partly sort of a "who cares" situation regarding my
case. yet another HLL will not effect much in the greater scheme of
things, probably the best it can really do is to serve my own uses, and
even then it is a bit trying with all the time that goes into debugging
and working on it, rather than it "just working".

also, my current language is technically a bit more closely related to
ActionScript than it is to Java...


or such...

On 5/29/2011 6:32 AM, Lew wrote:
> Nasser M. Abbasi wrote:
>> I do not know anything about Andriod [sic] version of Java. But if one
>> writes an Andriod [sic] application, can one take the Java source code
>> and compile it with Java (the standard Java) and run it on say
>> window 7 or linux [sic] or the mac [sic]?
>
> Not unless one has the API ported to the other platforms. Even during
> compilation Java requires that class references be satisfied, and of
> course those libraries must be present to run the code.
>
> Side note (that doesn't affect your question, really): there is more
> than one "standard" Java. One assumes you mean Java SE, and further, a
> current version thereof.
>

yep, there is always J2ME, and then one can define anything beyond this
as "extensions"...

granted, a "Java" which is basically just J2ME with everything else done
via proprietary APIs wouldn't likely appeal to most expecting Java SE
style functionality, even keeping the trademark intact.


"well, it has the Java 1.1 core language, and the packages java.lang and
parts of java.io and java.util..."

potential developer: "but what about AWT and Swing and these other APIs
I might want to use?"
response: "well, for these things you use our vastly improved
foo.gui.manager (it has Pointy/Clicky TM) and other custom APIs...".

at this point it would likely start to look a bit like someone trying
simply to use the Java trademark as a selling point.


or such...

In message <irtsqa$9ae$>, BGB wrote:

> ... register-based VMs are not necessarily non-portable, just the
> performance argument is a bit weak, especially on x86 ...

Which, interestingly, is not very popular for ultramobile devices.

> although they still use the Java language, which could itself be a
> factor in a legal sense ...

How come? Is the licence for the Sunacle JDK (which is what I use for
compiling programs) violated in any way?

In message <irtu02$bso$>, BGB wrote:

> ... there is always J2ME ...

Which is unsuited to modern ultramobile devices, as pointed out earlier.

> potential developer: "but what about AWT and Swing and these other APIs
> I might want to use?"
> response: "well, for these things you use our vastly improved
> foo.gui.manager (it has Pointy/Clicky TM) and other custom APIs...".
>
> at this point it would likely start to look a bit like someone trying
> simply to use the Java trademark as a selling point.

Which Google has been careful to avoid.

On 5/29/2011 5:44 PM, Lawrence D'Oliveiro wrote:
> In message<irtsqa$9ae$>, BGB wrote:
>
>> ... register-based VMs are not necessarily non-portable, just the
>> performance argument is a bit weak, especially on x86 ...
>
> Which, interestingly, is not very popular for ultramobile devices.
>

possibly, but I primarily develop on x86 systems, which have a few
relevant properties:
indirect addressing is nearly free;
memory in-cache performs nearly as fast as registers;
in 32 bit mode, there are only 8 usable GPRs, of which 2 or 3 are
generally needed by the CPU or ABI (ESP, EBP, and generally EBX on ELF
based targets).

now, maybe for RISC style targets things are faster, either with more
GPRs or slower memory access being a more major factor, but alas, I
haven't really used them much.


>> although they still use the Java language, which could itself be a
>> factor in a legal sense ...
>
> How come? Is the licence for the Sunacle JDK (which is what I use for
> compiling programs) violated in any way?
>

apparently, Sun/Oracle is fairly fussy about who uses their trademark
and when, and basically they went and sued Google, IIRC (?), for using
their trademark in an unliscensed and partial implementation, and for
infringing on their patents.

although, normally one could just make a nearly identical clone language
with a different name, an issue is that pretty much all the standard JDK
packages use the word 'java' as part of their name, meaning that to
completely escape the trademark issue, one would also have to rename the
packages, breaking compatibility.


this is also partly why the standards documents for JavaScript uses the
name ECMAScript instead, and many alternative implementations and
variants of the language (JScript, ActionScript, HaXe, ...) also have
different names.

my own BGBScript language itself is (loosely) a JavaScript variant.
although it started out as a more loosely related language, was later
brought much closer to JS, and more recently drifted a lot closer to
ActionScript and added a few more non-JS features (the most drastic
re-addition being optional C/Java/... style declarations, as opposed to
using the 'var' and 'function' keywords...).

side-note: my big effort to make a big/new/fancy Java-like language
(with lots more features, like structs and properties, ...) ended in me
mothballing it (due to having bigger concerns) and just shoving some of
its planned features (and syntax/semantics) onto my existing script
language and VM, creating a sort of hybrid...


all this is in contrast to the more cohesive identity, say, of C, where
there is a more solid core language, and generally lots of
implementations and implementation-specific extensions. or languages
like Scheme where although a common name and identity are used, general
compatibility between implementations is nearly non-existent...


or such...