Android—Why Dalvik?

[Nasser M. Abbasi]

Not a chance. They’ve already tacitly given up on phones for now, but are
still making a big noise about tablets. Though I’ve yet to hear of any
significant design wins.

The only advantage to having x86 on a tablet is the ability to run Windows.
And nobody seems to care about that.

Thanks. But windows still run on, what, may be 9% of the PC's
in the world?

http://en.wikipedia.org/wiki/Microsoft_Windows

"As of October 2009, Windows had approximately 91% of the market share
of the client operating systems for usage on the Internet.[3][4][5] "

So, I do not think not caring about 90% of the market is a wise
thing to do?

ps. I myself use Linux and windows on the same computer, thanks
to VirtualPC. I have them both running, and use them both, as
each is good at different things.

--Nasser

 

[Lawrence D'Oliveiro]

Thanks. But windows still run on, what, may be 9% of the PC's
in the world?

Makes no difference.

 

[Lawrence D'Oliveiro]

You write Android apps in Java (with the exception of some low-level
code which is written in C; I understand that's mostly done for games).

I see a lot of portable software also done in C. For example, the Python and
other interpreters used in the Scripting Layer for Android
<http://code.google.com/p/android-scripting/> are largely unchanged C code
from their versions on other platforms.

 

[BGB]

But the J2ME spec is unsuited to ultramobile devices, as pointed out
earlier.

if you say it is "unsuitable" then it is sort of expected to say in
which ways it is unsuitable...

J2ME was designed for cell-phones and embedded devices. its likely main
drawback now, is that it would (just by itself) lack many of the J2SE
features.

but, that is why it would be a "starting point". one can add any
features if they are needed...

given J2ME is mostly a subset of J2SE, and so if J2ME wont work (due to
overhead or similar), J2SE sure-as-hell wont work.


one can still implement a good portion of J2SE as well if they want,
only the spec does not require them to do so, whereas J2SE conformance
would require providing an implementation for pretty much the entire
class library.

Android mostly implemented much of the J2SE featureset, rather than the
J2ME featureset, which is part of what caused controversy.


or, one can do like with Dalvik, and use a different bytecode or
similar, if they really want (although this does add the issue of either
needing to provide a custom compiler, or trans-compiling JBC to the
custom bytecode prior to distribution...). less effort though is to
stick with the standard bytecode though unless there is some strong
reason to do otherwise...

and, as for JBC (and the ".class" file format, ...) there are other
specs for this.


provided one doesn't do something which directly violates a spec, all is
well and good...

anything which works, works...

 

[Nasser M. Abbasi]

Makes no difference.

Ok thanks, that makes sense.

--Nasser

 

[BGB]

The issue is power consumption. Intel has been unable to drive down the
power usage of x86 chips to offer serious competition to ARM.

snipping statements, using them out of context, and responding with
answers which don't make sense in context, well, this doesn't really buy
too many points...

but, anyways, I mostly use x86, and mostly on desktop PC and laptop
environments. x86 does what x86 does on PCs...


and, as for the performance profiles, it doesn't matter whether or not
x86 competes well with ARM in this market, only their respective
performance characteristics WRT a particular style of VM implementation.

on x86, there is not a lot of sway either way.
for ARM, who knows?... I am not an expert on ARM.
my guess is it may matter a lot more if typical ARM chips result in,
say, a relatively higher cost of indirect addressing or memory access
compared with register access, coupled with a larger number of HW registers.

I was explicitly allowing for this.

I don’t recall any trademarks being at issue in that suit.

I remember reading something to this effect though.

Which is a separate issue.

from the stuff I read, both issues came up in the same suit.


I suspect a major possible interpretation:
Google did their own VM, and claimed to support Java with it;
they didn't do things the proper Sun/Oracle way, and properly license
the VM, and not just omit the parts they didn't want to bother supporting.

Oracle rage-faced... and tried to put the hammer down...


had Google not used the Java trademark though, it is likely that Oracle
would not have done anything, since it would have essentially been (in a
mindshare sense) a different and unrelated piece of VM technology.

basically, it is mostly built on Apache's code, rather than the
Sun/Oracle code, so copyright doesn't work. also, the VM is a different
piece of technology from the JVM.


the link then is Java, but really, what is Java?...
mostly, it is its name and trademark...

most things that make up the core language: the syntax, semantics, ...
are all fairly generic:
a fair amount descends from C and C++;
some of the rest is variations on the above.

compilers are not really all that difficult to write (in the greater
scheme of things...).


also the libraries, which are distinctive mostly due to their particular
organization and the use of the word 'java' in most of the package
names, but are not themselves novel...

a language which looked like Java syntax-wise, and had a similar set of
APIs, would not likely have drawn much attention.

but, instead, Google endorsed Java itself...
this was very possibly near the core of the issue...


had it been called, say, GoogleC, and looked something like:
import goolglec.util.*;

public class MyApp
{
public static void main(String[] args)
{
System.out.println("Hello\n");
}
}

maybe... people would have been like "hey... this sort of looks like
Java...", but this would likely have been the end of it...


law is a funny thing sometimes...

 

[BGB]

Not a chance. They’ve already tacitly given up on phones for now, but are
still making a big noise about tablets. Though I’ve yet to hear of any
significant design wins.

The only advantage to having x86 on a tablet is the ability to run
Windows.
And nobody seems to care about that.

Thanks. But windows still run on, what, may be 9% of the PC's
in the world?

http://en.wikipedia.org/wiki/Microsoft_Windows

"As of October 2009, Windows had approximately 91% of the market share
of the client operating systems for usage on the Internet.[3][4][5] "

So, I do not think not caring about 90% of the market is a wise
thing to do?

ps. I myself use Linux and windows on the same computer, thanks
to VirtualPC. I have them both running, and use them both, as
each is good at different things.

yeah...

mostly I use and develop for Windows on normal PCs on x86 and x86-64...

the big drawback of smartphones is that they cost about as much as a
desktop PC but only do a fraction as much, and I have a cheap phone
(probably runs ARM, costed $25, can't do crap with it much beyond using
it as a phone and doing text messages...).

I don't have the piles of money where I can justify spending $400 to
$600 on a phone...


otherwise, when "on the move I have a laptop and/or a netbook...". the
netbook, however, runs on an Intel Atom chip... the laptop is older, and
uses an AMD Mobile Sempron.

mostly the netbook is better for "quick and dirty" stuff (sitting
somewhere and wanting to fetch info on Wikipedia or check email), and
the laptop is better for "actually doing something".

the netbook runs Ubuntu, and the laptop runs Windows XP.


AFAICT, laptops still win out at this point, in terms of common use, vs
higher-end cell-phones...


also, there are mobile x86 chips not made by Intel, such as by VIA and
AMD and by several other companies, so Intel is not the sole player in
x86 land, or even a market leader by a large margin (AMD has a good deal
of standing in the desktop PC space).

VIA and AMD have more relative standing in mobile and embedded systems
(since I guess the Atom eats watts vs the VIA Nano...).

ARM and PowerPC are popular in embedded, but interestingly I don't own
any ARM systems I can actually develop for (since most are closed-system
consumer electronics...).



also...

Android can also run on x86 chips... it all depends on the specific
device it is running on. this basically means that developing C apps for
Android would require recompiling for different architectures, vs Dalvik
which can be run unmodified on multiple targets.

or such...

 

[Lawrence D'Oliveiro]

Ok thanks, that makes sense.

Not unless you remember that Microsoft has been trying to sell the things
for the last decade without success.

 

[Lawrence D'Oliveiro]

if you say it is "unsuitable" then it is sort of expected to say in
which ways it is unsuitable...

Already done. See the posting that started this thread.

 

[BGB]

I see a lot of portable software also done in C. For example, the Python and
other interpreters used in the Scripting Layer for Android
<http://code.google.com/p/android-scripting/> are largely unchanged C code
from their versions on other platforms.

yeah...

C source code generally doesn't need to change that much between one
target and another (after all, most variations in OS and architecture
can be trivially handled via #ifdef magic).

the main issue is mostly that of needing to be rebuilt for each OS and
CPU, since binary code is generally not portable between targets...

this is not a huge issue, but it is still annoying.

granted, it is interesting that this is more generally seen as an OS
issue than a language or technology issue...

"well, this is a Windows' app, of course it doesn't work on Mac or
Linux...", despite that all 3 versions will likely build from the same
source. granted, many projects are distributed in source-form, but this
has its own set of drawbacks (not everything is ideally distributed as
source code).


would be nice if compiling C to ByteCode and using a JIT at the target
site were a little more commonplace...

granted, yes, compiling C to a portable bytecode and remaining strictly
conforming with the ISO C standards itself poses a few problems, but
these can be fudged (C can work here, just some things need to be
"reinterpreted" slightly...). (as-imagined, the compiler would likely
look a bit strange if compared against a more traditional compiler, but
I don't feel like going into this at the moment...).

I don't expect C will go away either though, as it itself has a few of
its own sets of merits.


MS sort of did something half-assed with C++/CLI, but C++/CLI manages to
produce IL that is itself not terribly portable...

I also am left with a "sour taste" regarding .NET in general...

although, in many ways I like C# and .NET more in a purely technical
sense, most things going on with it are in general much less appealing
(.NET is unencumbered in roughly the same way that a Chia Pet is free to
roam about a tabletop...).


so, what will the future hold?...

 

[Lawrence D'Oliveiro]

snipping statements ...

*Sigh* I get this crap all the time from the clueless newbies. Let me
explain to you something about USENET: my postings are to record what I
said, not what you said. If I quote any part of you said, it is to give
some context for what I said, nothing more.

Rest assured if I reply to you I did read what you said, whether I quoted
it or not. If I was ignoring what you said, I wouldn’t even bother replying
to you.

 

[BGB]

Already done. See the posting that started this thread.

I looked, and these are not solid answers, in that no real basis is
given apart from plain assertions, and would if-anything, be taken as an
argument against some particular implementation, rather than against the
spec that exists (the spec for what the spec says), which is essentially
just an API reference for a list of classes which would need to be
provided by *an* implementation...

so, it doesn't hold water...

especially when, in this instance, it is typical that each implementer
provides their own implementation, in which case, none of those original
issues hold, as none are, in-fact, mandated by the spec.


one can infact assert Android to be a J2ME superset... because it
happens to implement these classes...

yes... it really does have the likes of the "java.lang", "java.io", and
"java.util" packages, and a good deal more as well...

 

[Lawrence D'Oliveiro]

if you say [J2ME] is "unsuitable" then it is sort of expected to say in
which ways it is unsuitable...

Already done. See the posting that started this thread.

I looked, and these are not solid answers, in that no real basis is
given apart from plain assertions ...

“Too expensive†— seems pretty straightforward to me. It’s either right or
wrong; to settle it, just let us know what the licensing cost for J2ME is.

“Everything runs in one VM => lousy security†— that’s pretty obvious, too.
If it isn’t clear to you, might I point out that, under Android, every app
runs under its own user ID? So you get the standard user privilege
separations provided by the Linux kernel.

 

[John B. Matthews]

But windows still run on, what, may be 9[0]% of the PC's in
the world?

http://en.wikipedia.org/wiki/Microsoft_Windows

"As of October 2009, Windows had approximately 91% of the market
share of the client operating systems for usage on the
Internet.[3][4][5]"

[/QUOTE]

Interestingly, [3][4][5] were examined in October 2009 to get the 91%
figure. The 2011 numbers have all fallen--some more, some less.

 

[Joshua Cranmer]

C source code generally doesn't need to change that much between one
target and another (after all, most variations in OS and architecture
can be trivially handled via #ifdef magic).

I laugh at anyone who thinks this. If you do anything with a GUI, file
access beyond "open this file and read/write it", networking,
multithreading, you WILL run into nontrivial portability issues. Heck,
even porting 32-bit code to a 64-bit target of an otherwise identical
system is often nontrivial for any decently sized project.

 

[BGB]

I laugh at anyone who thinks this. If you do anything with a GUI, file
access beyond "open this file and read/write it", networking,
multithreading, you WILL run into nontrivial portability issues. Heck,
even porting 32-bit code to a 64-bit target of an otherwise identical
system is often nontrivial for any decently sized project.

as noted, I said "trivially handled via ifdef magic...".


this means, generally:

#ifdef linux
Linux specific stuff...
#endif

#ifdef _WIN32
Windows specific stuff...
#endif

#ifdef MACOSX
Mac specific stuff...
#endif

....

now, the code specific to each OS will only show up on its specific OS.


this includes things like GUI, sound-system interfaces, ...
generally, it is fairly common practice to wrap a lot of this in OS
specific wrapper code, such that the app is mostly dealing with more
normalized interfaces internally.

for example, low-level memory allocation:
#ifdef _WIN32
ptr=VirtualAlloc(...);
#endif
#ifdef linux
ptr=mmap(...);
#endif
....

but, in general it is far less effort than many people make it out to
be, and usually only effects a smaller portion of the total code,
provided the developer(s) know what they are doing.

personally, I have had relatively few issues with 32 and 64 bit
transitions as well.


yes, and I have done cross-platform apps with network and sound and GUI...

 

[BGB]

I'd bet, these days, that the root cause of that situation is the fact
that the three operating systems have *completely* different GUI's.

for source compatibility, yes, cross-platform GUI is a big issue.


for binary compatibility, the much bigger issue is the lack of a common
set of binary formats, as well as different CPU architectures and
operating modes.

a VM could address this.

And actually, Linux alone has *two* (more than two, technically, but
only two popular ones)

You have the Windows UI, the Cocoa UI on Mac, and KDE or Gnome running
under X11 on Linux.

granted...

my ideas for running C in a bytecoded VM, also just happened to include
ways of basically delaying final type specialization, many cases of
handling "#ifdef" blocks, ... until JIT time.


but, I don't believe this to be insurmountable with a VM.

granted, it is not as simple as with a homogeneous environment say like
the Java/JVM model, since this would reasonably need to deal with a good
deal more inter-OS variations (and still leaves the issue that code
which is not written in a portable way, will still not be portable).

but, if the VM can do its part, this at least is a start.


so, say, things like:
#ifdef _WIN32
void MyApp_SomeWindowsFunction()
{
...
}
#endif

#ifdef linux
void MyApp_SomeLinuxFunction()
{
...
}
#endif


void MyApp_SomeFunction()
{
...
#ifdef _WIN32
MyApp_SomeWindowsFunction();
#endif
...
#ifdef linux
MyApp_SomeLinuxFunction();
#endif
...
}


would delay handling of the ifdef blocks until one is compiling the code
in the JIT.

in my prior VM design, this had generally worked by internally
transforming many of these ifdef conditionals into attributes, where the
attribute would be a JIT-time conditional (whether or not to include a
given code-block).

typically, statement-level ifdefs were handled by folding the code into
its own block, which shares lexical bindings with the parent.

a restriction to all this though was that #ifdef and similar had to
follow proper block nesting, which is not true of true C ifdef's.

related restrictions also existed on the use of macros, ...


likewise, not all types could be entirely known at compile-time, and so
the JIT would have to handle some amount of the type-specialization, ...


or such...

 

[BGB]

But windows still run on, what, may be 9[0]% of the PC's in
the world?

http://en.wikipedia.org/wiki/Microsoft_Windows

"As of October 2009, Windows had approximately 91% of the market
share of the client operating systems for usage on the
Internet.[3][4][5]"

Interestingly, [3][4][5] were examined in October 2009 to get the 91%
figure. The 2011 numbers have all fallen--some more, some less.
[/QUOTE]

because, slowly but surely, Windows becomes more sucky WRT its
competition...

yes, Win95 and 98 sucked... at least NT4 and Win2K were decent enough at
the time.

XP was solidly good, as at least there were no major issues.

Vista was like "WTF, this sucks...".
Windows 7 is like "well, at least it is not Vista.".

but, it is a problem:
use Windows 7, have computer that generally performs like crap (vs XP)
and often behaves weirdly.
or use WinXP and have lots of newer apps not actually work.


sadly, Linux has not entirely caught up to Windows WRT making an OS
which is solidly good either... but, yeah, modern Linux would probably
have wiped the floor with Win98, but peoples' expectations are a little
higher now.


so, alas...

 

[BGB]

*Sigh* I get this crap all the time from the clueless newbies. Let me
explain to you something about USENET: my postings are to record what I
said, not what you said. If I quote any part of you said, it is to give
some context for what I said, nothing more.

Rest assured if I reply to you I did read what you said, whether I quoted
it or not. If I was ignoring what you said, I wouldn’t even bother replying
to you.

I have been using usenet for, what, 15 years...

now, the problem with your quoting style is that it often seems to be
being done in a way which obscures or misrepresents what the person who
was being responded to actually said, as if one is trying to
retroactively alter it and responding to this alteration instead of the
original meaning.

hence, this would appear to be a sort of trolling.

 

[Nasser M. Abbasi]

for source compatibility, yes, cross-platform GUI is a big issue.


for binary compatibility, the much bigger issue is the lack of a common
set of binary formats, as well as different CPU architectures and
operating modes.

a VM could address this.

The funny thing, is that Java when it came out, was supposed to
solve all these differences by putting a virtual OS between the
application and the OS, this way one writes to this one common
virtual OS (the VM) and not have to worry about the different
OS's below it.

But now it seems we have different virtual OS's also coming out.

So, I have an brilliant solution I'd like to suggest:

we need is a SUPER VM

A super virtual OS, is a virtual OS which runs on top of a
virtual OS.

i.e. the super VM, hides which VM it is running under, so it
runs on top of all the other VM's:

SUPER VM
Java VM, Google VM, Windows NET VM, etc..
WINDOWS, LINUX, Mac, VMS, etc..

This offourse, until one comes up with a different version of the
SUPER VM, then we go and make a SUPER SUPPER VM. So we need
to make sure this time, that we have provisions in place to
prevent someone from making a different SUPER VM.

I would like to go patent this now.

--Nasser