Java’s Future Lies In Mobile?

[Arne Vajhøj]

Ah! I did not know it was a different GUI.

If you look at:

http://developer.android.com/reference/java/awt/font/package-summary.html

then you see no AWT and no Swing.

Arne

 

[Arne Vajhøj]

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."

They talk about Java programming language and the implemented
Java SE classes are in java and javax namespace.

But you will not find anywhere where they claim that Android
implement Java.

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

SWT and Echo does neither claim to be a Java implementation or
in any way attempt to remove any standard Java SE functionality.

Marketing something as being a Java implementation without
implementing the entire Java SE API is a trademark violation.

MS tried that. SUN sued. And MS ended up paying 20 M$.

So there is some precedence.

I am pretty sure that Google lawyers are very careful
when it comes to using the word Java in anything.

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

They say Java programming language and Java compiler.

They don't claim to be a Java implementation.

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

constructed fantasy.

You need to dig a little deeper than just noting that the
word Java is used.

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

Google is a member of Eclipse and use Eclipse for not just
Android but also for GWT.

Arne

 

[Lew]

They talk about Java programming language and the implemented
Java SE classes are in java and javax namespace.

But you will not find anywhere where they claim that Android
implement Java.


SWT and Echo does neither claim to be a Java implementation or
in any way attempt to remove any standard Java SE functionality.

Marketing something as being a Java implementation without
implementing the entire Java SE API is a trademark violation.

MS tried that. SUN sued. And MS ended up paying 20 M$.

So there is some precedence.

I am pretty sure that Google lawyers are very careful
when it comes to using the word Java in anything.


They say Java programming language and Java compiler.

Yep. That's use of the trademark.

They don't claim to be a Java implementation.

"...developing applications on the Android platform using the Java programming
language."

What they don't claim is that it's a JVM implementation. That phrase right
there is a pretty darn clear claim of the use of Java, using the "Java" trademark.

What part of "... using the Java programming language" do you think they did
not mean?

fantasy.

You need to dig a little deeper than just noting that the
word Java is used.

Uh, you are denying the facts. They say flat out that "the Java programming
language" is used. That's more than just using a word, that's averral of a
fact. You need to stop denying conclusive evidence.

Google is a member of Eclipse and use Eclipse for not just
Android but also for GWT.

Yep, they provided a GUI builder for Eclipse because they prefer Eclipse, as
you just supported with your evidence.

 

[David Segall]

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.


That's begging the question.

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

OK! I should have said "That explains why Eclipse
is preferred _by developers_".

 

[David Segall]

If you look at:

http://developer.android.com/reference/java/awt/font/package-summary.html

then you see no AWT and no Swing.

I wasn't disagreeing with you. On the contrary, I was grateful for the
explanation of why I should use Eclipse instead of (my preferred)
NetBeans for Android development. I haven't bought my Android phone
yet so my need was not urgent.

 

[Arne Vajhøj]

Yep. That's use of the trademark.


"...developing applications on the Android platform using the Java
programming language."

What they don't claim is that it's a JVM implementation. That phrase
right there is a pretty darn clear claim of the use of Java, using the
"Java" trademark.

They do not claim to be a JVM implementation.

But they do not claim to be a Java implementation either.

Being a Java implementation means passing the Java SE TCK.

And it requires both a compliant JVM and a compliant library.

What part of "... using the Java programming language" do you think they
did not mean?

I am sure that they meant it.

But I don't consider using Java language to be implementing Java.

Uh, you are denying the facts. They say flat out that "the Java
programming language" is used. That's more than just using a word,
that's averral of a fact. You need to stop denying conclusive evidence.

I don't see any facts supporting that:
* Google claims Android is a Java implementation
* implementing the Java language is sufficient for something
to be a Java implementation

Arne

 

[Lew]

I don't see any facts supporting that:
* Google claims Android is a Java implementation

You reframed the discussion and added this undefined criterion "is a Java
implementation".

* implementing the Java language is sufficient for something
to be a Java implementation

I don't care about that. I don't know what you mean by "is a Java
implementation", nor did I claim that Darvik or what's in Android is whatever
you mean by that phrase.

What I did claim is that Java programming skills apply to Android because
Android is programmed in the Java language. You cannot deny that by refuting
some different undefined point.

 

[Arne Vajhøj]

You reframed the discussion and added this undefined criterion "is a
Java implementation".


I don't care about that. I don't know what you mean by "is a Java
implementation", nor did I claim that Darvik or what's in Android is
whatever you mean by that phrase.

I started by noting that:

"Even though it is not officially Java."

and:

"It is not certified Java SE"

Which are correct.

What I did claim is that Java programming skills apply to Android
because Android is programmed in the Java language. You cannot deny that
by refuting some different undefined point.

On which I wrote:

#> Why would anyone think that Java skills wouldn't apply to Android
#> development?
#
#They obviously do.

Which agree with that.

(they are "Java skills")

Arne

 

[Mike Schilling]

.... with the Memphis blues, again.

 

[Lew]

I respect your reasoning and perspective even when I disagree with what you
say. To disagree with your conclusions is always at peril.

Within the frame you presented, that Android is not itself a Java
implementation, you make a good argument. I'm not entirely convinced - to a
pragmatist a failure to contain certain features makes it no less "Java" than
is Java ME. OTOH, it clearly is not your grand-daddy's Java. So you are
correct. And you bring to light an important point:

WORA - Write Once Run Anywhere - doesn't mean WARA.

Java has dialects that are not fully compatible with each other. SWT and
Swing don't really mix. Neither do Android and certain desktop idioms.

More generally, portability is a spectrum. You have to have some notion of
the underlying platform even if at an abstracted level.

I'm also correct, in the sense that a dialect of Java still deploys Java
programming skills. Some perhaps might seek to narrow the definition of "Java
skills" to the point that they don't apply to smartphone work. That's all
right - by that definition they're right. But it's a Pyrrhic victory that
denies them the use of their own hard-won skills in a new environment.

So for me, Android is "Java" in any pragmatic sense that lets me leverage what
I've already got. Google calls it "Java" themselves and there's nothing in
the programming model that contradicts that assertion.

Whatever transpires next, Arne, your discourse has empowered me to clarify my
understanding and refine it where I would not otherwise have done so.

 

[Arne Vajhøj]

I respect your reasoning and perspective even when I disagree with what
you say. To disagree with your conclusions is always at peril.

Within the frame you presented, that Android is not itself a Java
implementation, you make a good argument. I'm not entirely convinced -
to a pragmatist a failure to contain certain features makes it no less
"Java" than is Java ME. OTOH, it clearly is not your grand-daddy's Java.
So you are correct. And you bring to light an important point:

WORA - Write Once Run Anywhere - doesn't mean WARA.

Java has dialects that are not fully compatible with each other. SWT and
Swing don't really mix. Neither do Android and certain desktop idioms.

More generally, portability is a spectrum. You have to have some notion
of the underlying platform even if at an abstracted level.

I'm also correct, in the sense that a dialect of Java still deploys Java
programming skills. Some perhaps might seek to narrow the definition of
"Java skills" to the point that they don't apply to smartphone work.
That's all right - by that definition they're right. But it's a Pyrrhic
victory that denies them the use of their own hard-won skills in a new
environment.

So for me, Android is "Java" in any pragmatic sense that lets me
leverage what I've already got. Google calls it "Java" themselves and
there's nothing in the programming model that contradicts that assertion.

Whatever transpires next, Arne, your discourse has empowered me to
clarify my understanding and refine it where I would not otherwise have
done so.

To add to that, then my opinion is that Google and Oracle
should make peace - and as part of that make the Android platform the
new Java ME standard (they may need to add some Java ME stuff to
be backwards compatible, but that should not be a big deal).

Arne

 

[Lew]

... with the Memphis blues, again.

That was simply brilliant. Kudos.

 

[Dirk Bruere at NeoPax]

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.

One of the big mistakes of history was IBM opting for the 8086 rather
than the 68000 (or even Z8000)

As for processing power, I think s/w will shortly begin to outpace
processing power once again esp with usable voice recognition and
realtime language translation apps

 

[Dirk Bruere at NeoPax]

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!

But it helps.
And there is enough difference between Android and standard Java progs
to make it a real pain. I found one of the hardest bits being the use of
XML files to describe layouts and resources.

 

[Dirk Bruere at NeoPax]

I wasn't disagreeing with you. On the contrary, I was grateful for the
explanation of why I should use Eclipse instead of (my preferred)
NetBeans for Android development. I haven't bought my Android phone
yet so my need was not urgent.

Neither have I.
The emulator is a bit of a dog, but usable.
I'm waiting for a cheap Honeycomb tablet to emerge

 

[Arne Vajhøj]

And there is enough difference between Android and standard Java progs
to make it a real pain. I found one of the hardest bits being the use of
XML files to describe layouts and resources.

I did not even know that.

But it is not so novel a concept.

It sounds very much like Flex mxml and Silverlight xaml.

Arne

 

[Dirk Bruere at NeoPax]

Maybe you should consider getting a phone - I deploy apps directly to my
phone, over USB, and it's much quicker than using the emulator.

The emulator is more than "a bit of a dog." Something needs to be done
about that.

The stuff I am developing is really for a Tablet for use as an AV
controller.
The min spec is a Samsung Galaxy Tab, and that's too expensive.
I might get an Advent Vega, but I would prefer the company to make some
statement about Honeycomb upgrades before I do

 

[Dirk Bruere at NeoPax]

I did not even know that.

But it is not so novel a concept.

It sounds very much like Flex mxml and Silverlight xaml.

Arne

It's probably a neat idea, but I am not used to xml

 

[Lew]

It's probably a neat idea, but I am not used to xml [sic]

It is a little strange to lay out graphics with XML - it's like drawing a
picture with words. But no Java programmer can afford to be unfamiliar with XML.

 

[Arne Vajhøj]

It's probably a neat idea, but I am not used to xml

It is still a form of code.

Arne