Android vs Java (FX)?
kiwisincebirth
Google, and the Open Handset Alliance.
http://www.openhandsetalliance.com/android_overview.html
This appears to be in direct competition to Sun's Java FX Mobile
initiative launched earlier this year. But it goes a little deeper
than that. Google have been absent about using the work Java in there
literature, and for good reason!
The Dalvick VM (included with Android) is a departure from a
traditional JVM in that it runs it's own variant of byte-code. It
supports a language similar to Java, supports a lot of the common Java
API's (Apache Harmony), and runs in traditional IDE's. It just
compiles to a different byte-code.
Effectively creating there own platform Google is not dependant on Sun
or the JCP, it is free to distribute the platform under it's own
licensing agreement allowing Google to pursue there own direction for
the platform independantly of Sun.
http://blogoscoped.com/archive/2007-11-13-n83.html
http://blogs.zdnet.com/BTL/?p=6900
http://www.psynixis.com/blog/2007/11/06/android-vs-javafx-mobile-the-big-difference/
http://www.infoq.com/news/2007/11/android-java
When Java was open-sourced there was concern over the potential for a
fork to occur, well that day seems to have arrived.
Do we need two competing open mobile platforms?
What will this mean for Sun's Java FX Mobile platform?
Will this impact the Java platform in general?
Which technology should I be building my next-gen mobile apps on?
Can Sun compete?
Mark
Casper Bang
> fork to occur, well that day seems to have arrived.
Stephen Colebourne's Kiajro, Rémi Forax's properties etc. I wouldn't
be surprised if IBM has something cooking either.
> Do we need two competing open mobile platforms?
Competition in the form of .NET did wonders for mainstream Java, this
might do the same for mobile.
> Can Sun compete?
With Google? Hmm... appears to me the people who wrote large portions
of the Java class libraries now work for Google. And considering the
difference in cash flow and Sun's unimpressive marketing department my
money would be on Google.
It's quite peculiar though how Sun's Jonathan Swartz praises the
initiative considering:
- They are not part of the alliance.
- Apache Harmony is used rather than Sun's (remember the open letter
issue).
- The API is a hybrid between ME/SE/Google extensions.
- It has codec's, WebKit browser wrapper and whatnot which has always
lacked in Java.
- There's no JVM involved.
So technically, I guess this can't really be called Java (referencing
the Sun vs. Microsoft disbute). Meaning Sun and their JCP veto right
is completely out of the picture.
But the real question is of course: what's in it for Google? Does
this
mean we'll soon have ads in our address book? lol
/Casper
Michael Neale
its necessarily an adversarial thing with Sun's efforts. Its good to
have great choices. Perhaps there is a link between them we are
missing?
Dalvik VM looks like a phenominal piece of engineering. It is really
built for purpose. Using bytecode as the "source" for this looks like
a smart move in my opinion. Time will tell I guess, but from the
videos of real "gphones" in action - WOW. And the api is very very
very nice. JavaFX as a UI language would be nice - which will
(presumably) compile to .class, which Android can work with, so its
not ether/or really.
As for googles motivation, really I think its simple. Google want you
to have the internet with you, on, all the time, as much as possible.
Or at least most of the time. Not some crusty old teclos version of
the net, not to sell you ring tones for a dollar each (or more??) or
other worthless content. But the internet. All of it, all the time
(you know why). I think they were tired of the silly games that telcos
and handset makers were playing (perhaps with the exception of apple
now) - and just wanted to give it a shove, and they had the resources
to do it. They just want you to have the internet. If there was a way
to have it prejected on your retina, they would be on it post haste.
Good on them I say. I look forward to seeing what people get up to
with Android, and I hope Dick spills the beans on what it really is
and so on. Thats his job now !
On Nov 14, 2:21 pm, Casper Bang <c...@brunata.dk> wrote:
> > The Dalvick VM (included with Android) is a departure from a
> > traditional JVM in that it runs it's own variant of byte-code. It
> > supports a language similar to Java, supports a lot of the common Java
> > API's (Apache Harmony), and runs in traditional IDE's. It just
> > compiles to a different byte-code.
>
> Has anyone dug around at the bytecode level? I.e. could Google
> possibly have added reified generics since they are not (*liberating
> sigh*) bound by all the legacy stuff?
>
> > When Java was open-sourced there was concern over the potential for a
> > fork to occur, well that day seems to have arrived.
>
> Oh there are many signs of this "breaking out of Sun confinement",
> Stephen Colebourne's Kiajro, Rémi Forax's properties etc. I wouldn't
> be surprised if IBM has something cooking either.
>
> > Do we need two competing open mobile platforms?
>
> Competition in the form of .NET did wonders for mainstream Java, this
> might have the same effect for the mobile world.
>
> > Can Sun compete?
>
> With Google? Hmm... appears to me the people who wrote large portions
> of the Java class libraries now work for Google. And considering the
> difference in cash flow and Sun's unimpressive marketing department,
> my money would be on Google.
>
> It's quite peculiar though how Sun's Jonathan Swartz praises the
> initiative considering:
> - They are not part of the alliance.
> - Google uses Apache Harmony rather than Sun's (remember the open
> letter issue).
> - The API is a hybrid between ME/SE/Google extensions.
> - Such major parts as Swing and AWT are completely missing.
> - It has video codec's and whatnot which has always lacked in Java.
> - There's no JVM involved.
>
> So technically, I guess this can't really be called Java. Meaning Sun
> and their JCP veto right is completely out of the picture.
>
> The real question is of course: What's in it for Google? Does this
> mean soon we'll have to get used to ads in our phone's address book?
> lol
>
> /Casper
kiwisincebirth
byte-codes are different. Source level compatability would be the best
you could expect, so unless Java FX was ported (and all its
dependancies) to run on Android then you would be out of luck.
Thats the point, this isnt Java we are talking about here, it is
however a very Java-like platform
Mark :)
kiwisincebirth
are looking to have there services extend into the major mobile
platforms. There involvement with Apple, has probably given them
insight into what is possible. But there company culture is so
different with that of Apple, that they cannot really allign to them.
So looking around the competition, Sun, Microsoft; Google proably
cant see how they can work with them either, to bring there platforms
upto scratch, and the platform would still be controlled by the
respective company. Only choice left is to buy into another technology
(open source it), let others build hardware, and software, that would
make the platform compete with Apple, and in doing so sell more
advertising.
Mark.
Michael Neale
sent to the phone (you can either use the tools) - but its pretty
clear it works off .class format, NOT source.
JavaFX compiles to .class files (AFAIK?) - therefore you can convert
this to dex:
http://code.google.com/android/reference/othertools.html#dx
All you need are class files !
Augusto Sellhorn
the Android environment, that's pretty easy to do. The problem is that
Android doesn't include any of the AWT/J2D/Swing classes that JFX
depends on. So you would have to extend what is there and include
quite a bit of functionality just to have the simplest hello world JFX
app.
PeterAndersen
Love to hear Joe discus this topic on the posse ... with.. well:
Joe ;-)
Hi has been out for all the Java/OS X things, look like hi got this
for him self
/Peter
> > > not ether/or really.- Hide quoted text -
>
> - Show quoted text -
Casper Bang
> sent to the phone (you can either use the tools) - but its pretty
> clear it works off .class format, NOT source.
Since the class byte code is so closely aligned with an AST from a
java file, can't this just be seen as reuse of the compiler parts
(lexer, parser, syntax sugar expander) more than nessesarily a desire
to cross-compile Java byte code per se? Compared to what the VM has to
do, these first steps seem insignificent. In other words, Google could
very well end up writing .dex files and perhaps avoid some of the
annoyences of classic Java byte code (lack of true generics etc.)
> Love to hear Joe discus this topic on the posse ... with.. well:
> Joe ;-)
Joe and Tor could discuss the story I guess, of course both could be
suspected of not having anything particular positive to say about the
GPhone given it's basically an open version of the iPhone but using
pseudo-Java. From the demo's its pretty clear the GPhone
responsiveness falls behind that of the iPhone, but whether that's due
to the difference in stack (no pseudo-Java on the iPhone) or simply a
maturity thing only time can tell. Indeed, it should be a very
interesting next posse podcast.
/Casper
PeterAndersen
Isn't Tor working for Sun? Hi can't talk about the "vs Java FX Mobile"
/Peter
Casper Bang
No but he might shed a little light about Sun's view on this, whether
the really interesting people (the engineers) consider it a fork or
not. After all, what comes out on Jonathan Schwartz blog makes little
sense; he just appears busy ordering a new batch of bumper stickers
with "Java is now on a trillion phones".
/Casper
robilad
> So technically, I guess this can't really be called Java (referencing
> the Sun vs. Microsoft disbute). Meaning Sun and their JCP veto right
> is completely out of the picture.
Google's interpreter,
as the two ME JVM vendors wouldn't be on board if there was no money
to make selling JVMs for it.
Sun would be crazy to fight android, when they make money on the
certification of ME VMs for it.
> But the real question is of course: what's in it for Google? Does
> this
> mean we'll soon have ads in our address book? lol
Michael Neale
not in terms of its UI goodness.
On Nov 14, 8:25 pm, Augusto Sellhorn <augusto.sellh...@gmail.com>
wrote:
Casper Bang
> Google's interpreter,
> as the two ME JVM vendors wouldn't be on board if there was no money
> to make selling JVMs for it.
> Sun would be crazy to fight android, when they make money on the
> certification of ME VMs for it.
(JSE) parts than JME. So from the other end of the speculation scale,
it seems just as possible that the JME vendors were brought in to
assist in developing Dalvik rather than being merely JME vendors.
Google, not mentioning Java anywhere, appears free to create their own
TCK around Android allowing commercial implementations - this would be
very interesting to existing JME vendors.
I know Sun is trying to suppres the possible implications of this, but
when your CEO writes about NetBeans support etc. that really just
seems deluded considering the choices made by Google suggests they
really are not interested in conforming to Sun (or their JCP veto
right) in any way, shape or form (Eclipse instead of NetBeans, Harmony
instead of Sun, SQLite instead of Derby etc.). The mantra of write-
once-run-everywhere in the form of JME did not deliver, Google being
somewhat more pragmatic than Sun saw this and acted. If you are not a
Sun (and possibly an Apple) employee, this is a very exciting project
for what it might amount to in the consumer world.
/Casper
Augusto Sellhorn
> ah yeah - I guess I was thinking of JavaFX Script in abstract sense,
> not in terms of its UI goodness.
Amarjeet Singh
--
Amarjeet Singh
Phone: +91-98712-76661
Steve Lewis
>
> <off_topic>Talk about going 'Paranoid' about 'Android'</off_topic>
Fitter. Happier. More productive.
--
SteveL
Joshua Marinacci
are some confused looking germans near by. :)
- J
Peter Becker
Peter
robilad
> > I suspect that commercial deployments will use ME VMs, rather than
> > Google's interpreter,
> > as the two ME JVM vendors wouldn't be on board if there was no money
> > to make selling JVMs for it.
> > Sun would be crazy to fight android, when they make money on the
> > certification of ME VMs for it.
>
> Looking at the source, there seem to be a lot more Apache Harmony
> (JSE) parts than JME. So from the other end of the speculation scale,
> it seems just as possible that the JME vendors were brought in to
> assist in developing Dalvik rather than being merely JME vendors.
> Google, not mentioning Java anywhere, appears free to create their own
> TCK around Android allowing commercial implementations - this would be
> very interesting to existing JME vendors.
TCK, as they
have complete control over implementations and the API. There is also
no Android spec.
You only need a spec and a TCK if you are building an open platform.
That is, something
you expect others to build independent implementations of. Note the
lack of a
specification for Android's API and note the lack of a compatibility
verification suite.
It's in Google's interest to make sure that there are no alternative
implementations
of Android for the next couple of years, and while Googlers can't
outright try to kill
Maemo or OpenMoko, as that would be a bit obvious, they can make sure
that
Android is licensed in a way that prevents Maemo and OpenMoko from
building their
own clones, or porting Android on their own stacks.
Which is what Google has, funny enough, done with the Android SDK
license, while
getting all the good press (and the stock shoot through the roof as
long as investors
bought the lie) they can on the fake story that Android is open source
and ALv2 licensed.
Since Google needs total control over the product, in order to keep
their consortium
from fragmenting it too fast, going with ME or SE would have been
pointless for them,
as those aren't technologies Google can assert full control over.
So instead, Google went for a ME/SE hybrid with its own proprietary
application
development framework. But ME/SE hybrids with some added on framework
are
all the rage these days anyway: IBM is working on eRCP/eSWT, Sun is
working on JavaFX.
Google's coming late to an already fragmented party. They are
validating the Java on
Linux combination, even if Android isn't officially either, of course,
so the money Google
will pour down this hole will end up helping both.
I'd still bet on Apple, as they have the one lickable device (iphone/
ipod), with the one API
(os x frameworks), with the one channel (itunes) to sell your apps to
Apple's '600
USD on a phone gadget means nothing to me' customers globally. And I'd
guess that it
wasn't Sun's stock ticker name change that prompted Google to release
Android in its
current, unfinished, no-hardware-on-the-market-for-another-year
state. ;)
Michael Neale
of Java - I would say most. Python has no "TCK" (it barely has a spec
- well it kind of does). In fact lots popular programming languages
don't - including ones that could be considered as "platforms". There
is no "TCK" for linux, yet no one would argue that it is not an open
platform.
This separation of implementation and spec seems to be common in the
Java community, but I don't see it as much anywhere else.
Peter Becker
implementations. Many vendors implement and declare the implementation
the "standard" -- some even try to turn the resulting pile of crap
into an official standard (http://openxmldeveloper.org).
I guess part of the story is that traditional engineering knows only
specs -- after all you can't just duplicate an implementation of the
spec around the world. And you don't really need (possibly shouldn't
even) make an implementation part of your standard -- and I don't
think that is what Sun does. The implementation is there to test the
spec for flaws/obmissions (I think of it as a "prototype" in the
classical engineering sense), not as part of the final standard. Of
course we are doing software where prototypes live longer.
Cheers,
Peter
PS: I have read arguments (don't have the pointer anymore, sorry) that
you should really require two independent implementations of a spec
before releasing it since otherwise you can easily have answers to
some questions only in the implementation, but not in the spec. It can
still happen with n implementations, but it gets less and less likely
with every new implementation.
robilad
> Plenty of open source things don't have a TCK or a spec to the level
> of Java - I would say most. Python has no "TCK" (it barely has a spec
> - well it kind of does). In fact lots popular programming languages
> don't - including ones that could be considered as "platforms". There
> is no "TCK" for linux, yet no one would argue that it is not an open
> platform.
robilad
> of Java - I would say most.
A) Android is not open source, so you can't create alternative
implementations with it.
B) Android does not have a spec / test suite, so you can't create
alternative implementation without it.
The examples for open platforms you gave, usually fall into category
A, where due to them
being open source, it is possible to clone the platform, improve it,
port it, etc. Even without Android being
open source, Google explicitly prohibits use of the Android SDK for
uses other than writing applications
for their own walled garden, which means that you can't write an
Android clone if you are using the
Android SDK. Google intends to keep things that way until their
exclusive implementation
of Android is 'established' in the market, according to a statement
last week.
The whole point of an open platform is that it is open to alternative
implementations. Otherwise, you
don't have an open platform, you have a vendor (cartel) with a binary
blob, marketed as 'open', but
anything but that in practice. Been there, helped spring one of those
traps open. I know one when I see it. :)