updates and so on

[Stefan Ram]

Recently, Java had to be upgraded often due to several
security issues and also the procedure used to update Java
on the clients was subject to discussions. I just read this
text that was written about 1995 or 1996 in an early Java
whitepaper:

»Operating on multiple platforms in heterogeneous
networks invalidates the traditional schemes of binary
distribution, release, upgrade, patch, and so on. To
survive in this jungle, the Java language must be
architecture-neutral, portable, and dynamically adaptable.«

But it seems that Java today still relies on that same
»traditional schemes of binary distribution, release,
upgrade, patch, and so on«. (The »jungle« of course was part
of a text that often is given as the source for the choice
of the name »Java«.)

 

[Thomas Richter]

Recently, Java had to be upgraded often due to several
security issues and also the procedure used to update Java
on the clients was subject to discussions. I just read this
text that was written about 1995 or 1996 in an early Java
whitepaper:

»Operating on multiple platforms in heterogeneous
networks invalidates the traditional schemes of binary
distribution, release, upgrade, patch, and so on. To
survive in this jungle, the Java language must be
architecture-neutral, portable, and dynamically adaptable.«

But it seems that Java today still relies on that same
»traditional schemes of binary distribution, release,
upgrade, patch, and so on«. (The »jungle« of course was part
of a text that often is given as the source for the choice
of the name »Java«.)

To my understanding, two different things are meant here: a) How the
language core and language runtime are updated, and b) how the programs
running on this core are updated.

a) is still the same old stuff, for the same reasons binary programs
require updating anyhow.

b) could be done in a more elegant way with java, though java programs
are no longer "distributed" in the way envisioned back then. Nowadays,
java programs are server-side, and not client side as envisioned, and
thus the "dynamical update mechanism" is - as a tool for software
deployment - not really needed. What is left from this is the very
dynamic binding java offers, i.e. the injection of code at run time,
server side. Though not for distribution purposes, but rather as part of
the normal program flow, or debugging.

 

[Arne Vajhøj]

"Thomas Richter" wrote in message
[snip]

Nowadays, java programs are server-side, and not client side as
envisioned, and
thus the "dynamical update mechanism" is - as a tool for software
deployment - not really needed.

WTF? Have you not heard of Swing, Applets, Java Web Start, SWT, AWT or
JavaFX? Have you not heard of embedded Java or The Internet of Things?

Java is on far more platforms and devices than ever and Oracle is very
deliberately pushing Java to be the "technology of choice" for embedded
platforms and the IoT. Many of these platforms require GUIs and of
course need to be updated.

The notion that "java (sic) programs are server-side" is utter nonsense.

Java is not only server side.

But if we look at the amount of Java code being written and the
number of people employed to write the code, then Java EE aka
"server side" is certainly by far the biggest share. Android, desktop
apps, applets, embedded etc. being far behind.

Arne

 

[Arne Vajhøj]

"Arne Vajhøj" wrote in message

[snip]

Java is not only server side.

But if we look at the amount of Java code being written and the
number of people employed to write the code, then Java EE aka
"server side" is certainly by far the biggest share. Android, desktop
apps, applets, embedded etc. being far behind.

This is undoubtedly correct. I am merely rejecting Thomas's (implied)
notion that we no longer need to address the issues raised by Stefan
because Java only ever gets deployed to servers. Again, that is utter
nonsense.

BTW I made no reference to Android/Dalvik because that is not officially
Java. However, JavaFX will be running on iOS and Android phones and
tablets sometime in 2014.

Android is officially not Java.

But "If it looks like a duck, swims like a duck, and quacks like a duck,
then ...".



Arne

 

[Arne Vajhøj]

"Arne Vajhøj" wrote in message


Don't get me started! Of course it *is* Java (same class names, methods
etc.) but will never be *called* Java for obvious legal reasons.

But it doesn't matter because, as I mentioned, JavaFX (and thereby Java
itself) will soon be running on both iOS and Android. The point is Java
is or soon will be deployed to millions of devices which are NOT servers.

Will be available for deployment or actually deployed?

That is a big difference!

Arne

 

[Thomas Richter]

Am 21.11.2013 23:47, schrieb Qu0ll:

in message

[snip]

Nowadays, java programs are server-side, and not client side as
envisioned, and

thus the "dynamical update mechanism" is - as a tool for software
deployment - not really needed.

WTF? Have you not heard of Swing, Applets, Java Web Start, SWT, AWT or
JavaFX? Have you not heard of embedded Java or The Internet of Things?

Yes. And this application of java is dead. Oracle killed it
successfully. Once you require from your users to "click" on an applet
to start it, or to click on scary security warnings, the user is gone.
If it does not run on mobile devices nowadays, the user is gone, too.

Nice idea, but ridden by problem. Too late to fix, this ship sailed away
quite a while ago.

 

[Thomas Richter]

Am 22.11.2013 10:01, schrieb Qu0ll:

in message


Well at least you got one thing right - applets are most definitely
dead. But for some reason you ignored all of the other "non-server"
deployment methods I mentioned.

The future of Java (other than the obvious server-side usages) is IoT.
And, I also believe that JavaFX (and hence Java) can be a big player in
mobile and tablet space when iOS and Android support is viable next
year. It's being worked on by both Oracle and the JavaFX community and
*will* be viable in the short term.

I don't believe it will.

Do you still want to hang-on to your "only server" stance Thomas?

Yup. We'll talk in a year.

 

[Nigel Wade]

Recently, Java had to be upgraded often due to several
security issues and also the procedure used to update Java
on the clients was subject to discussions. I just read this
text that was written about 1995 or 1996 in an early Java
whitepaper:

»Operating on multiple platforms in heterogeneous
networks invalidates the traditional schemes of binary
distribution, release, upgrade, patch, and so on. To
survive in this jungle, the Java language must be
architecture-neutral, portable, and dynamically adaptable.«

But it seems that Java today still relies on that same
»traditional schemes of binary distribution, release,
upgrade, patch, and so on«. (The »jungle« of course was part
of a text that often is given as the source for the choice
of the name »Java«.)

I think you are not making the distinction between Java the language (including programs written in the language), and
Java the JVM which actually executes the compiled byte-code.

The above quote I think refers to Java the language, which is still "architecture-neutral, portable, and dynamically
adaptable". What does rely on, and has always relied on, "traditional schemes of binary distribution..." is the JVM. The
regular binary distribution of updates/patches etc are fixes to the JVM, not the language.

 

[Nigel Wade]

Android is officially not Java.

But "If it looks like a duck, swims like a duck, and quacks like a duck, then ...".

You're going to get sued? ;-)

 

[Arne Vajhøj]

You're going to get sued? ;-)

By the ducks?



Arne

 

[Fredrik Jonson]

The future of Java [...] is IoT. And, I also believe that JavaFX
(and hence Java) can be a big player in mobile and tablet space when
iOS and Android support is viable next year. It's being worked on by
both Oracle and the JavaFX community[...]

I really don't see that happening - i.e. Oracle gaining serious momentum
with Java FX on Android or Apple devices.

Both Google and Apple have a firm grip on their mobile development
offerings. And the developers enjoy the raw power you get with native
development, a power you never had with Java ME. Would developers really
want to trade that for cross platform development bundled in a
proprietary offering controlled by Oracle?

And the users, would they accept going back to the least common
denominator-based UX reasoning that once dominated Java ME applications?
I understand that Java FX is not Java ME, but besides the possibility of
WORA, what other advantage would FX offer Android or IOS developers?

There are already a few cross platform efforts - f.x. Apache Cordova and
Xamarin - but so far I have seen none that are really gaining momentum.
Neither Microsoft or any other up and coming alternatives, like Firefox
OS, seem really interested in reviving the Java ME train or anything
like it again, and the manufacturers that used Java ME have moved on to
Android a long time ago.

Besides, isn't various Linux based platform complemented with scripting
languages, like Python, Lua, Javascript, or perhaps compiled Go, a more
likely solution for the part of IoT that is not phones and tablets?

 

[Joerg Meier]

Would developers really
want to trade that for cross platform development bundled in a
proprietary offering controlled by Oracle?

What is more is that Android and iOS have very different interface
metaphors, and apps that try to have the same interface will look out of
place on one, and sometimes even both platforms, and be perceived as low
quality.

Liebe Gruesse,
Joerg

 

[Arne Vajhøj]

Am 22.11.2013 10:01, schrieb Qu0ll:

I don't believe it will.


Yup. We'll talk in a year.

We can.

But I am pretty sure that Android is not dead in a year.

Arne

 

[Arne Vajhøj]

And the users, would they accept going back to the least common
denominator-based UX reasoning that once dominated Java ME applications?

Besides the web L&F: not likely.

There are already a few cross platform efforts - f.x. Apache Cordova and
Xamarin - but so far I have seen none that are really gaining momentum.

Cordova/PhoneGap is actually rather widely used. But that is web
technology which benefits from synergies with web.

Arne