Questions about Java 11

Blackboard Learn now uses Java 11.

Blackboard Learn SaaS 3800.0.0 and later run on version 11 of the Java SE Platform from Oracle (released September 2018). This change is on the server only and is unrelated to any Java you or your users may use on devices or browsers. Blackboard utilizes Amazon Corretto's production-ready distribution of Java 11, which allows us to benefit from a zero-cost fully supported version of Java with performance enhancements and the latest security fixes. In order to provide the most secure and quality solution, Blackboard Learn will always leverage the latest Java technology with long-term support.

This topic answers a number of common questions to help you and your institution understand what the transition from Java 8 to Java 11 means for your Blackboard Learn environment.

Can I use Java 11 JDK with prior versions of Learn?

No. Java 11 JDK should only be used with the latest Blackboard Learn releases.

What impact does Java 11 have on my Blackboard Learn environment?

The primary impact is on third-party building blocks. Most building blocks will continue to work without any changes. Due to the numerous changes between Java 8 and Java 11, though, some building blocks may require significant changes depending on how they were authored.

We recommend testing all third-party building blocks in test or staging instances before this release is made available to production.

Custom integrations to campus SIS or LDAP implementations may also be affected due to deprecated or removed security ciphers and protocols.

What do system administrators need to do to prepare for this change?

Third-party building blocks

If you use building blocks that aren't part of core Blackboard Learn, you should plan to test them in a non-production environment running a version of Blackboard Learn using Java 11. Report any issues you may find to the building block solution provider.

This recommended testing is a best practice for any upgrade, but we strongly encourage you to test for this upgrade because the change is more significant.

Command line integrations

Integrations involving command line invocation may be impacted. Scenarios invoking Java from a command line script would need to include the argument --add-modules=ALL-SYSTEM to prevent potential module related errors.

Integrations involving locale-specific dates or timestamps may be affected by the adoption of the Common Locale Data Repository (CLDR) by default in Java 9 and later (see https://openjdk.java.net/jeps/252 for more information). For Java 11, Blackboard Learn will override the new default CLDR locale provider in favor of providing backward compatibility support for locale data and formatting. Specifically, Blackboard Learn will set the the java.locale.provider property as: java.locale.providers=COMPAT,CLDR.

Depending on the client use and load, there may be risk of StackOverflow errors due to the increased size of the callstack for resolving class files in Java 11. We can control the stacksize setting in Tomcat via the bb-config.properties setting bbconfig.max.stacksize.tomcat. The previous recommendation for stack size was 400K, and the current recommended minimum under Java 11 is 700K.

Any Java-based command line integrations with Blackboard Learn should use the same settings to ensure maximum compatibility.

SIS and LDAP integrations

Any integration that relies on older or less secure cipher suites for SSL or TLS implementations won't work under Java 11. See the support bulletin for details.

What do developers need to do?

Generally, most Java 8 code is compatible with Java 11 and will work. However, some building blocks may require updates. Likely scenarios include:

• A building block that references or depends on third-party libraries or jars that are part of the Blackboard Learn distribution.
  • In this scenario, building block developers should bundle their own copies of third-party libraries or jars that are required for their building block functionality to run.
• A building block that depends on EE (Enterprise Edition) framework classes that were removed by Oracle in Java 9 (see https://openjdk.java.net/jeps/320 for for more information).
  • Any dependency of these removed classes must be mitigated by replacing them with external packages with similar functionality.
• A building block that references or depends on certain internal Java APIs may not continue to work under Java 11. Most com.sun.* and sun.* packages are internal and inaccessible by default as of Java 9.
  • Any dependency on Java internal packages must be mitigated by replacing them with external packages with similar functionality.
• Many building blocks won't require recompilation. However, a recompile might be unavoidable for building blocks that rely on one or more third-party libraries that need to be upgraded to work with Java 11 (for example, Spring).
  • To be compatible with Java 11, a building block that relies on the Spring Framework should be updated to use Spring 5.1.X+.

In any case, it's best practice to recompile building blocks with Java 11 and the latest public Blackboard API library files.

As a developer, can I leverage Java 11 features?

Yes, developers can now use any of the language-specific capabilities introduced in Java 9 through 11. However, implementing these features means the building block won't be compatible with Java 8 versions of Blackboard Learn. If the building block is specific to your environment, this is less of a concern. Implement Java 11-specific features after you upgrade Learn.

Solutions intended for multiple versions of Blackboard Learn may need to create two separate building blocks or create a single building block compiled using the target versions' appropriate libraries, and compiler source and target versions to meet both Java 8 and Java 11 compatibility requirements.

How can I learn more about building blocks?

Join the Blackboard Learn Developer Community.