Java 6 Sunset and Upgrade Home (2016)

Document created by rich_patterson Employee on Feb 29, 2016Last modified by mike_aronson on Mar 20, 2017
Version 7Show Document
  • View in full screen mode

This document is your one-stop source for information regarding the Java 6 sunset and what you need to do to ensure continued operation of your Atoms and Molecules. Below you will find general information, important dates, and important execution behavior differences with Java 8.

 

CRITICAL: Local atoms on Java 6 will stop running as of May 4, 2016. You must upgrade your atom prior to this date to ensure your processes continue to run.

 

TIP: Follow this document to be notified of updates.

 

 

Reference Guide Articles

Here are some links to our Reference Guide

 

General Information

 

What is Dell Boomi's plan to upgrade to Java 8?

In Dell Boomi’s continuous efforts to provide the highest quality of service to our customers, Dell Boomi has implemented a plan for upgrading to Java 8. Please take note of the following key dates:

  • July 22: Java 8 upgraded on the Dell Boomi Test Atom Cloud and EU Atom Cloud.
  • August 5: Java 8 Atom and Molecule upgraders/installers released.
  • September 16 : Java 8 upgraded on the Dell Boomi Production Atom Cloud.
  • October 7: Java 8 Cloud upgraders and installers released (for any Clouds not managed by Dell Boomi).
  • November 4: Java 6 support officially ended.
  • May 4, 2016: Processes running on Java 6 will no longer run.

 

What are the advantages of Java 8 over Java 7?

  • For Improved Security:
    • Java 8 contains patches that will make the application more secure and less vulnerable
  • Sustainability:
    • Java 6 is no longer supported by Oracle, and therefore will no longer receive security patches and software updates.  Oracle will discontinue support of Java 7 in the near future.
  • Latest Technology:
    • By staying up to date with the latest technology, Dell Boomi will be able to utilize the enhanced performance and features available with the new tools.  As soon as Java 9 is available, Dell Boomi will begin to plan this transition as well.

 

What do I need to do to upgrade?

Information related to the Java upgrade is located in the Java Upgrade FAQ in the documentation. We can also answer any questions you may have about upgrading—just contact Dell Boomi Customer Support through normal channels for assistance.

 

Will I be able to upgrade directly from Java 6 to 8? If so, will I have to do anything differently?

Yes, you will be able to upgrade directly from Java 6 to 8. The Java 7 upgrader has been replaced with a Java 8 upgrader which allows the installer to detect and run on Java 8. Other than that, the upgraders will operate in exactly the same way.

 

Will I still be able to run on Java 6 or Java 7 when using the Java 8 installers?

You will only be able to run with either Java 7 (Should it be already installed) or Java 8. Java 6 is no longer detected by the installer and will be unavailable for use.

 

What does “end of official support” really mean?

We will officially stop supporting Java 6 in November, 2015.  If you have a Java 6 specific issue, the only workaround may be to upgrade your version of Java.

 

Will my processes continue to run after the end of official support?

When we end runtime support for Java 6 in May, 2016, the release will prevent Atoms, Molecules, and Clouds running on Java 6 from restarting. We encourage you to upgrade as soon as possible to prevent any disruption in the execution of your processes.

 

During this transition period, Dell Boomi will continue to support Java 6 and Java 7 concurrently for your production processes. This will give you time to migrate to Java 8. In the meantime, if you have any questions, please contact the Customer Success team.

 

If I have a local atom, do I have a dependency on the upgrade of Dell Boomi Atom Clouds?

Upgrading the Dell Boomi hosted Atom Clouds is independent of upgrading local atoms.  After the upgraders are released, you may upgrade your local atoms, molecules or clouds at any time, independent of our scheduled upgrades to the Dell Boomi Atom Clouds, however you may wish to follow a schedule similar to the one above, and certainly before the end of Java 6 support.

 

Who do I contact if I have questions?

Please contact the Dell Boomi Customer Success team at customersuccess@boomi.com or open a Support Case

 

Upgrade FAQ

 

What version of Java should I use, and where can I download the appropriate tools?

Currently, the Dell Boomi Atom Clouds use version 1.8.0_31-b13.

 

To upgrade an existing atom, you may download the appropriate upgrade scripts from atom management, or from one of links at the bottom of this topic. The upgrade tools should automatically install the same version of java as used by the Dell Boomi Atom Cloud.

 

When installing a new Atom from scratch, it will attempt to use the latest version of Java available on the system.  If a compatible version is not available, then the installer will download and install one automatically.  If required, you can reconfigure your atom to use a different version by updating the pref_jre.cfg file, as described in the Reference Guide.

 

If necessary, you can also download and install Java 8 manually, via the following links:

 

Download Links for Dell Boomi Install / Upgrade tools:

 

Behavior Differences FAQ

 

After upgrading to Java 8, the order of the rows produced by the Map shapes may change. Why did this happen?

Output of rows from a map shape may be in a different order between Java 7 and 8. If you depend on a particular order or doing a comparison with a run from another java version, your integration may not work as you expected.  You may also notice the difference in order, if you use custom scripting and depend on the order of output from a set or map

 

The implementation of HashMap and HashSet changed in Java 8, resulting in potential ordering differences.

 

As a Best Practice, you should never depend on order from the output of the map shape. In your custom scripts, you should not depend on the order of output from a java map or set.  Within AtomSphere, iteration order has always been undefined and should not be relied upon.

 

The Salesforce Connector will no longer work on Java 6. What should I do?

In April of 2016, Salesforce will disable TLS 1.0, and integrations utilizing the Salesforce API, including the Salesforce Connector, will no longer function under Java 6.  Customers will generally need to use Java 8 or higher to enable TLS 1.1 and TLS 1.2 in call-outs by default.

 

Another option is to use Java 7 and enable TLS 1.1 and/or TLS 1.2 using the https.protocols Java system property.  If using a custom connector, it may be possible to change code to enable TLS 1.1 and TLS 1.2 on SSLSocket and SSLEngine instances.

 

See Salesforce Disabling TLS 1.0 (2017) for more information.

 

My JDBC-ODBC Bridge is no longer working. How can I fix this?

If you upgrade to Java 8 and attempt to use the JDBC-ODBC bridge, you may receive this error while using the database connector:

java.lang.ClassNotFoundException: sun.jdbc.odbc.JdbcOdbcDriver

 

Solution:

Starting with JDK 8, the JDBC-ODBC Bridge is no longer included with the JDK.

 

The JDBC-ODBC Bridge has always been considered transitional and a non-supported product that was only provided with select JDK bundles and not included with the JRE. Instead, use a JDBC driver provided by the vendor of the database or a commercial JDBC Driver instead of the JDBC-ODBC Bridge, such as jTDS.

 

Java 7 will still be compatible with JDBC-ODBC.

 

Why do I see two instances of the Atom.exe process running after the Java 8 Upgrade?

Due to an updated version of install4j ( a tool used during the AtomSphere install ), you may see two instances of the atom.exe running. This change was made to help improve the stability of the JVM, and to improve the restart capability.  We do not anticipate any impact on atom functionality. This extra process consumes only a very small amount of memory, and very little CPU.

 

Why does the string split function differently between Java 7 and Java 8?

The behavior is different because our underlying String.split logic (which calls Pattern.split), specifically when done on an empty String, calls Java's native string split. The implementation of that is different between Java 7 and Java 8.

 

When there is a positive-width match at the beginning of this string then an empty leading substring is included at the beginning of the resulting array. A zero-width match at the beginning however never produces such empty leading substring.

 

For example: the string “01234” when specifying a null delimiter, turns into [ “null”, “0”, “1”, “2”, “3”, “4” ] in java 7, but in java 8 it will be like  [ “0”, “1”, “2”, “3”, “4” ].

 

This behavior is also documented in java 8 documentation: String (Java Platform SE 8 )

Note : The difference is really only exposed, when you try to split without specifying a delimiter ( or specifying a null delim )

 

Why am I getting JavaScript Errors after migrating to Java 8?

The JavaScript scripting engine has changed in Java 8 compared to Java 6 and Java 7. If you use JavaScript in some of your Custom Scripting, you might see errors as there are some syntax differences.

 

Please check your JavaScript and refer to the below link to check if you need to make any changes for the Java 8 scripting engine.

https://wiki.openjdk.java.net/display/Nashorn/Rhino+Migration+Guide

 

Why am I not getting any stack traces after atom crashes?

This is due to a JVM bug.  In the Windows event log you'll see an application error event in module MSVCR100.dll.

 

Update your <atom_install>/bin/atom.vmoptions file, and add the following ( you will need to restart the atom ):

-Djava.awt.headless=true
  • Note that if users are running a Windows atom in Desktop mode, the Boomi atom icon will no longer appear in the icon tray. But if users use or wish to see the Boomi atom icon, then rollback to Java 7 by following this guidance:
  • When the issue is fixed by Boomi, Customers should remove the atom property and restart the atom.

 

Why does my JAXP / Implementation throw errors?

This issue may affect some cloud owners, who specify an alternative JAXP implementation, and who have customers who define or use extension functions in custom scripting or custom jars.  In some cases, the following errors may appear in the container logs:

cassCastException for javax.xml.* or org.w3c.* classes

 

There may also be new or buggy behavior when using extension functions in an xpath, but only when you  use a 3rd party DOM implementation. In general, theNodeSet structure is expected to be compatible with that of the JDK default implementation.

 

Solution:

The only workaround would be to rewrite your xpath query or code into manual code that does not use extension functions.

 

Why am I getting Garbage Collector warnings?

Garbage Collection settings are usually made by editing the following file: <atom_installation_directory>/bin/atom.vmoptions

 

The following garbage collector combinations are deprecated in Java 8:

  • DefNew + CMS
  • ParNew + SerialOld
  • Incremental CMS

 

Corresponding command-line options produce warning messages and it is recommended to avoid using them. These options will be removed in one of the next major releases.

  • The -Xincgc option is deprecated
  • The -XX:CMSIncrementalMode option is deprecated. Note that this also affects allCMSIncremental options.
  • The -XX:+UseParNewGC option is deprecated, unless you also specify -XX:+UseConcMarkSweepGC.
  • The -XX:-UseParNewGC option is deprecated only in combination with -XX:+UseConcMarkSweepGC.

Dell Boomi recommends removing these settings from your vmoptions files.

 

Where can I get the Unlimited Strength Cryptography jar files?

Location and installation of the JCE files remains the same.  Please follow steps from our Reference Guide:

To Install JCEUnlimited Strength Jurisdiction Policy Files

 

Why is the Javascript Date String breaking after Java 8 upgrade?

Sample Error:

com.boomi.process.ProcessException: [Function: X12 820 BPR Date, Date Format (Step 2)]: DateFormat cannot parse '2015-03-27': java.text.ParseException: Format.parseObject(String) failed
at com.boomi.process.graph.ProcessShape.failDocuments(ProcessShape.java: 736)
...

Solution:

The Javascript engine changed from Java 7 to Java 8.  With this change, the Javascript function Date.toLocaleDateString() outputs a different format string for the same locale. This can cause problems to subsequent code or steps that expects the string to be in a certain format.

 

So to fix this, we recommend not using Date.toLocaleDateString() for data going to a format step. This is a bad practice as the process will break simply by running on a machine with a different locale or on a machine with a different JVM. Rewrite the code using java.text.SimpleDateFormat to output the actual format that you want.

 

In addition, the customers may want to consult the reference guide for the new Javascript engine.

 

Why does the Foreground Collector CMS no longer work? (Advanced users)

The foreground garbage collector in CMS has been deprecated and is expected to be removed in a future release of Java. Use G1 or regular CMS instead.

 

Please don't include these parameters in the GC settings (atom.vmoptions). Here is a detailed summary of the flags and flag combinations that will stop working:

DefNew + CMS       : -XX:-UseParNewGC -XX:+UseConcMarkSweepGCParNew + SerialOld : -XX:+UseParNewGCParNew + iCMS      : -XincgcParNew + iCMS      : -XX:+CMSIncrementalMode -XX:+UseConcMarkSweepGCDefNew + iCMS      : -XX:+CMSIncrementalMode -XX:+UseConcMarkSweepGC -XX:-UseParNewGCCMS foreground     : -XX:+UseCMSCompactAtFullCollectionCMS foreground     : -XX:+CMSFullGCsBeforeCompactionCMS foreground     : -XX:+UseCMSCollectionPassing

Why is my HttpURLConnection Digest Authentication not working?

In previous releases, the HttpURLConnection Digest Authentication implementation incorrectly quoted some values in the WWW-Authenticate Response Header. In the Java SE 8 release, these values are no longer quoted. This is in strict conformance with the RFC 2617, HTTP Authentication: Basic and Digest Access Authentication.

 

You might see that HTTP DIGEST authentication fails. Inside the Authorization header, one or both of the "qop" or "algorithm" values are not quoted (before upgrade to Java 8, they WERE quoted)

Example Error:

Error: Failed authentication

 

Solution:

Certain versions of some server implementations are known to expect the values to be quoted. HTTP requests to these servers might no longer successfully authenticate. Other server implementations that previously failed to authenticate because the values were quoted, might now successfully authenticate.

 

Tell owner of the receiving server to update their software to a version that does not rely on quoted values for qop or algorithm in the authorization header

 

Why am I getting a new Out Of Memory Error?

From Java 8 the "java.lang.OutOfMemoryError: PermGen space"  error will no longer exist but now its a regular out of memory error. The JVM flags PermSize and MaxPermSize are now ignored.

 

You can add this property in the atom_install_dir\bin\atom.vmoptions

-XX:MaxMetaspaceSize=<metaspace size>[g|m|k]

 

eg. -XX:MaxMetaspaceSize=1024m

 

How do I use Reject Client Initialized Renegotiation?

In advanced config: for security (to prevent certain DOS attacks), some users have asked if they may set the system property jdk.tls.rejectClientInitializedRenego to true (default is false).

 

If the system property is set to true, the server side does not accept client initialized renegotiation, and could fail with a fatal handshake_failure alert if the receiving client initialized the renegotiation request.

 

Dell Boomi's Official Statement:

  • This may affect some connection functionality, proceed with care.
  • Oracle provides this feature as a security measure that you are free to use if you so choose.
  • We don't use this in our own production cloud.
  • It has the potential to impact processing on your atom cloud and should be tested first.

 

Why am I getting a Certificate Key Length error?

There have been some Issues with certification path building and validation. This key size restriction also impacts JDK components that validate X.509 certificates, for example signed JAR verification, SSL/TLS transportation, and HTTPS connections.

 

ERROR:  "java.security.cert.CertificateException: Certificates does not conform to algorithm constraints", "Failed to validate certificate" or another certificate or security related message.

Solution:

Certificates are blocked if they contain RSA keys of less than 1024 bits in length. This restriction is applied via the Java Security property, jdk.certpath.disabledAlgorithms. This impacts providers that adhere to this security property, for example, the Sun provider and the SunJSSE provider.

 

If it only started happening after an upgrade from <1.7.0_40 then the recommendation is this:

  • In order to avoid the compatibility issue, users who use X.509 certificates with RSA keys less than 1024 bits are recommended to update their certificates with stronger keys. As a workaround, at their own risk, users can adjust the key size restriction security property (jdk.certpath.disabledAlgorithms) to permit smaller key sizes (comment out the security setting "jdk.certpath.disabledAlgorithms" in the file <JRE>/lib/security/java.security)

 

Note: Certificate issues are still very likely to be caused by something else other than this.

 

Why is JAXP / ServiceLoader no longer working? (Advanced Users)

If you define custom classloaders, you might experience issues with not loading a desired implementation of JAXP.  We occasionally see a ClassCastException for javax.xml.* classes in the container logs, especially when custom classloaders or StAX classes are being used.

 

JDK 8 ships with JAXP 1.6 and so includes specification updates that mandate the use ofjava.util.ServiceLoader for finding service providers. Service providers across JAXP will now be located consistently following the process as defined in java.util.ServiceLoader. The changes may result in some subtle differences from implementations of JDK 7 where the provider-configuration file may have been located differently, for example, by using a different getXXX method of the ClassLoader than ServiceLoader.

 

Solution:

If there is a ClassCastException, the offending code should be rewritten to use the JAXP classes without reference to the implementation classes. Applications that implement their own Classloaders shall therefore make sure that theClassLoaders' getXXX methods are implemented consistently so as to maintain compatibility.

 

Recommendations from Sun:

  • If there is custom code the defines its own Classloader, the author should make sure that the ClassLoaders' getXXX methods are implemented consistently so as to maintain compatibility.
  • When using the StAX API and calling .newInstance() or .newFactory() methods with factoryId parameters, the value of factoryId must be the name of the base service class if it is intended to represent the name of the service configuration file, that is, if it is not the name of a System Property.
  • As a side note: To verify that a different JAXP implementation is being selected, we can run an atom under both versions of Java with the -Djaxp.debug=1 flag in both cases (in bin/atom.vmoptions), to see if it is selecting different implementations, and to see if the bug is exposed in one but not the other.
4 people found this helpful

Attachments

    Outcomes