Upgrading to SDL Tridion Docs R14: OpenJDK

McAfee is currently planning (internal scoping/budgeting only at this point) for an upgrade from SDL Tridion Docs R13 (since renamed) to SDL Tridion Docs R14 (to my knowledge, the most current version). Although the upgrade promises to be more straight-forward than our previous one (we waited too long for the last upgrade), we understand that upgrades now require code conversion to utilize Open JDK (versus Oracle JDK, which now requires additional licensing).

We are quite happy with SDL Tridion Docs R13 and confident that SDL's technical folks can successfully move us to Open JDK. However, because our upgrade must happen during a strict time frame, my management is wondering if we should also bring a contractor on board (recommended by another 3rd party vendor - would collaborate with McAfee and SDL) to assist with engineering tasks related to Open JDK updates). Basically, the objective would be to move things along more quickly, in order to meet business objectives.

So just wondering::

  • Have other customers performed similar upgrades that involved moving to Open JDK?
  • If so, did Open JDK updates require significant engineering resources?

Thanks for any help anyone can give.

Paul M.

  • Hi Paul,

    From a product perspective, you can search "java" on the overview on TD14SP2 - Software compatibility across releases. So Tridion Docs 14SP2 (14.0.2) is the latest available version.

    Just like you, we were also affected by the revisited Oracle licensing scheme. We however offer you two flavors, allow me to quickly write them down using proza text Slight smile ... see also https://stackoverflow.com/questions/52431764/difference-between-openjdk-and-adoptium-adoptopenjdk 

    1. Oracle continued, what you are used to from the past. New however, is that you need Oracle maintenance contracts in place as you have to stick on a long-term-supported (LTS) version. Something you'll notice when downloading the Oracle build binaries.
    2. AdoptOpenJDK, is a variation of OpenJDK that is build and maintained outside of Oracle. Those LTS releases do get hotfixes for a longer time, for free

    The components inside Tridion Docs Content Manager (I assume you are not using Content Delivery and you migrate away from Collaborative Review if you were even using that). So for Tridion Docs Content Manager there are only few components using Java, but we can put them in two groups:

    • Components like Solr are tested by us on the supported versions
    • Customization, so for publishing this typically is DITA-OT. We ship with a certain DITA-OT version and we tested that on the offered Java version. However, in the end DITA-OT in total is part of the custom publish pipeline, so many customers have a separate upgrade path for DITA-OT and in turn prerequisites of publishing components like DITA-OT.

    Knowing the above, the main question is, what custom Java code (inc DITA-OT) do you have available.


  • Dave, thank you for the great response, We currently use two different versions of the DITA toolkit:

    • DITA-OT154: All output formats except our web portal (Zoomin Docs).
      Has Java customizations for output formats such as Webhelp and PDF.
    • DITA-OT244: Zoomin (portal) output formats, plus some APIs (for example, as part of the PDF upload process).
      Has Java customizations for Zoomin plugins.

    Optimally we would like to:

    • Use only one DITA-OT instance (possibly 3.x, if all our vendors can support it).
    • Upgrade to DITA 1.3 (from our current 1.2).

    So it would appear we could have some heavy work on our hands (not only with Java changes, but other DITA-OT changes such as XSLT, XSL-FO, configuration). And if we decide on DITA 1.3, our CMS customizations would have to change, too.

    Thanks again for your help. 

  • Good to hear from you Paul. Hope you're well.

    And if you need help, you know where to find us! Slight smile

Reply Children
No Data