http://stackoverflow.com/questions/10895969/can-newer-jre-versions-run-java-programs-compiled-with-older-jdk-versions
You can run code compiled by the java 1.7 or 1.6 or earlier SDKs on a
Java 8 JVM.
This gets you the improved speed of the Java 8 JVM even if you do not
rebuild the code.
If this was not true, life would be chaos when you upgraded your Java on
a production server.
All of the code that ran a few minutes ago would fail.
Think about how much java is running on a typical data centre. You would
have heard the howls of pain if all that code suddenly stopped running.
It should be easy to test the existing jars compiled with earlier
version of java on a machine running the Java 8 JVM.
Just replace the Java and restart the server.
A reasonable migration path is to replace the JVM and continue to run
existing code.
Upgrade the code at your leisure.
An application can be constructed from Jars from different SDKs.
I had no trouble with the dozens of Apache and third party libraries
that make up my application when I changed my compiler to Java 8.
One minute I was compiling and testing with Java 7 and the next minute I
was compiling with Java 8 and the code still worked with all of the same
third party jars.
No source code changes where required in any code to upgrade.
Since then, I have incorporated Java 8 features into most of our code
but that is not really part of this discussion.
I hope that this helps.
Ron
Ron
On 21/02/2017 3:03 AM, Marc-Aurèle Brothier wrote:
No there isn't any issue except having the bugs & fixes of the JDK you're
using. You can compile it with a JDK 1.8 as long as you don't change the
target bytecode version for 1.7
On Tue, Feb 21, 2017 at 8:15 AM, Wei ZHOU <ustcweiz...@gmail.com> wrote:
Marco,
Good point. Is there any issue if we compile code with jdk8 but run it on
jdk7 (systemvm) ?
-Wei
2017-02-21 7:43 GMT+01:00 Marc-Aurèle Brothier <ma...@exoscale.ch>:
There's a list of compatibility issues between Java 7 & Java 8 here
http://www.oracle.com/technetwork/java/javase/8-
compatibility-guide-2156366.
html
The main problem I would see in two system communicating while running
different Java version is the way they handle serialization and
de-serialization of objects which had been a problem in the past between
some Java versions. AFAIK we're using JSON for that now, so if the code
already compiles with Java8, it should not be a problem.
On Mon, Feb 20, 2017 at 10:36 PM, Wei ZHOU <ustcweiz...@gmail.com>
wrote:
We tested 4.7.1+systemd patches as well, it also works fine.
-Wei
2017-02-20 22:34 GMT+01:00 Wei ZHOU <ustcweiz...@gmail.com>:
@Will and @Syed, I build the packages of 4.9.2+systemd patches on
ubuntu
16.04 (openjdk 8).
Then install the packages to management server and kvm hosts (all are
ubuntu 16.04 with openjdk8).
The systemvm template is 4.6 with openjdk7.
cpvm and ssvm work fine.
As there is no java process in VR, so I did not check, VR should not
be
impacted.
-Wei
2017-02-20 22:16 GMT+01:00 Pierre-Luc Dion <pd...@cloudops.com>:
That's quite interesting Chiradeep!
so I could do something like this I guest:
mvn clean install
and then this one to build the systemvm.iso:
mvn -Psystemvm -source 1.7 -target 1.7 install
I'll give it a try! but for now, I'm worried about existing VR, they
must
continue to work while running on jdk7. newer VPC would be ok to
run
with
jdk8. but we need to make sure while upgrading the
management-server
we
are not in the obligation to upgrade VR's.
For sure it is required for strongswan + JDK8 to ugprade the VR,
but a
existing VR should remain usable for port forwarding, vm creation
and
such...
I'll post my finding...
Thanks !
On Mon, Feb 20, 2017 at 3:59 PM, Chiradeep Vittal <
chirade...@gmail.com
wrote:
You can build the system vm with -source 1.7 -target 1.7
Also unless you are using Java8 features (lambda) the classfiles
produced
by javac 8 should work in a 1.7 JVM
Sent from my iPhone
On Feb 20, 2017, at 11:51 AM, Will Stevens <
wstev...@cloudops.com
wrote:
yes, that is what I was expecting. which is why I was asking
about
Wei's
setup because he seems to have worked around that problem. Or
he
has
a
custom SystemVM template running with both JDK7 and JDK8.
*Will STEVENS*
Lead Developer
<https://goo.gl/NYZ8KK>
On Mon, Feb 20, 2017 at 2:20 PM, Syed Ahmed <
sah...@cloudops.com
wrote:
The problem is that systemvm.iso is built with java 8 whereas
java
on
the
VR is java 7
On Mon, Feb 20, 2017 at 13:20 Will Stevens <
wstev...@cloudops.com
wrote:
Did it work after resetting a VPC or when blowing away the
SSVM
or
CPVM? I
would not expect the SSVM or the CPVM to come up if the
management
server
was built with JDK8 and the system vm template is only using
JDK7.
Can
you
confirm?
*Will STEVENS*
Lead Developer
<https://goo.gl/NYZ8KK>
On Mon, Feb 20, 2017 at 1:15 PM, Wei ZHOU <
ustcweiz...@gmail.com
wrote:
We've tested management server 4.7.1 with ubuntu
16.04/openjdk8
and
systemvm 4.6 with debian7/openjdk7.
The systemvms (ssvm, cpvm) work fine.
I agree we need consider the openjdk upgrade in systemvm
template.
-Wei
2017-02-20 18:15 GMT+01:00 Will Stevens <
wstev...@cloudops.com
:
Regarding my question. Is it because of the version of Java
that
the
systemvm.iso is built on?
On Feb 20, 2017 11:58 AM, "Will Stevens" <
wstev...@cloudops.com
wrote:
A question that is hidden in here is:
- Why does the JDK version on the management server have to
match
the
JDK
version of the System VM?
*Will STEVENS*
Lead Developer
<https://goo.gl/NYZ8KK>
On Mon, Feb 20, 2017 at 11:50 AM, Pierre-Luc Dion <
pd...@cloudops.com>
wrote:
Hi,
In the context of deployment of CloudStack with VPCs,
What will happen to a cloud when upgrading to 4.10 that
now
use
jdk8?
Does upgrading the management-server to 4.10 jdk8 and then
keep
the
old
VRs
run for a while that run on JDK7 will still work ?
Because If we upgrade the management-server to jdk8, we
need
to
keep
VR
to
work until they get upgraded but we can't force an upgrade
of
VR
just
because the management-server is now using JDK8.
Thanks,
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
