Difference between revisions of "GCube Java 8 migration guide"
(→JVM - TO COMPLETE) |
(→Other Incompatibilities) |
||
(31 intermediate revisions by the same user not shown) | |||
Line 10: | Line 10: | ||
= Source Code = | = Source Code = | ||
− | == Source Incompatibilities | + | == Source Incompatibilities == |
* Detected at integration time (the component does not build) | * Detected at integration time (the component does not build) | ||
Line 22: | Line 22: | ||
** suggested: 1.14.8 | ** suggested: 1.14.8 | ||
− | == | + | |
+ | ==== ETICS and javaws incompatibilities ==== | ||
+ | |||
+ | Some issues with artifact built by ETICS are provided. In particular with SmartExecutor which runs on Smartgears. Such issues does not happen if the user try to build locally SmartExecutor, SmartgearsDistribution and SmartgearsDistributionBundle. | ||
+ | |||
+ | In particular | ||
+ | If the user set this dependency on SmartExecutor | ||
+ | |||
+ | <dependency> | ||
+ | <groupId>com.sun.xml.ws</groupId> | ||
+ | <artifactId>jaxws-rt</artifactId> | ||
+ | <version>2.1.7</version> | ||
+ | </dependency> | ||
+ | |||
+ | The '''''java.lang.IllegalArgumentException: Argument(s) "type" can't be null at com.sun.xml.bind.api.TypeReference. <init>(TypeReference.java:89) ~[jaxb-impl-2.1.11.jar:2.1.11] ''''' is occurred. The full description of the exception can be found at : https://support.d4science.org/pastes/740ec053e84ac34cb1118ac5084cec1a6dbb2374. | ||
+ | |||
+ | Trying to use the following version depdencendy for jaxws: | ||
+ | |||
+ | <dependency> | ||
+ | <groupId>com.sun.xml.ws</groupId> | ||
+ | <artifactId>jaxws-rt</artifactId> | ||
+ | <version>2.2.10</version> | ||
+ | </dependency> | ||
+ | |||
+ | another exception is occured : | ||
+ | |||
+ | The ''''' java.lang.RuntimeException: MASM0015: Class [ com.sun.xml.ws.assembler.jaxws.HandlerTubeFactory ] does not implement | ||
+ | [ com.sun.xml.internal.ws.assembler.dev.TubeFactory ] interface at com.sun.xml.internal.ws.assembler.TubeCreator. <init> (TubeCreator.java:63) ~[na:1.8.0_121]'''''. | ||
+ | |||
+ | The full description can be found at: https://support.d4science.org/pastes/4ca7a2dd23215b6f5ce7a620412abc9db16ec12e. | ||
+ | |||
+ | The issues doesn't happen with the build locally for SmartExecutor, SmartgearsDistribution and SmartgearsDistributionBundle. | ||
+ | The local configuration user is: | ||
+ | |||
+ | Oracle Java 8, | ||
+ | $ java -version | ||
+ | java version "1.8.0_121" | ||
+ | Java(TM) SE Runtime Environment (build 1.8.0_121-b13) | ||
+ | Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode) | ||
+ | |||
+ | and | ||
+ | |||
+ | maven-compiler-plugin 3.6.2 | ||
+ | |||
+ | In the ETICS node the following configuration is used: | ||
+ | |||
+ | Java version: 1.8.0_91, vendor: Oracle Corporation | ||
+ | Java home: | ||
+ | /home/gbuilder/ workspace.org.gcube.4-3-0/repository/ externals/jdk/1.8.0_91/linux_x86_64/jre | ||
+ | maven-compiler-plugin to 3.6.1 | ||
+ | |||
+ | <br> | ||
+ | jaxb version is inherited from javaws-rt (jaxb-impl is the 2.1.11). That's occurred when the user try to update javaws-rt to obtain a more | ||
+ | recent version of jaxb. With javaws-rt 2.2.10 (the highest available on maven central) it's given jaxb-impl 2.2.10-b140802.1033 (2010 beta version) which seems too the latest available. | ||
+ | - '''Problem''' | ||
+ | javaws-rt is not a SmartExecutor requirement but is needed from common libraries to made calls and the problem is a runtime problem throw from dependency of dependency. | ||
+ | <br> | ||
+ | |||
+ | '''- Solution''': | ||
+ | The user local build works fine , only remote build doesn't work. The solution seems from compiler point of view otherwise it could have a huge impact on common library development. | ||
+ | <br> | ||
+ | It was caused by a compilatoin or java runtime bug fixed in one of the patches between jdk 1.8.0_91 and jdk 1.8.0_121. | ||
+ | |||
+ | Updating of the jdk 8u121 in ETICS to test the artefactbuild in ETICS. The change is made permanent and set the jdk version for candidate release builds. | ||
+ | |||
+ | |||
+ | ==== Incompatibility during updating of the registry service for some nodes ==== | ||
+ | Incompatibilities during the updating of the registry service (node9-d-d4s) [https://support.d4science.org/issues/6306 #6306] | ||
+ | In particular the issue occurred | ||
+ | <cite> | ||
+ | after the replacing of Xerces and xml-api libraries, | ||
+ | </cite> | ||
+ | where | ||
+ | <cite> | ||
+ | the gCore container doesn't start with the following exception: | ||
+ | </cite> | ||
+ | <pre> | ||
+ | 2017-02-16 17:20:20,037 FATAL contexts.GHNContext [Initialiser,fatal:76] [0.663s] GHNContext: gHN could not complete initialisation | ||
+ | java.lang.NoSuchMethodError: org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar([Lorg/apache/xerces/xni/parser/XMLInputSource;)V | ||
+ | at org.apache.xerces.jaxp.validation.XMLSchemaFactory.newSchema(Unknown Source) | ||
+ | at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:638) | ||
+ | at org.gcube.common.resources.kxml.KGCUBEResource.getSchema(KGCUBEResource.java:170) | ||
+ | at org.gcube.common.resources.kxml.KGCUBEResource.load(KGCUBEResource.java:80) | ||
+ | at org.gcube.common.resources.kxml.node.KGCUBEHostingNode.load(KGCUBEHostingNode.java:18) | ||
+ | at org.gcube.common.core.contexts.GHNContext.loadGHNResource(GHNContext.java:405) | ||
+ | at org.gcube.common.core.contexts.GHNContext.configureGHNResource(GHNContext.java:384) | ||
+ | at org.gcube.common.core.contexts.GHNContext.initialise(GHNContext.java:291) | ||
+ | at org.gcube.common.core.contexts.GHNContext.<clinit>(GHNContext.java:261) | ||
+ | at org.gcube.common.core.contexts.GCUBEServiceContext$Initialiser.onRIDeployed(GCUBEServiceContext.java:677) | ||
+ | at org.gcube.common.core.contexts.service.Consumer.onEvent(Consumer.java:30) | ||
+ | at org.gcube.common.core.utils.events.GCUBEProducer$2.run(GCUBEProducer.java:176) | ||
+ | </pre> | ||
+ | |||
+ | ''' - Solution''': see you the previous issue to solve it. | ||
+ | ==== Maven Compiler Plugin ==== | ||
+ | maven-parent is updated with the version of maven-compiler-plugin to use and in order to avoid incompatibility with all components that use Java7 yet. | ||
+ | The reccomendation is to update its pom configuration to remove from the build phase the reference about the maven-compiler-plugin and as soon as possible migrate to Java8. | ||
+ | |||
+ | == Behaviour Incompatibilities == | ||
* Cannot be detected at development and integration time | * Cannot be detected at development and integration time | ||
* We will need to carefully test our artifacts | * We will need to carefully test our artifacts | ||
− | == Other Incompatibilities | + | == Other Incompatibilities == |
− | + | ||
− | * Java8 required as pre-requisited the latest TOMCAT version as reported in the https://support.d4science.org/issues/6306: | + | *'''TOMCAT incopatibily''' |
+ | Java8 required as pre-requisited the latest TOMCAT version as reported in the https://support.d4science.org/issues/6306: | ||
− | |||
Moving to the latest tomcat version is not so easy. We want to stuck with the distribution provided tomcat for a lot of reasons: | Moving to the latest tomcat version is not so easy. We want to stuck with the distribution provided tomcat for a lot of reasons: | ||
+ | *backport of bug and security fixes | ||
+ | *compatibility with the apr libraries | ||
+ | *In addition to that, the javassist exceptions were a cosmetic only problem in the past, and an upgrade to a newer version of javassist was planned. | ||
− | + | The solution is : | |
− | + | ||
− | + | ||
− | + | ||
− | The solution | + | |
* for gCore : updating the xerces and xml-api libraries to make the gCore services working; | * for gCore : updating the xerces and xml-api libraries to make the gCore services working; | ||
* for Smartgears: upgrade on ubuntu 14.04 all the development and production infrastructure. This should be resolved the problems manifested for the javassist and xml parsing. | * for Smartgears: upgrade on ubuntu 14.04 all the development and production infrastructure. This should be resolved the problems manifested for the javassist and xml parsing. | ||
+ | <pre> | ||
+ | Due to the split of the release in gCore and Smartgear components the migration and possible resolution of the issue are provided both. | ||
+ | </pre> | ||
− | + | *'''GWT Web Toolkit incompatibilty''' | |
− | = JVM | + | Java8 requires a version higher than 2.6.x and 2.7.x : latest. |
+ | |||
+ | An tipycal error during the build was reported: | ||
+ | |||
+ | ''[ERROR] Failed to execute goal org.codehaus.mojo:gwt-maven-plugin:2.6.1''. | ||
+ | |||
+ | This becasue the source level for the Java must be 1.6, 1.7. | ||
+ | Infact gwt-maven-pluing 2.6.1 is not supported by Java8 as suggested in this http://stackoverflow.com/questions/33653943/codehaus-mojo-gwt-maven-plugin-project-fails-to-compile. | ||
+ | <br> | ||
+ | As the same for the 2.7.x gwt version, as reported in the following link http://stackoverflow.com/questions/29915564/upgrading-java-7-to-java-8-using-gwt-2-6: | ||
+ | <pre> | ||
+ | GWT will support Java8 from version 2.8 onwards. | ||
+ | </pre> | ||
+ | |||
+ | Two possibilities are suggested: | ||
+ | |||
+ | - update to the last version of gwt (rif. http://stackoverflow.com/questions/33653943/codehaus-mojo-gwt-maven-plugin-project-fails-to-compile): 2.7 for example; | ||
+ | |||
+ | - force the java version to the 1.7 as prodived in the wiki page: [https://wiki.gcube-system.org/gcube/Developing_gCube_Maven_Components#Java_Version Java_Version]. | ||
+ | |||
+ | More details in the following REdmine Task Issue: | ||
+ | *[https://support.d4science.org/issues/8396 #8396], | ||
+ | *[https://support.d4science.org/issues/8395 #8395], | ||
+ | *[https://support.d4science.org/issues/8407 #8407], | ||
+ | *[https://support.d4science.org/issues/8408 #8408], | ||
+ | *[https://support.d4science.org/issues/8409 #8409], | ||
+ | *[https://support.d4science.org/issues/8484 #8484]. | ||
+ | <p> | ||
+ | *''' Smartgears Container and Oracle-Java8 build 161''' | ||
+ | After the migration to Java8 (1.8.0_161) on Ubuntu repositories an important incompatibility has been occurred from Smartgears container and this version of java. All developers has been invited to check the java version present on their node and not upgrade it if < "1.8.0_161": | ||
+ | *[https://support.d4science.org/issues/11013 #11013], | ||
+ | *[https://support.d4science.org/issues/11020 #11020]. | ||
+ | |||
+ | = JVM = | ||
JVM memory management changed in Java 8: concept of PermGen space has been replaced by Metaspace. As consequence, startup options used in Java 7 (e.g. "-XX:MaxPermSize") rae not valid anymore in JVM 8. | JVM memory management changed in Java 8: concept of PermGen space has been replaced by Metaspace. As consequence, startup options used in Java 7 (e.g. "-XX:MaxPermSize") rae not valid anymore in JVM 8. | ||
− | |||
− | |||
− | + | Set Java 8 as the default JVM for all the development servers managed by Ansible. A new provisioning run is needed to install the new packages and reconfigure the services. On the smartgears-based nodes this can be done running the playbook(s) with the tags: jdk,tomcat | |
+ | '''List of the nodes migrated''': | ||
* node26.d.d4science.research-infrastructures.eu migrated (no java app running on this host) | * node26.d.d4science.research-infrastructures.eu migrated (no java app running on this host) | ||
* node24.d.d4science.research-infrastructures.eu migrated (smartgears or ghn was not running on this host, only postgresql) | * node24.d.d4science.research-infrastructures.eu migrated (smartgears or ghn was not running on this host, only postgresql) | ||
Line 57: | Line 189: | ||
* obis2.i-marine.research-infrastructures.eu alias geoserver-dev2.d4science-ii.research-infrastructures.eu migrated (no java app running on this host, only postgresql) | * obis2.i-marine.research-infrastructures.eu alias geoserver-dev2.d4science-ii.research-infrastructures.eu migrated (no java app running on this host, only postgresql) | ||
* dev.d4science.org migrated (no java app running on this host, only postgresql) | * dev.d4science.org migrated (no java app running on this host, only postgresql) | ||
− | |||
− | |||
− | |||
To migrate old ghn dev (ubuntu 8.04) as node1.d.d4science , node4.d.d4science , node5.d.d4science, new nodes are created : | To migrate old ghn dev (ubuntu 8.04) as node1.d.d4science , node4.d.d4science , node5.d.d4science, new nodes are created : | ||
− | + | * node9-d-d4s.d4science.org (registry service) | |
− | * node9-d-d4s.d4science.org | + | |
* node4.d.d4science | * node4.d.d4science | ||
* node5.d.d4science | * node5.d.d4science | ||
− | To migrate the | + | To migrate the olg ghn dev to Java8 the first step is update the old OS : |
− | *node11.d.d4science.research-infrastructures.eu Ubuntu 9.04 32-bit | + | *node11.d.d4science.research-infrastructures.eu : Ubuntu 9.04 32-bit |
− | *node13.d.d4science.research-infrastructures.eu Ubuntu 9.04 32-bit | + | *node13.d.d4science.research-infrastructures.eu : Ubuntu 9.04 32-bit |
− | *node20.d.d4science.research-infrastructures.eu Ubuntu 9.04 32-bit | + | *node20.d.d4science.research-infrastructures.eu : Ubuntu 9.04 32-bit |
− | *node15.d.d4science.research-infrastructures.eu Ubuntu 9.10 64-bit | + | *node15.d.d4science.research-infrastructures.eu : Ubuntu 9.10 64-bit |
The first step has been creating a new hosts: | The first step has been creating a new hosts: | ||
− | * node11-d-d4s.d4science.org ( | + | * node11-d-d4s.d4science.org (replaced node11.d.d4science) |
− | + | ||
− | </ | + | '''TO UPDATE''' |
+ | <pre> | ||
+ | *node12-d-d4s.d4science.org (it'll replace node13.d.d4science.research-infrastructures.eu) | ||
+ | *node13-d-d4s.d4science.org (it'll replace node15.d.d4science.research-infrastructures.eu) | ||
+ | *node14-d-d4s.d4science.org (it'll replace node20.d.d4science.research-infrastructures.eu) | ||
+ | </pre> | ||
= References = | = References = |
Latest revision as of 12:28, 24 January 2018
This page collects the guidelines for the migration of D4Science infrastructure and the gCUbe software from Java 7 to Java 8. It also collects common issues (and their solution) experienced during the migration as reference for all gCube developers.
There are (few) documented incompatibilities between Java 7 and Java 8.
Running into one of them will require to re-factor the component and release a new version of it.
Java 8 compatibility guide: http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html
Contents
Source Code
Source Incompatibilities
- Detected at integration time (the component does not build)
- animal-sniffer-maven-plugin can be used by developers to detect them at development time
Dependencies
Some third-party libraries are not compiled in Java 8 and their code is not Java 8 compatible. This is usually the case of very old versions.
- lombok
- not compatible: 0.11.6
- suggested: 1.14.8
ETICS and javaws incompatibilities
Some issues with artifact built by ETICS are provided. In particular with SmartExecutor which runs on Smartgears. Such issues does not happen if the user try to build locally SmartExecutor, SmartgearsDistribution and SmartgearsDistributionBundle.
In particular If the user set this dependency on SmartExecutor
<dependency> <groupId>com.sun.xml.ws</groupId> <artifactId>jaxws-rt</artifactId> <version>2.1.7</version> </dependency>
The java.lang.IllegalArgumentException: Argument(s) "type" can't be null at com.sun.xml.bind.api.TypeReference. <init>(TypeReference.java:89) ~[jaxb-impl-2.1.11.jar:2.1.11] is occurred. The full description of the exception can be found at : https://support.d4science.org/pastes/740ec053e84ac34cb1118ac5084cec1a6dbb2374.
Trying to use the following version depdencendy for jaxws:
<dependency> <groupId>com.sun.xml.ws</groupId> <artifactId>jaxws-rt</artifactId> <version>2.2.10</version> </dependency>
another exception is occured :
The java.lang.RuntimeException: MASM0015: Class [ com.sun.xml.ws.assembler.jaxws.HandlerTubeFactory ] does not implement [ com.sun.xml.internal.ws.assembler.dev.TubeFactory ] interface at com.sun.xml.internal.ws.assembler.TubeCreator. <init> (TubeCreator.java:63) ~[na:1.8.0_121].
The full description can be found at: https://support.d4science.org/pastes/4ca7a2dd23215b6f5ce7a620412abc9db16ec12e.
The issues doesn't happen with the build locally for SmartExecutor, SmartgearsDistribution and SmartgearsDistributionBundle. The local configuration user is:
Oracle Java 8, $ java -version java version "1.8.0_121" Java(TM) SE Runtime Environment (build 1.8.0_121-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
and
maven-compiler-plugin 3.6.2
In the ETICS node the following configuration is used:
Java version: 1.8.0_91, vendor: Oracle Corporation Java home: /home/gbuilder/ workspace.org.gcube.4-3-0/repository/ externals/jdk/1.8.0_91/linux_x86_64/jre maven-compiler-plugin to 3.6.1
jaxb version is inherited from javaws-rt (jaxb-impl is the 2.1.11). That's occurred when the user try to update javaws-rt to obtain a more
recent version of jaxb. With javaws-rt 2.2.10 (the highest available on maven central) it's given jaxb-impl 2.2.10-b140802.1033 (2010 beta version) which seems too the latest available.
- Problem
javaws-rt is not a SmartExecutor requirement but is needed from common libraries to made calls and the problem is a runtime problem throw from dependency of dependency.
- Solution:
The user local build works fine , only remote build doesn't work. The solution seems from compiler point of view otherwise it could have a huge impact on common library development.
It was caused by a compilatoin or java runtime bug fixed in one of the patches between jdk 1.8.0_91 and jdk 1.8.0_121.
Updating of the jdk 8u121 in ETICS to test the artefactbuild in ETICS. The change is made permanent and set the jdk version for candidate release builds.
Incompatibility during updating of the registry service for some nodes
Incompatibilities during the updating of the registry service (node9-d-d4s) #6306 In particular the issue occurred after the replacing of Xerces and xml-api libraries, where the gCore container doesn't start with the following exception:
2017-02-16 17:20:20,037 FATAL contexts.GHNContext [Initialiser,fatal:76] [0.663s] GHNContext: gHN could not complete initialisation java.lang.NoSuchMethodError: org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar([Lorg/apache/xerces/xni/parser/XMLInputSource;)V at org.apache.xerces.jaxp.validation.XMLSchemaFactory.newSchema(Unknown Source) at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:638) at org.gcube.common.resources.kxml.KGCUBEResource.getSchema(KGCUBEResource.java:170) at org.gcube.common.resources.kxml.KGCUBEResource.load(KGCUBEResource.java:80) at org.gcube.common.resources.kxml.node.KGCUBEHostingNode.load(KGCUBEHostingNode.java:18) at org.gcube.common.core.contexts.GHNContext.loadGHNResource(GHNContext.java:405) at org.gcube.common.core.contexts.GHNContext.configureGHNResource(GHNContext.java:384) at org.gcube.common.core.contexts.GHNContext.initialise(GHNContext.java:291) at org.gcube.common.core.contexts.GHNContext.<clinit>(GHNContext.java:261) at org.gcube.common.core.contexts.GCUBEServiceContext$Initialiser.onRIDeployed(GCUBEServiceContext.java:677) at org.gcube.common.core.contexts.service.Consumer.onEvent(Consumer.java:30) at org.gcube.common.core.utils.events.GCUBEProducer$2.run(GCUBEProducer.java:176)
- Solution: see you the previous issue to solve it.
Maven Compiler Plugin
maven-parent is updated with the version of maven-compiler-plugin to use and in order to avoid incompatibility with all components that use Java7 yet. The reccomendation is to update its pom configuration to remove from the build phase the reference about the maven-compiler-plugin and as soon as possible migrate to Java8.
Behaviour Incompatibilities
- Cannot be detected at development and integration time
- We will need to carefully test our artifacts
Other Incompatibilities
- TOMCAT incopatibily
Java8 required as pre-requisited the latest TOMCAT version as reported in the https://support.d4science.org/issues/6306:
Moving to the latest tomcat version is not so easy. We want to stuck with the distribution provided tomcat for a lot of reasons:
- backport of bug and security fixes
- compatibility with the apr libraries
- In addition to that, the javassist exceptions were a cosmetic only problem in the past, and an upgrade to a newer version of javassist was planned.
The solution is :
- for gCore : updating the xerces and xml-api libraries to make the gCore services working;
- for Smartgears: upgrade on ubuntu 14.04 all the development and production infrastructure. This should be resolved the problems manifested for the javassist and xml parsing.
Due to the split of the release in gCore and Smartgear components the migration and possible resolution of the issue are provided both.
- GWT Web Toolkit incompatibilty
Java8 requires a version higher than 2.6.x and 2.7.x : latest.
An tipycal error during the build was reported:
[ERROR] Failed to execute goal org.codehaus.mojo:gwt-maven-plugin:2.6.1.
This becasue the source level for the Java must be 1.6, 1.7.
Infact gwt-maven-pluing 2.6.1 is not supported by Java8 as suggested in this http://stackoverflow.com/questions/33653943/codehaus-mojo-gwt-maven-plugin-project-fails-to-compile.
As the same for the 2.7.x gwt version, as reported in the following link http://stackoverflow.com/questions/29915564/upgrading-java-7-to-java-8-using-gwt-2-6:
GWT will support Java8 from version 2.8 onwards.
Two possibilities are suggested:
- update to the last version of gwt (rif. http://stackoverflow.com/questions/33653943/codehaus-mojo-gwt-maven-plugin-project-fails-to-compile): 2.7 for example;
- force the java version to the 1.7 as prodived in the wiki page: Java_Version.
More details in the following REdmine Task Issue:
- Smartgears Container and Oracle-Java8 build 161
JVM
JVM memory management changed in Java 8: concept of PermGen space has been replaced by Metaspace. As consequence, startup options used in Java 7 (e.g. "-XX:MaxPermSize") rae not valid anymore in JVM 8.
Set Java 8 as the default JVM for all the development servers managed by Ansible. A new provisioning run is needed to install the new packages and reconfigure the services. On the smartgears-based nodes this can be done running the playbook(s) with the tags: jdk,tomcat
List of the nodes migrated:
- node26.d.d4science.research-infrastructures.eu migrated (no java app running on this host)
- node24.d.d4science.research-infrastructures.eu migrated (smartgears or ghn was not running on this host, only postgresql)
- node27.d.d4science.research-infrastructures.eu migrated (old smartgears tomcat restarted with java8)
- obis2.i-marine.research-infrastructures.eu alias geoserver-dev2.d4science-ii.research-infrastructures.eu migrated (no java app running on this host, only postgresql)
- dev.d4science.org migrated (no java app running on this host, only postgresql)
To migrate old ghn dev (ubuntu 8.04) as node1.d.d4science , node4.d.d4science , node5.d.d4science, new nodes are created :
- node9-d-d4s.d4science.org (registry service)
- node4.d.d4science
- node5.d.d4science
To migrate the olg ghn dev to Java8 the first step is update the old OS :
- node11.d.d4science.research-infrastructures.eu : Ubuntu 9.04 32-bit
- node13.d.d4science.research-infrastructures.eu : Ubuntu 9.04 32-bit
- node20.d.d4science.research-infrastructures.eu : Ubuntu 9.04 32-bit
- node15.d.d4science.research-infrastructures.eu : Ubuntu 9.10 64-bit
The first step has been creating a new hosts:
- node11-d-d4s.d4science.org (replaced node11.d.d4science)
TO UPDATE
*node12-d-d4s.d4science.org (it'll replace node13.d.d4science.research-infrastructures.eu) *node13-d-d4s.d4science.org (it'll replace node15.d.d4science.research-infrastructures.eu) *node14-d-d4s.d4science.org (it'll replace node20.d.d4science.research-infrastructures.eu)
References
- Oracle releases plan
http://www.oracle.com/technetwork/java/eol-135779.html
- New features in Java 8
- Compatibility guide
http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html
- Animal Sniffer Plugin Guide