Java claims WORA

[owais]

Java claims WORA (write once and run anywhere). Do you agree with this statement that all java programs can be run anywhere (all platforms)? Can you identify a scenario where this claim may not hold true?

 

[Robert Klemme]

Java claims WORA (write once and run anywhere). Do you agree with this statement that all java programs can be run anywhere (all platforms)? Can you identify a scenario where this claim may not hold true?

I find the question quite strange. Something tells me that you are asking a homework question... Oh, I see:
http://vusols.blogspot.de/

Please do your own research.

Cheers

robert

 

[Gene Wirchenko]

Java claims WORA (write once and run anywhere). Do you agree with this

statement that all java programs can be run anywhere (all platforms)?
Can you identify a scenario where this claim may not hold true?

Since it is your homework, how about you do it?

Sincerely,

Gene Wirchenko

 

[Lew]

Java claims WORA (write once and run anywhere). Do you agree with this statement that all java programs can be run anywhere (all platforms)? Can you identify a scenario where this claim may not hold true?

It is spelled "Java".

I am not aware of a Java port to the PDP-8.

 

[Arne Vajhøj]

Java claims WORA (write once and run anywhere). Do you agree with this statement that all java programs can be run anywhere (all platforms)? Can you identify a scenario where this claim may not hold true?

Java programs written and build for a specific Java version will run
where that Java version or is available (and typical also if a newer
version is available).

Java is available for all the most common platforms.

Arne

 

[glen herrmannsfeldt]

Do you agree with this statement (snip)

Java programs written and build for a specific Java version will run
where that Java version or is available (and typical also if a newer
version is available).

Java is available for all the most common platforms.

So common, but not all.

Is there Java for VAX/VMS?
As I understand it, there are web browsers that run on VMS.

Java requires IEEE floating point, so it tends not to be available
on hosts that have a different floating point format.

Most likely never for, for example, the IBM 7090. (Which would
be batch mode, and not browser/applet, but still.)

-- glen

 

[Martin Gregorie]

Most likely never for, for example, the IBM 7090. (Which would be batch
mode, and not browser/applet, but still.)

More to the point, are any still running?

 

[Robert Klemme]

More to the point, are any still running?

Probably: there's nobody around any more who knows how to switch them off...

robert

 

[Arne Vajhøj]

So common, but not all.
Yep.

Is there Java for VAX/VMS?
As I understand it, there are web browsers that run on VMS.

VMS Alpha and VMS Itanium: yes

VMS VAX: no

But it is 20 years since Alpha came out.

Java requires IEEE floating point, so it tends not to be available
on hosts that have a different floating point format.

That is supposed to be the reason why VAX did not get Java.

But they could have emulated IEEE FP if they wanted to.

Arne

 

[Roedy Green]

Java claims WORA (write once and run anywhere).
Do you agree with this statement that all java programs
can be run anywhere (all platforms)? Can you identify a
scenario where this claim may not hold true?

The caveats are:

1. If your code is written for Java 1,7 you must have a Java 1.7+
runtime. It might not be available for a given platform.

2. a given JVM might have a bug that stops some particular program
from working.

3. If you use JNI, you must have the appropriate native code for the
given platform.

4. Java does requires the programmer to handle the WORA stuff
explicitly for file names and line separators and encodings. Simple
programs will work fine, but more complex ones must be aware.
--
Roedy Green Canadian Mind Products
http://mindprod.com
If you look in a computer programmer's freezer you will find all
kinds of containers, but none of them labeled. They do the same thing
creating files without labeling the encoding. You are just supposed to
know. Ditto with the MIME type, the separator and comment delimiters and
column names in CSV files. Ditto with the endian convention. Imagine how
much more civilised life would have been if Martha Stewart were the first
programmer.

 

[Roedy Green]

Probably: there's nobody around any more who knows how to switch them off..

Where they the ones with the red mushroom you either pulled or pushed
for emergency power off or was that the 360?
--
Roedy Green Canadian Mind Products
http://mindprod.com
If you look in a computer programmer's freezer you will find all
kinds of containers, but none of them labeled. They do the same thing
creating files without labeling the encoding. You are just supposed to
know. Ditto with the MIME type, the separator and comment delimiters and
column names in CSV files. Ditto with the endian convention. Imagine how
much more civilised life would have been if Martha Stewart were the first
programmer.

 

[David Lamb]

Where they the ones with the red mushroom you either pulled or pushed
for emergency power off or was that the 360?

360. You had to call IBM to unlatch the emergency-off and figure out how
many components blew out from the instant power cut.

 

[Arne Vajhøj]

4. Java does requires the programmer to handle the WORA stuff
explicitly for file names and line separators and encodings. Simple
programs will work fine, but more complex ones must be aware.

It is not quite clear to me what "handle the WORA stuff
explicitly" really means.

But the Java API provides classes and methods that allow
for platform independent handling of those.

So by following good practice one should be OK.

Arne

 

[Roedy Green]

The caveats are:

for a more detailed answer see http://mindprod.com/jgloss/wora.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
If you look in a computer programmer's freezer you will find all
kinds of containers, but none of them labeled. They do the same thing
creating files without labeling the encoding. You are just supposed to
know. Ditto with the MIME type, the separator and comment delimiters and
column names in CSV files. Ditto with the endian convention. Imagine how
much more civilised life would have been if Martha Stewart were the first
programmer.

 

[Arne Vajhøj]

for a more detailed answer see http://mindprod.com/jgloss/wora.html

More detailed but very misleading.

#Java works with platform-specific \r \n line-ending conventions. You
have the lineSeparator to help, but your code has to deal with \r\n
(Windows), \n (Unix) and \r (Mac) conventions.

You should be using readLine and println etc. not doing binary
IO with line.separator!

#Internet Explorer is so far out, they can’t even legally call it Java.

I can not see why SUN/Oracle Java used by IE can not be called Java.

#On some platforms the elements of the classpath are separated by
semicolons, and others by colons. There was no need for this variety,
since classpath is a purely Java invention.

Classpath is a Java thingy but path separators are not.

Arne

 

[Thomas Richter]

Am 20.06.2012 17:33, schrieb owais:

Java claims WORA (write once and run anywhere). Do you agree with this statement that all java programs can be run anywhere (all platforms)? Can you identify a scenario where this claim may not hold true?

Java is more like WOTA for me - write once, test everywhere. It's quite
acceptable for simple programs, but as soon as it gets more complex than
this, there are subtle differences between Java installations on Windows
and Linux, and from version to version. I've seen cases where Java does
not size windows correctly on one version, but not on others for reasons
that are not clear to me, where input focus handling was slightly
different and inconsistent, where refresh handling and the order of
requests is slightly different, where window placement may or may not
work... In theory, Java is very nice for running everywhere, but you
still need to test and need to tweak a bit to get it working consistently.

 

[Jan Burse]

Java claims WORA (write once and run anywhere). Do you agree
with this statement that all java programs can be run anywhere
(all platforms)? Can you identify a scenario where this claim
may not hold true?

Java has different degrees of WORA. For example one might
distinguish between headless Java and Java with a GUI.

Headless Java has a broader WORA. If you accept that WORA
also includes transforming bytecode, then via DEX you can
run Java on an Android platforms.

Java with a GUI has a narrower WORA. If you opt for Swing
then you have a good portability on platforms such as Windows,
Mac and Linux. SWT would be an alternative for Swing.

But for Android you would need to rewrite the GUI. But then
with an Android GUI you can cover tablets, phones etc..
which isn't bad.

An Architecture that works for both Swing (or SWT) and Android
would look as follows:

+---------------+
+ Swing GUI |
+---------------+-+---------------+
| Headless Part |
+---------------+-+---------------+
| Android GUI |
+---------------+

There are a couple of design patterns that help you with doing
the above. For the headless part you have WORA, but you need
to build two apps on top of it, a .jar (for Swing) and
an .apk (for Android).

The above recently worked for me.

Bye

 

[John B. Matthews]

Am 20.06.2012 17:33, schrieb owais:

Java is more like WOTA for me - write once, test everywhere. It's
quite acceptable for simple programs, but as soon as it gets more
complex than this, there are subtle differences between Java
installations on Windows and Linux, and from version to version. I've
seen cases where Java does not size windows correctly on one version,
but not on others for reasons that are not clear to me, where input
focus handling was slightly different and inconsistent, where refresh
handling and the order of requests is slightly different, where
window placement may or may not work... In theory, Java is very nice
for running everywhere, but you still need to test and need to tweak
a bit to get it working consistently.

I'll second the need for testing, but I've found that using layouts
properly and respecting a component's preferred size greatly reduces
the number of cross-platform problems. There's a recent example here:

<https://groups.google.com/d/msg/comp.lang.java.programmer/BbU4GjYuD6E/H-QLV3BRmmsJ>

 

[Jim Janney]

Am 20.06.2012 17:33, schrieb owais:

Java is more like WOTA for me - write once, test everywhere. It's
quite acceptable for simple programs, but as soon as it gets more
complex than this, there are subtle differences between Java
installations on Windows and Linux, and from version to version. I've
seen cases where Java does not size windows correctly on one version,
but not on others for reasons that are not clear to me, where input
focus handling was slightly different and inconsistent, where refresh
handling and the order of requests is slightly different, where window
placement may or may not work... In theory, Java is very nice for
running everywhere, but you still need to test and need to tweak a bit
to get it working consistently.

A few years ago I was assigned the task of getting a Swing-based
program, developed under Windows, to run under Linux. At the time it
represented perhaps 30 to 40 programmer-years of work: not large by some
standards but not trivial either. Part of the build process included a
small set of unit tests and a much larger set of what amounted to
integration tests to load the program and run it through its paces:
these were originally written using jfcUnit but had evolved to the point
that no actual jfcUnit code was still in use. These tests normally took
somewhat over an hour to run.

It took me a few days to get the program to the point where you could
run and use it under Linux. There were some custom DLLs written in C++
that had to be recompiled, and a few odd things like Unicode constants
in the source code that needed to be replaced with their hex versions.
But I was never able to get the integration tests to pass, or even to
fail in the same places consistently. There was an issue with dialogs
that wouldn't go away -- I verified that the code to close them was
running and as far as Java was concerned they seemed to be gone, but you
could still see them on the screen. Also various random-seeming null
pointer exceptions and such-like. After I'd been working on it for
about four weeks management decided they didn't want it that much and
abandoned the effort.

The point here isn't that it can't be done. With enough time and
support from management I could have found and fixed the problems, or we
could have found someone who else who could. (I'm happy to say that
sending it to customers without passing the tests first was never on the
table.) But it certainly wasn't automatic. If you intend to deploy to
multiple platforms my advice would be to test on each platform right
from the start.

 

[Roedy Green]

I'll second the need for testing, but I've found that using layouts
properly and respecting a component's preferred size greatly reduces
the number of cross-platform problems. There's a recent example here:

one of the big problems is when you substitute a font, the characters
are not the same size. I would like to normalize fonts to their true
size so that when you substitute fonts, the actual real estate
consumed varies only a little.

Another would be a guaranteed to render all glyphs, even if it means
substituting from some other font. Failing that at telling the truth.
Java claims to render a glyph when all it does in render some generic
glyph.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Computers are machines that do exactly what you tell them,
but they still can surprise you with the results.
~ Dr. Richard Dawkins 1941-03-26