We are a 3rd party software vendor who enjoys tons of issues with Java
versions that we specify in the properties files. We spend more time
supporting that one aspect of our software (one little comm job) than all of
the other hundreds of thousands of lines of RPG/CL and the associated logic.
However, I have never been aware of anyone actually 'removing' a version, so
I cannot speak to that symptom.
We do not do that in our own testing of the ONE (stinking) Java program (out
of hundreds of RPG/CL) that we deliver to customers. All of our testing is
done on systems that have all prior versions installed.
Having said that, there are multiple ways to specify the Version, using an
exported environment variable, in the global props file, User props file for
the profile that starts the code, and in the local props file. We use the
last method, and each method has great differences.
We have found that each implementation of a new version of Java has
fundamental changes to the (expected) locations of folders and content. We
have fought over the last 10 years to use the most generic code humanly
possible, and that is a challenge, but we have stabilized on code that works
well for all Java versions from 1.4 on up. That does not take into account
that some versions are unusable due to encryption (SSL/TLS) issues that are
insurmountable.
Bottom line, Java was pitched as "Write once, Run everywhere," and we have
found it to be "Write once, TEST everywhere."
And woe be unto you if you approach IBM with a Java issue that does NOT
involve dreaded Websphere (that we do not use at all). They generally claim
that they do not support independent use of Java outside of Websphere. We
have tried to use RPGIV for the high speed communications, and have never
been able to match the communications performance of Java. That is why we
use it as the ONE job that performs comms, and everything else in our system
is CL and RPG.
Ira Chandler
Curbstone Corporation
Technical Services - 888-844-8533
https://curbstone.com/email_disclaimer
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Thursday, January 28, 2016 12:55 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Changing java versions
Suppose you're a third party vendor of IBM i software, and you select what
version of java you run based simply on some properties or ini file, or some
environment variable, have you run into problems by anyone changing your
supplied version from JDK 6 to 7 or 8?
Have you tested that?
Have you tested that by completely removing JDK 6 from the system?
I've ran into one issue where a vendor allows you to select the level of
java with a ini file, and I tried jdk7. And it worked and their verify
command says I'm using jdk7. However if I remove jdk6 from the system it
says I'm trying to use an unsupported version of java on start up. I
suspect they do some prereq check that's coded poorly.
However I'm just interested if things should pretty much run as good or
better by changing from java 6 to 7 (or 8). At least no fatal errors. I'm
pretty java ignorant.
Rob Berendt
midrange.com
