[Looking for Charlie's main web site?]

New URL for signing up to the CFML Slack: cfml-slack.net

TLDR; the URL for joining the CFML Slack workspace and channels has changed. If you want to join the CFML Slack, use the form at cfml-slack.net. As some may have noticed, the old URL for joining (cfml-slack.herokuapp.com) no longer works.

Since it's mentioned in many places on the web, I wanted to help spread this news. This cfml-slack.net URL replaces that, while the URL for the CFML Slack channel itself is unchanged: cfml.slack.com.

For more explanation/context, and especially if you may be new to considering the CFML Slack, read on.

[....Continue Reading....]

Be aware that ColdFusion 2018 end-of-life (and end of updates) is coming July 2023

Are you still running ColdFusion 2018? Did you know that its end-of-life is July 13, 2023? That's the date that "core" support ends--meaning, no more updates from Adobe after that, not even security fixes.

As for CF2021, it gets updates into 2025, and the currently running pre-release of CF2023 is a great sign for the continued vitality of CF. But this looming deadline for CF2018 is a reminder that as the years roll on, we not only get new versions but we must say good-bye to old ones.

Wondering what you can do? or when CF2021 or CF2023 support will end also? And what's the difference between "core" and "extended" support Adobe sells? (The extended support plan does NOT provide updates beyond this coming July.) For more on these, including official Adobe documentation that discusses such things, as well as my thoughts on migration, costs, various options to consider, and more, do read on.

[....Continue Reading....]

Thrilled to be presenting at Devnexus 2023

I'm thrilled to announce that I've been selected as a speaker at Devnexus 2023, the long-running professional developer conference held in Atlanta. If you may not be familiar with it, I'll talk about the event a bit more below, as well as offer a discount code to attend.

As for my session, it will be "Transitioning to Java 17 from 11 or 8 for Admins":

[....Continue Reading....]

What's new in FusionReactor 9.2.0, released Jan 18 2023

If you're a user of the wonderful FusionReactor monitoring and observability solution (for ColdFusion, Lucee, Java servers and more), you may delight in hearing news of a new FusionReactor (FR) version. 9.2.0 was released last week, Jan 18, 2023.

You can learn more (in brief) about what's new in the bullets for 9.2.0 offered at the release notes page.

TLDR: For some folks, news of the new version is all the need to hear. For those who may like to hear a bit more about the update, read on.

[....Continue Reading....]

Beware that latest Oracle JDK installers will REMOVE older JDK installs of that version

Here's something new to beware, a change in the most recent Oracle JDK installers for Java 11 or 17 (since Jan 2023) which could break your apps which rely on Java, whether on Windows, macOS, or via RPM, where the new Oracle jdk installer WILL REMOVE any previous updates of that JVM version that were created by previous JDK installers of that same major version. And it will do pretty much without warning, which may be a confusing shock for those caught unaware. Let me explain.

TLDR; If you run the Oracle JDK installer for Java 11 or 17 after updates 11.0.18 or 17.0.6 or later (on any OS), it has two new behaviors:

  1. it will remove any prior update installed with the installer that major version, and it may or may not tell you that it does it (and any app relying on that old version/configured to use it specifically may not be able to restart/start)
  2. it will create a new folder to hold the new JVM with a name that only reflects the MAJOR version, like jdk-11, whereas previously the foldername also reflected the minor version, like jdk-11.0.17. You must change any app configured specifically to use such a specific Java version to use this new folder. Or you can instead manually extract the new JDK from the zip or tar.gz and place it where you like, configuring your app to point to that (some folks have always done this. This post is for those who have instead always used the installer.)

To be clear I'm referring here to new behavior in the JDK installers from the Jan 2023 update, which I blogged about the day they came out. This topic will apply also to subsequent JVM updates as they come out in the future. (Fortunately for some, this issue does NOT affect those running Java 8 or below, and this aspect of it being a "change in behavior" will not affect Java 19 or above, as I explain later.)

After I posted this, I heard some people assert that "this is not new behavior: Java's always popped up and offered to remove old versions". Those folks are misunderstanding something: that was true of past JRE installers (like in Java 8 and earlier, which don't exist for Java 11), but it was never the case for Oracle JDK installers (even for Java 8). THAT's what's new about the JDK 11 and 17 installers, but it may surprise those who never saw a JDK installer do that, thus this post.

While the technotes for the new updates (which I point to in my post above) DO make mention of the issue I'm describing, I don't feel they do it in as obvious a manner as they might (it's not clear how it affects CURRENTLY installed earlier updates of JDK 11 or 17)., and I've already helped some people dealing with the ramifications of the change. And of course it's all the MORE important to make sure this is made known to those who might NOT read the release notes.

I've also found that the JDK installer doesn't ALWAYS warn that there are running processes using the older JDK version that it's about to remove. And to be clear, it won't warn about applications that are NOT running but which are configured to try to use the older JDK version that would be removed.

Read on for:

Before going further, it may help to clarify that when I (or others) refer to a "major Java version", we are referring for example to Java 11 or 17 (or Java 8 or 19, and so on). And when we refer to a "minor" version, we mean an update to such a major version, such as 11.0.17 for Java 11. Previous JDK installers did allow us to run more than one minor version of a given major version, which could be an advantage. Newer ones no longer will.

The issue, in brief: JDK installers now implement a single minor version per major version, deleting older minor versions

In brief, the new behavior is that:

  • The new Oracle jdk installers for 11 and 17 now implement a single-minor-version-per-major-version policy, supporting only ONE minor version (update) being implemented at a time by that installer, for a given major version of Java 11 or 17
  • As such, the new JDK installer will attempt to REMOVE all previous minor versions/updates to that major Java version, which were installed by previously run jdk installers for that major version. (To be clear, it will NOT touch any Java that was implemented by you or some software, which put Java someplace the JDK installer doesn't know about)
  • The problem is that you may or may not expect that removal of the old version to happen (it's new behavior for Oracle JDK 11 and 17), and it may have a serious impact on existing apps that may be currently using or set to use such an earlier minor version--which this process would remove!

Let's make things more clear: say you already have in place two "minor" versions of the "major" version of Java 11, for example 11.0.16 and 11.0.11, which were implemented by the previous JDK installers for those versions. Upon running the Oracle JDK installer for the new 11.0.18 version (or future later versions), that new JDK installer will attempt to REMOVE BOTH those 11.0.16 and 11.0.11 installations first!

Again the same is true of the Java 17 jdk installer.

(As for Java 8 or below, Oracle did not opt to implement this change. As for Java versions 19 and above, it ALREADY implements this change from its original version, released in Sep 2022.)

The implications of this changed behavior which may trip you up--and a solution

There are a couple of VERY important implications of this change in behavior or the Oracle JDK installer, including some things that may surprise you--and one that may really trip you up, with a solution I can offer:

  • The most important implication of course is that you may NOT expect the JDK installer to DO this removal of the older version/s at all. Now you've been warned
  • And you may well be warned by the new JDK installer about this, telling you that some running app is using an older JDK update to be removed, at least giving you a chance to realize what's happening--and you can even cancel the install if you want.
    • Even so, the way the installer reports "already running processes" may surprise you: it will report processes by process id. It will be up to you to use your OS tools to find what process each of those points to, so you can stop them. (And I was surprised on one machine that it listed over a dozen processes, even ones that did not involve Java.) Fortunately, the JDK installer offers a "retry" option, so you can check if it feels you've stopped enough processes. I did not have to stop ALL of those listed, after all.
  • Then again, you may have some application that's configured to use such an old JDK--but if that application is not running, then obviously you can't expect the installer to warn you about that, since it's looking for whether any currently running processes refer to it. That's bad enough.
    • But on 2 of 3 machines I tested on, where I DID have running processes that were using that JDK to be uninstalled, the new JDK installer did NOT offer me that warning about running processes using it. It just deleted it.
  • And the sinister problem about those last two points is that you (or colleagues) may not realize what's happened until hours or even DAYS AFTER the new JDK installer was run, deleting the prior ones, so your apps that were relying on the older JDK (which is now REMOVED) will simply not start the next time you try to run (or restart) them. And it's very likely no one experiencing THAT problem will connect the dots to this having been caused by the new JDK installation.

Fortunately, solving those last couple of problems is rather easy, at least once you understand that this is what happened.

Just change your app to refer to the NEW JVM location. (Good news: with the new approach, there will always be only ONE JDK location for a given major version.) On Windows, for instance, it will by default be C:\Program Files\Java\jdk-11, without any minor version number. Of course, in some apps it's your responsibility to escape those Windows slashes, as in C:\\Program Files\\Java\\jdk-11.

As for HOW to make that change in your app, there are so many ways to control that depending on your Java-based app as well as how it was installed, etc. I'm writing this post in a way that the information will make sense regardless of what Java app you may run. And since someone in your org already had to know to change your app to point to the OLD JDK location (the one deleted), I'll have to leave this as an exercise for the reader. (For my traditional audience of CF users, see my CF Update page with more for you.)

Again, my goal here has been to make you AWARE of the issue, so you can plan for and anticipate it.

Some closing considerations

Before wrapping up, there are just a couple of closing topics related to the above someone may wonder:

  • "You say this change of behavior was documented?"": Yes. In the release notes for 11.0.18 and for 17.0.6, notice that each has 3 sections with different names ("Disable Side-by-Side Installations of Multiple JDK Updates in Windows JDK Installers", "All JDK Update Releases Are Installed Into the Same Directory on macOS", and "RPM JDK Installer Changes"), which cover essentially this one issue, each with slightly different details.
  • "Can't we just re-install the older JDK, if we want it back?": The answer is "yes", in that I was able to do that with the Windows 11.0.17 JDK, for instance. But note first that the next time you run any JDK installer from Jan 2023 or later, that will again remove it. Note also that the aforementioned release notes imply that future installers will PREVENT older JDK installers from running (perhaps only those from Jan 2023, forward.)
  • "What about openjdk and other non-Oracle Java implementations?": As I've indicated throughout this post, I'm talking about the Oracle JDK. Some alternative Java implementations ALREADY take this single-minor-version-per-major-version approach, such as the Azul Zulu JDK installer, as I confirmed with their JDK installer and docs for the JDK 11 version prior to this one, 11.0.17.
  • "You mention RPM installers. What about .deb files?": While the release notes refer to .rpm files, they make no mention of .deb files--though those are indeed offered as another Linux installer choice, for Debian/Ubuntu. I can confirm that when I ran the older 11.0.17 JDK installer as a .deb file, it installed into a single /usr/lib/jvm/jdk-11/ folder, reflecting the single-minor-version-per-major-version policy being already implemented BEFORE this 11.0.18 update.
  • "Does this affect Oracle JRE installers?": Oracle no longer offers separate JRE installers since Java 8. And as I noted earlier, this matter applies only to JDK 11 and 17 installers.

Conclusion

While this new behavior is challenging (all the more because it's new to the Oracle JDK), in time people will come to understand it and deal with it. Until then, I offer all this to help folks and give a heads-up.

If you may feel stuck, I can probably help quickly via my short-term, remote consulting.

As for all the above, I certainly welcome feedback.

New updates released for Java 8, 11, 17, and 19 as of Jan 17 2023: resources and thoughts

Here's a heads-up that some will want to hear about: there are new JVM updates released today (Jan 17, 2023) for the current long-term support (LTS) releases of Oracle Java, 8, 11, and 17, as well as the current interim update 19. (Note that prior to Java 9, releases of Java were known technically as 1.x, so 8 is referred to in resources below as 1.8.)

TLDR: The new updates are 1.8.0_361 (aka 8u361), 11.0.18, 17.0.6, and 19.0.2 respectively). For more on each of them, including what changed and the security fixes they each contain (including their CVE scores regarding urgency of concerns), see the Oracle resources I list below. Oracle calls them "critical patch updates" (yep, CPU), but they are in fact scheduled quarterly updates, so that "critical" nomenclature may be a bit overstated. And as is generally the case with these Java updates, most of them have the same changes and fixes as each other, though not always.

Update: After posting this, I learned of some rather surprising implications of a new feature of the new JDK installer, as 11.0.18 or 17.0.6 and later. For more, see another post I created.

For some folks, that's all they need to hear. For others, read on for topics like:

  • Finding more info on these Jan 2023 Java updates
  • What about other JVM distributions besides Oracle?
  • News for my CF audience (getting the Java updates from Adobe or Oracle, how to update, why you should NOT for now use Java 17 with CF, etc)
  • Should you apply the update? how soon?
  • Beware a change in the Oct 22 JVM update regarding Java no longer trusting jars signed with SHA-1
  • Beware a change in the April 2021 JVM update, if you may be skipping over it
  • Wrapping up, getting more help

[....Continue Reading....]

Adobe has started to open the prerelease Alpha for ColdFusion 2023 (codename Fortuna)

If you're active in social media you may have heard the news already, but for those who are not, Adobe has started to open the prerelease program for the next CF version, aka ColdFusion 2023--though known for now formally by its code name, Project Fortuna. You can find out more (and request to join) the prerelease program at its page on the Adobe prerelease site (where you will see as well as all kinds of prereleases for other Adobe products).

For now, only the Alpha has been announced, and the number of registrants allowed may be limited.

For more on that and about the prerelease (what can be gleaned/shared publicly), read on.

[....Continue Reading....]

Restoring the CF Admin logviewer removed in Oct 2022 CF updates, at your own risk

As of the Oct 2022 CF updates (CF2021 update 5 and CF2018 update 15), Adobe has chosen to remove the CF Admin feature to view, search, download, and delete CF logs, due to asserted (but as-yet undocumented) security concerns.

What if you want it back? In this post, I explain what changed, why, and how to get the functionality back--albeit at your own risk. For more, read on.

[....Continue Reading....]

Special offer: upgrade to ColdFusion 2021 from CF2016 or earlier, saving perhaps thousands of $$

If you're running CF2016 or earlier, now's your chance (though the end of the year Feb 28, 2023) to save potentially thousands of dollars in upgrading to the latest current version, CF2021. Intergral, the folks who make the FusionReactor monitoring tool and service, are again offering a special deal of 25% off to upgrade CF2016 or earlier to CF2021 (a deal which even Adobe does not offer).

Read on for more details.

[....Continue Reading....]

How to solve "Failed Signature verification", for downloads of ColdFusion updates--since Oct 2022

If you try to download a CF update using the ColdFusion Administrator AND you get an error, "error occurred while installing the update: Failed Signature Verification", there are both a couple of possible explanations (one of them new), both with fairly simple solutions.

Update: In mid-February 2023, Adobe did re-sign their jars and placed them on the uploads site so that either the CF Admin update download or anyone performing a manual download after that date WOULD get the newly signed jars, and the problem below then no longer happens. (They are now signed as "SHA256withRSA, 4096-bit key".) I leave the rest here still for those who would want to understand what DID happen and why the update jars that were in place then DID change (slightly) for this reason.

[....Continue Reading....]

More Entries

Copyright ©2023 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting