Building with Java 1.8 and deploying in Java 1.7

Question

Our existing web application is developed using JDK 1.6 and built using maven(2.2.1). The built artifacts(war/ear) is deployed to an environment using Java 7.

As of June 2018 the legacy protocols TLS 1.0 & 1.1 protocols will no longer be supported by various products such as Maven, JFrog. Any client accessing maven or JFrog needs to use TLS 1.2. We are using Bamboo for CI which currently uses JDK 1.6 for building and currently all the builds are failing due to the legacy protocols. Building with Java 1.8 solves the issues but what i am not sure is will there be any issues if i build(maven) with Java 1.8 and deploy the artifacts(war/ear) into an environment using Java 1.7. Any pointers will be helpful.

Update -1

We decided to add the build version to java 1.8 since when we try to build(maven) using Java version 1.7.0_80 we are getting the below error:

    [DEBUG] Error transferring file: Received fatal alert: handshake_failure
org.apache.maven.wagon.TransferFailedException: Error transferring file: Received fatal alert: handshake_failure
        at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:143)
        at org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116)
        at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88)
        at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)
        at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:546)
        at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:427)
        at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:382)
        at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:216)
        at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:90)
        at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:558)
        at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251)
        at org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:277)
        at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:205)
        at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:184)
        at org.apache.maven.plugin.DefaultPluginManager.loadPluginDescriptor(DefaultPluginManager.java:1642)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1540)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1503)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:1282)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:534)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
        at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
        at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1979)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1086)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343)
        at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
        at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1301)
        at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:468)
        at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338)
        at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:115)

Java 1.8 solves the build failure but what i am not sure is will there be any issues if i deploy the artifacts(war/ear) into an environment using Java 1.7

Update - 2 As mentioned by khmarbaise i used toolchains for my scenario and below are the details:

MAVEN_JAVA_HOME & JAVA_HOME - path to JDK 1.8

Maven version - 2.2.1

Updated my Application parent pom.xml to include toolchain plugin as shown below:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-toolchains-plugin</artifactId>
<version>1.1</version>
<executions>
  <execution>
    <goals>
      <goal>toolchain</goal>
    </goals>
  </execution>
</executions>
<configuration>
  <toolchains>
    <jdk>
      <version>1.6</version>
      <vendor>sun</vendor>
    </jdk>
  </toolchains>
</configuration>

The toolchains.xml file(see below) is the configuration file where you set the installation paths of your toolchains. I have placed this file in /.m2 directory.

 <?xml version="1.0" encoding="UTF8"?>
<toolchains>
  <!-- JDK toolchains -->
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>1.6</version>
      <vendor>sun</vendor>
    </provides>
    <configuration>
      <jdkHome>C:\Program Files\Java\jdk1.6.0_45</jdkHome>
    </configuration>
  </toolchain>
</toolchains>

I have verified in my local the build was successful. I need to verify how to pass toolchain.xml file to my bamboo configurations.

Refer https://maven.apache.org/guides/mini/guide-using-toolchains.html for details about how to configure toolchains.

Maven can build for an older platform; see https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html. But it is better to update your target platform. (Java 7 is EOL'd ...) — Stephen C, Jun 29 '18 at 13:30
Correct setup to handle such things building with JDK 7 or 8 but building for target 6 is to use toolchains... — khmarbaise, Jun 29 '18 at 15:30
I bad read your question. I though that the TLS was required at runtime too. But no just for the build ! My bad, sorry ! If all is working you should add an answer rather than editing your post. It could help others. I deleted my post. @khmarbaise could have done it too. — davidxxx, Jun 29 '18 at 17:21

score 1 · Answer 1 · answered Jun 29 '18 at 21:12

As mentioned by khmarbaise i used toolchains for my scenario and below are the details: