Java’s Future Lies In Mobile?

[Lawrence D'Oliveiro]

<http://www.theregister.co.uk/2011/02/08/oracle_loses_client_to_server/>:

Application developers are moving away from the server and to mobile
clients, as a Forrester survey reveals ... ZDNet's Jason Perlow reasons
this shift will benefit Java-based Android more than Apple, in large
part because of Android's Java heritage.

However:

An Android developer isn't, in other words, necessarily a Java
developer, and certainly the skillsets of enterprise Java server
engineers aren't being repurposed for mobile application development.

 

[Arne Vajhøj]

<http://www.theregister.co.uk/2011/02/08/oracle_loses_client_to_server/>:

Application developers are moving away from the server and to mobile
clients, as a Forrester survey reveals ... ZDNet's Jason Perlow reasons
this shift will benefit Java-based Android more than Apple, in large
part because of Android's Java heritage.

There is a lot of bullshit bingo over that analysis.

However:

An Android developer isn't, in other words, necessarily a Java
developer,

Why not.

Practically all Android development are done in Java, with javac and
Eclipse.

Questions about Android show up here.

and certainly the skillsets of enterprise Java server
engineers aren't being repurposed for mobile application development.

We already have: Java SE desktop apps, Java ME mobile apps,
Java web apps, EJB's, Applets, JavaFX and possibly other
stuff that I have forgotten. Now we additionally have Android
as well.

Arne

 

[Lew]

Such certainty over an incorrect statement. I'm an enterprise Java developer
myself, and I find my skills from that work just fine as I'm learning Android
skills.

We already have: Java SE desktop apps, Java ME mobile apps,
Java web apps, EJB's, Applets, JavaFX and possibly other
stuff that I have forgotten. Now we additionally have Android
as well.

Tastes great, less filling. Beats the old days when folks tried to put Java
(1.1) as the chip-level code on a CPU. Now we just cram an entire
supercomputer into a phone shell and run a JVM on it. Simple.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|

 

[Lawrence D'Oliveiro]

We already have: ... Java ME mobile apps ...

Java ME was a joke.

 

[Lawrence D'Oliveiro]

... however, the assertian that an Android developer isn't a Java
developer is mostly BS. I believe there are some Android games written in
C, but most of the apps out there are written in Java.

Being an open platform, at least Android gives you a choice. I believe
Google itself is working on something called App Inventor.

Though things like the recent news that the Dalvik VM now works on Maemo
(with Meego to come), and can run apps written for Android, helps encourage
folks to at least use languages that compile to Dalvik code.

 

[Arne Vajhøj]

Tastes great, less filling. Beats the old days when folks tried to put
Java (1.1) as the chip-level code on a CPU. Now we just cram an entire
supercomputer into a phone shell and run a JVM on it. Simple.

An Android phone would be a pretty powerful computer
in the Java 1.1 days, so it is not really a joke.

Arne

 

[Arne Vajhøj]

Java ME was a joke.

It has been estimated that 2.1 billion devices
support Java ME.

That makes it an important platform.

It does not prevent people from calling it
a joke on usenet, but the joke is really on them.

Arne

 

[The Frog]

Whoever believes that Java isnt a platform for Android is just plain
nuts. The Java developers that I know and work with have all been
easily able to port their skillsets across to Android and have enjoyed
the new platform to play with.

App Inventor is a great way to get people started in developing apps,
especially kids. Could you build a 'real' app with it? Probably, but
it would most likely be easier to just write the Java. Maybe in the
years to come App Inventor will make more complex app building easily
possible, but not today.

Java ME is an important platform, especially for embedded hardware.
Android IMO will far surpass this in terms of importance. The next gen
of hardware that I am seeing some engineers building is going to be
Android based whereas in the past we would use all sorts of things. I
wouldnt be surprised to see far more hardware being Android based in
the years to come. The ARM based CPU's are quite powerful these days
as well as cost effective and well supported. Motorolla's iMX535 SOC
is a great example. You could build a laptop with that thing if you
were so inclined.

The primary areas where Java is being used may change, and probably
will, and IMO I expect Android to be an enormous part of that change.

My 2 cents

The Frog

 

[Lew]

An Android phone would be a pretty powerful computer
in the Java 1.1 days, so it is not really a joke.

I wasn't joking.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|

 

[Roedy Green]

<http://www.theregister.co.uk/2011/02/08/oracle_loses_client_to_server/>:

Application developers are moving away from the server and to mobile
clients, as a Forrester survey reveals ... ZDNet's Jason Perlow reasons
this shift will benefit Java-based Android more than Apple, in large
part because of Android's Java heritage.

It makes much more sense to do the display computations in the client
device, and just exchange compacted binary data back and forth with
the server. This is what Applets can do.

We have been dicking around with infuriatingly inept pure-server side
(slow, poor UI for data entry), and JavaScript/Ajax (write once debug
everywhere).

The big advantage mobiles have over desktops is Java is pre-loaded.
There is no big delay the way there is for your first Applet. Given
how cheap flash ram is today, perhaps Java on the desktop could be
given a boost start by putting a RAM image into a USB Flash drive that
can be loaded in under a second.

 

[Lawrence D'Oliveiro]

It makes much more sense to do the display computations in the client
device, and just exchange compacted binary data back and forth with
the server. This is what Applets can do.

Unfortunately, the applet concept was a failure. Wonder why?

We have been dicking around with infuriatingly inept pure-server side
(slow, poor UI for data entry), and JavaScript/Ajax (write once debug
everywhere).

Google and others can manage it.

The big advantage mobiles have over desktops is Java is pre-loaded.
There is no big delay the way there is for your first Applet. Given
how cheap flash ram is today, perhaps Java on the desktop could be
given a boost start by putting a RAM image into a USB Flash drive that
can be loaded in under a second.

Didn’t Sun try that with their Java Desktop System? Also another failure.

 

[Dirk Bruere at NeoPax]

It's a different platform and API, however, the assertian that an
Android developer isn't a Java developer is mostly BS. I believe there
are some Android games written in C, but most of the apps out there are
written in Java.

I'm certainly writing in Java for Android.
It's been a steep learning curve moving from Netbeans however.

 

[Dirk Bruere at NeoPax]

Such certainty over an incorrect statement. I'm an enterprise Java
developer myself, and I find my skills from that work just fine as I'm
learning Android skills.


Tastes great, less filling. Beats the old days when folks tried to put
Java (1.1) as the chip-level code on a CPU. Now we just cram an entire
supercomputer into a phone shell and run a JVM on it. Simple.

True - it's one of those rare moments where processing power actually
generally exceeds s/w requirements. The big push is now maximizing
Instructions/Watt

 

[Lew]

True - it's one of those rare moments where processing power actually
generally exceeds s/w requirements. The big push is now maximizing
Instructions/Watt

That is not rare. The processing power of the '286 exceeded anything people
did with it, to a first order of approximation. They hadn't even caught up
with the '286 when the '386 and '486 came along.

One of the reasons that Windows was somewhat bloated and clunky was their
choice not to exploit the full power of the Intel-compatible CPU.

 

[Lew]

I'm certainly writing in Java for Android.
It's been a steep learning curve moving from Netbeans however.

http://developer.android.com/guide/basics/what-is-android.html
("What is Android?") tells us, "The Android SDK provides the tools and APIs
necessary to begin developing applications on the Android platform using the
Java programming language."

http://developer.android.com/guide/topics/fundamentals.html
("Application Fundamentals") tells us, "Android applications are written in
the Java programming language."

Check this out:
http://developer.android.com/reference/java/util/Map.html

Can't have a "java.*" package if it isn't Java, can you?

http://en.wikipedia.org/wiki/Android_(operating_system)
"Developers write primarily in the Java language, controlling the device via
Google-developed Java libraries."

Why would anyone think that Java skills wouldn't apply to Android development?

You don't have to move from NetBeans!

 

[Arne Vajhøj]

http://developer.android.com/guide/basics/what-is-android.html
("What is Android?") tells us, "The Android SDK provides the tools and
APIs necessary to begin developing applications on the Android platform
using the Java programming language."

http://developer.android.com/guide/topics/fundamentals.html
("Application Fundamentals") tells us, "Android applications are written
in the Java programming language."

Check this out:
http://developer.android.com/reference/java/util/Map.html

Can't have a "java.*" package if it isn't Java, can you?

http://en.wikipedia.org/wiki/Android_(operating_system)
"Developers write primarily in the Java language, controlling the device
via Google-developed Java libraries."

Why would anyone think that Java skills wouldn't apply to Android
development?

They obviously do.

Even though it is not officially Java.

It is not certified Java SE (it uses a different GUI), so
calling it Java would violate trademarks etc..

But it is still Java.

You don't have to move from NetBeans!

Just that Google pushes Eclipse.

Arne

 

[Lew]

Just that Google pushes Eclipse.

They do, but they don't lock you into it.

Personally I'm not enough of a partisan to care much either way. If Eclipse
stays out of my way better, then I'll use it.

 

[Arne Vajhøj]

They do, but they don't lock you into it.

That would not be in either Java or Google spirit.

Personally I'm not enough of a partisan to care much either way. If
Eclipse stays out of my way better, then I'll use it.

At your level IDE is not so important.

Arne

 

[David Segall]

It is not certified Java SE (it uses a different GUI), so
calling it Java would violate trademarks etc..

But it is still Java.


Just that Google pushes Eclipse.

Ah! I did not know it was a different GUI. That explains why Eclipse
is preferred because, as I understand it, Google has provided a GUI
builder for Eclipse and the Netbeans GUI builder won't work.

 

[Lew]

But they *do* call it Java! How are we passing this by? It says right there,
"... developing applications on the Android platform using the Java
programming language."

Using a different GUI doesn't violate Java trademarks. Otherwise SWT would be
in violation, and it isn't. Nor is Echo2. Etc.

If it weren't, then use of the 'java.' and 'javax.' package namespaces really
would be a violation.

Plus they *are* using the Java trademark in their associated documentation.
http://developer.android.com/guide/basics/what-is-android.html

I'm sorry to break this to you, but that was a beautifully constructed fantasy.

It is actual Java, actually so. Google says so flat out. As has been quoted
multiple times. It doesn't get any freaking plainer than that. No need to
spin cotton-candy fairy tales over it.

Ah! I did not know it was a different GUI. That explains why Eclipse
is preferred because, as I understand it, Google has provided a GUI
builder for Eclipse and the Netbeans GUI builder won't work.

That's begging the question.

The reason Google provided a GUI builder for Eclipse is that they preferred it.