Does anyone (particularly the Adobe team, <@U01EY2...
# adobe
r
Does anyone (particularly the Adobe team, @Mark Takata (Adobe)?) know what the language in the screenshot on the Oracle Java site means in terms of production server use of Oracle Java 17 JDK with current versions of ColdFusion going forward? Is this another situation where use of Oracle Java in production environments is covered under an agreement between Adobe and Oracle? Has Adobe considered officially supporting JDKs from other providers to avoid this?
s
See https://coldfusion.adobe.com/2023/11/oracle-java-support-for-adobe-coldfusion-2021-2023/ (and the earlier https://coldfusion.adobe.com/2019/01/oracle-java-support-adobe-coldfusion/ ) -- Adobe states current and future LTS versions will be supported under their agreement with Oracle. Links to the documentation where Java support is discussed.
👍🏻 1
👍 2
r
Thanks, @seancorfield.I'm kind of baffled as to how I missed that.
s
If it helps, I searched (Bing) for
adobe oracle license coldfusion jre
and then
adobe oracle license coldfusion jre 17
(the links above were the #1 result on each search)
m
Thank you Sean. There is even more, specific, information here: https://helpx.adobe.com/coldfusion/enterprise/faq.html#java-support
The pertinent info:
image.png
r
@Mark Takata (Adobe) Hoping you clarify one aspect of the information in that FAQ entry: does that mean we have to use the Oracle JDK bundled with ColdFusion? Does the "bundled with" aspect of that wording mean the only version of the Oracle JDK we can use is the one that comes with ColdFusion? Can we install a more recent version of the Oracle JDK for use with ColdFusion even though/if that is not "bundled with" the Adobe product? (We've learned the hard way in the past that when it comes to licensing, words matter.)
s
@rstewart I'm not Mark but my understanding is that Oracle has been tracking downloads and contacting companies that do that, to follow up on license compliance. Adobe has a redistribution agreement so the bundled JDK is covered by that, but anything you download from Oracle is not covered.
And Oracle have been getting really aggressive about this lately so I would err in favor of never downloading an Oracle JDK at this point. I don't even use their openjdk builds any more, even tho' those are "safe".
👍 1
r
Thanks, @seancorfield, those are both are good points. These would definitely seem to argue in favor of us only using the versions of the Oracle JDK Adobe makes available for download (rather than downloading from Oracle) and/or the Adobe team being diligent in updating the "bundled" JDK on a regular (i.e., quarterly) basis as part of their ColdFusion updates (with both of those from the standpoints of licensing clarity and getting the security-related updates associated with JDK updates on a timely basis). (And I'd still like to see Adobe officially support at least one of the OpenJDK builds although that's a different but related topic.)
s
Bear in mind that Adobe has to certify a specific build of the JDK with a specific build of ColdFusion for each update in order to offer support in any meaningful way. That all takes time and effort. You can almost certainly run ColdFusion with any "equivalent" OpenJDK build but you wouldn't be able to get support from Adobe for any issues you ran into unless you could reproduce them with a specific supported Oracle JDK build. (This is why Lucee and BoxLang "support" any old JDK across multiple versions: because they're not really offering anything more than "community assistance", unless you purchase specific support plans and then I think you'll find they'd also be stricter about which specific JDKs and versions they'd want you to use to be supported)
As someone who primarily works with an open source language that "supports" a fairly wide range of JDKs, I can tell you that even some minor JDK updates can cause problems, despite how careful the vendors are about backward compatibility! At work, we manage the JDK installation ourselves and the path from JDK 17 to 21 (the two most recent LTS versions) was littered with memory leak bugs in the JVM that prevented us from using JDK 19 at all and the initial build of JDK 20. Once you stop relying on a vendor who certifies specific builds, you are taking on an unknown amount of work.