[Looking for Charlie's main web site?]

Announcing updates of Apr 21, 2026 for Java 26, 25, 21, 17, 11, and 8 - thoughts and resources

Posted At : April 21, 2026 12:21 PM | Posted By : Charlie Arehart
Related Categories: updates, java, security
Comments: (4)
It's that time again: there are new Oracle JVM updates released today (Apr 21, 2026) for the current long-term support (LTS) releases of Oracle Java 25, 21, 17, 11, and 8, as well as the newest short-term release, 26. (Yep, kind of crazy that there are for now 5 current Oracle Java "LTS" releases, for historical reasons.)

TLDR: The new updates are 26.0.1, 25.0.3, 21.0.11, 17.0.19, 11.0.31, and 1.8.0_491 (aka 8u491) respectively. The update seems a pretty modest one, without seeming breaking changes (though my opinion is based solely on my read of the update release notes, in this first day).

More on the updates below, including links to more info on each of them including what changed, bug fixes, and the security fixes each version contains. (I also offer a quick assessment of the changes listed for the updates.)

Also, openjdk updates are usually released at the same time or soon after, so this info may help users of such alternative JDK implementations.

For some folks, the above is all they need to hear. For others, whether this your first time updating Java or your fiftieth, there are some things that you may or may not know, as I cover here.

Topics:

Note also that Oracle while calls these updates "critical patch updates" (yep, "CPU"), they are in fact scheduled quarterly updates (Jan, Apr, Jul, Oct, with specific dates listed here), so that the "critical" aspect of this nomenclature may sometimes be a bit overstated. See more below on the specific security changes. And as is generally the case with these Java updates, most of them have the same changes and fixes across the current LTS JVM versions, though not always.

Finding more info on these most recent Java updates

As for what changed in the updates, see the release notes for each of: (Again, Java 26 is a "short-term" release while the others are what Oracle calls "long-term support" or LTS releases.)

These Oracle release notes have sections on topics such as "New Features", "Known Issues", "Issues Fixed", "Other notes", and "Bug Fixes"--each as may apply to that specific update, which is why I am not listing all these changes here. See the release note for the update you are considering applying. That said, some changes may indeed be (and typically are) found in all the current LTS versions.

Changes, in brief

Though I don't want to repeat the details in the technotes, here at least is a brief assessment of the changes, as I've compared them across all of the LTS versions that were updated. Most of the new features seem marginally significant. Java 17 and above have a couple more than Java 11 and 8. Same with regard to "Other Notes" section in each. This update has no "Notable issues fixed" section, in any of them.

As for the bog fixes ("Fixed") section, the release note for each version lists in the range of 20-30 year (other than for the new version 26).

All in all, this seems an update that should be pretty innocuous as far as "changes" go, which is mostly my focus in my assessment of things (though I do often take not of important new features).

What if you are skipping over other recent JVM updates?

Of course while sometimes there may (or may not) be much significant to any one Java version's update (or nothing may seem to apply to you), note that if instead you may be skipping OVER recent Java updates to get to this one, then you DO need to consider also what was changed in THOSE updates. Of course, Oracle offers a release notes document for each version's update, and I offer a blog post like this on each such set of updates. See my java category of posts.

Finding more on security matters addressed in these Java updates

As for security fixes included in this update, that's covered elsewhere. Unfortunately, I find often that when I get this post out on the day that the update comes out--and even though the release notes above are available for me to point to and assess--the details about the SECURITY changes seem delayed. But they WILL come, and perhaps will be there by the time you click the links I share next.

First, see the single document listing Java security fixes in this most recent update. That should take you to a section labelled "Oracle Java SE Risk Matrix", which is not yet there as I post this entry, but should be soon. (If you see instead, "Oracle Java SE Executive Summary", that seems to be a placeholder they put there until replacing it with the "risk matrix" with more detail--at the same link.)

Second, see the Text Form of Risk Matrix for Oracle Java SE--but as I write the page gets a "we found a phone" 404 error. Both problems should be resolved by later today, from past experience.

As for that first link, pay close attention to "notes" column offered there on the right for each vulnerability, as that may temper the severity. (Note as well that while both these documents cover ALL Oracle products, I have offered in the first paragraph above links to the Java-specific sections of the pages. Focus on references to "Java SE" rather than any specific to GraalVM, which is not the focus of the discussion in this post.)

Watch also that many times the listed issues indicate that a vulnerability may be "difficult to exploit" and that many "[do] not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator)", which may reduce the concern for you about them depending on your perspective.

That said, these documents could also change between now and when you see this post, so it's your responsibility to assess that information carefully. And regardless of whether such vulnerabilities may seem to apply to you, generally folks should seek to keep their JVM updated, or at least avoid falling too far behind.

Obtaining the JVM update, from Oracle

As for obtaining downloads of Java updates, you can find all the current versions on this one page. Note that recent Java versions are offered in tabs at the top of the page, while the older LTS versions are offered in tabs toward the bottom of the page, as I indicate below.

Note that there are tabs for the installers for each supported OS (Linux, macOS, and Windows), both installers and "compressed archives"/zip/tar.gz files.

(Also, to users of Adobe ColdFusion--my primary audience--note that Adobe licenses Oracle Java for our use of it with CF--but CF only. More on that below.)

Oracle downloads for Java 26, 25, and 21

The top of that Oracle downloads page offers the LATEST Java versions, 26, 25, and 21:

Note that those updates for Java 21 and above do NOT require a login on the Oracle site. Java 21 updates will get updates until Sept 2026--a year after Java 25 was released, and Java 25 will get them until Sep 2028, a year after the next LTS is expected to be released. (Java licensing matters are beyond the scope of this post to discuss, but see links offered there for more.)

Oracle downloads for Java 8, 11, and 17

As for the remaining downloads, note that those are offered at the BOTTOM of that Oracle downloads page. To download those you will be prompted for an Oracle sign in, but an account is free.

Here are direct links to the section at the bottom for that downloads page for the remaining Java versions:

Obtaining the JVM update, from Adobe

The focus of my blog and work is mostly focused on those using Adobe ColdFusion (as well as Lucee and BoxLang, and all 3 run atop Java), I'll clarify especially for CF users that Adobe offers the Oracle Java downloads, such that one need not log into the Oracle site as discussed above.

See the CF Downloads page, and its last section offering Java installers, which includes the installers or zip/archive options, for each of Windows, Linux, and MacOS. Sometimes Adobe gets these downloads posted as soon as Oracle releases them, but often it may take some days before the latest update appears, in which case consider the Oracle links in the previous section. (Note that Adobe formally supports only the use of Oracle Java, not other OpenJDK implementations.)

As of my posting this today, the Adobe downloads page for CF-related installers does not yet have the downloads for this latest update. Watch that space for change sover time, or use the Oracle downloads approach I offer above.

And while some assert that CF folks "must use those from the CF downloads page", every time I've done a binary compare of the files, they have been identical to those offered on the Oracle site (at least for the identical build number, which may change slightly over time on the Oracle site though not the Adobe site). As this installer includes the Java license, I can't see how anyone could assert that it matters WHERE you get an identical installer. But IANAL. The choice is yours if you want the update ASAP and Adobe doesn't offer it yet.

Other topics you may be interested to know, and where I discuss them

Some readers may find the above so far to have been "a lot to consider" already, but there is indeed far more that you could and should consider before applying a Java update. And for a few years, I would cover such additional topics within this sort of blog post, each time I announced the new JVM update. But I've decided recently to split that off into its own blog entry, and I will point to that instead in each of these such JVM update announcement posts, in order to keep this relatively "brief".

In that other post, I address such issues as :

  • Obtaining and learning still more about available JVM updates
  • What about other JVM distributions besides Oracle?
  • News for my CF audience (which CF versions support what JVM versions, how to apply the update--including when using Commandbox or Lucee, why CF users should NOT for now use Java 21 and up with CF, etc.)
  • Should you apply the update? how soon?

Then I cover a few things that you should be aware of if skipping over previous JVM updates:

Again, that other post of mine with more info is here: Several things to consider when applying JVM updates.

Wrapping up, getting more help

I hope all that may be helpful for you.

Finally, feel free to ask questions or raise comments below, or for direct help note that I offer remote screenshare consulting help, where I am usually able to quickly fix problems (that might take many folks hours to resolve--if they don't deal with these issues daily like I do in helping people).

For more content like this from Charlie Arehart: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
  • See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
Comments (4)
Comments
[Add Comment]
This might be a bit unrelated blog article to post my comment under - so please forgive me in advance and point me in the right direction - but since the last CF2023 update the CF server has had numerous problems rendering utf-8 characters properly. Google search says to add -Dfile.encoding=UTF-8 in the JVM config but before I do that I wanted to seek the expert advice.

Will adding this to the jvm config break any legacy ASCII file based code in our system? We have been running banking related app since 2001 so it is critical that we do not break anything legacy. Thank you.
# Posted By Himanshu Shekhar | 4/22/26 12:15 PM
Himanshu, I will say first that no, this doesn't seem the right place--since you say that the issue started with your last update of CF. Maybe you thought it could be since you're asking about "jvm arguments", but what you refer to are not new args with THIS recent JVM update.

Still, you've written here already, so let's plow on. First, a few questions (you can use the numbers to offer your answers):

1) You don't clarify WHAT update was "the last update" you applied. Was it the one that came out last week, CF2023's update 19? If you don't have access to the CF admin, you can see the current CF update version by dumping CF's server.coldfusion.productversion variable. And do you know what update were you on BEFORE that? That could be significant to understanding your problem.

2) And as for what else may have changed, when you (or a colleague) updated your CF, did you ALSO happen to update your JVM that CF uses, as discussed in this post? If so, what JVM version does the CF admin show you now using (use the "settings summary" page on the first Admin "settings" button). If you don't have access to the admin, dump cf's server.system.properties["java.version"] variable.

And do you know what JVM version it was using before?

3) And what OS is CF running on? Windows? Linux? Mac? And what locale/language is your CF server set for?

Whenever trying to understand "why did things break", it's CRUCIAL to understand whatever was changed. Often people think it was one thing (like in your case, "the last cf update"), when it may well be that or something else, or a combination of things. Or people may pose "answers", but they may not suit YOUR setup.

Indeed, to your asking about adding the jvm arg "-Dfile.encoding=UTF-8", I'll assume you mean you find that none is set currently, right? I'll clarify for readers that that there is NO arg of that name set for CF (2023 or 2025) by default.

And therefore its value is decided upon by Java (not CF)--and Java decides based on not only your Java version but also your OS (thus my questions above). More specifically, note that for Java 18 and above, it now DEFAULTS to utf-8 for ALL OS's. But since C2023 runs (and is supported only to run) on Java 17 (while CF2025 is supported only to run on Java 21, so this arg/value you propose should NOT be needed for CF2025.)

4) So are you aware of what your CURRENT jvm file.encoding value is? I would propose it's always wise to know what value you are changing FROM when making such jvm changes. Also, it may prove helpful for you (or us) to know.

If you have access to the CF admin, it's shown there on that same "settings summary" page as "Java File Encoding". If you don't have access to the admin, dump out the value of CF's server.system.properties["file.encoding"] variable. For my CF2023 on Windows it reports being Cp1252. If yours is something else, perhaps that's worth digging into.

5) Finally, you didn't say what your errors were beyond "rendering utf-8 chars". Is that in outputting html, from CF pages? Or was it maybe about CF accessing files? Or accessing data returned from external applications/api's?

FWIW, many such operations have their own way to set the encoding for that specific operation, which might be another solution (or even perhaps another explanation for problems). And beyond looking at the CFML reference docs, see also the discussion in the CF Developer's Guide about such character encoding, at https://tinyurl.com/ye25mj2p

I realize you probably didn't want to be asked a lot of questions. You just want to know if your sites will break if you make this change. I'm afraid I simply can't tell you that. I'm not sure if anyone else can (but perhaps they may).

Indeed, finally, I can't help but offer also that if you're asking this because you only have a prod environment and so fear making the change, I would push back STRONGLY that this is the EXACT reason one should have a dev or test environment, so as to mimic prod (as well as possible), such that you could make the change there and find your answer without such grave risk.

Let's see if any of the above may have helped you, or if your answers to the questions may help me or others to help you further.
# Posted By Charlie Arehart | 4/22/26 1:43 PM
Thank you kindly for writing back. Your help to the community is very much appreciated as always.

1. last update on the Cf2023 server was Update Level: 18 applied - Fri, 27 Mar 2026. I also do not know for sure what update level the server was on before that. To clarify - we believe this UTF-8 issue may have been present even before the last update but maybe not as prevalent since we are only now update OLD code that was running on CFMX. New Tailwind CSS design UI pages use UTf-8 characters apparently and since our QA person has flagged multiple weird looking characters on our new UI pages we are only now addressing the issue and hence it got me to your blog. In short - we do not really know if it was "working" before and something broke it - but we are trying to get it fixed now !

2. JVM is 17.0.6

3. OS is Windows Server 2022, English en_US and more details below from the settings summary page. I noticed that the Java File Encoding is Cp1252
Java Version 17.0.6
Java Vendor Oracle Corporation
Java Vendor URL https://java.oracle.com/
Java Home X:\<folder>\jre
Java File Encoding Cp1252
Java Default Locale en_US

4. it appears from the settings summary that the file encoding is Cp1252 - and we dare not touch that unless we know for sure that changing it won't break our legacy code.

5. CF is not throwing any errors, all CFFILE reads are working as expected so far - but there are lots of weird characters such as — displaying on various pages. We have tried adding <cfprocessingdirective pageencoding="utf-8"> on top of our .cfm pages but that does not seem to help either.

Thank you again.
# Posted By Himanshu Shekhar | 4/22/26 7:34 PM
Thanks for the kind regards. As for your issue, it's helpful that you've confirmed the problem is not new since any particular cf or Java update.

That said, it's really hard to know then what has led to the change in behavior.

Believe it or not, since you've started editing old code (if seems), note that these character encoding problems can happen BECAUSE OF YOUR EDITOR. And of course, you may have different devs using different editors. One may be stubbornly sticking to a very old one which may be introducing these problems, when they edit code.

Or the problem could be in your database. There are char encoding features in most DBs, settable at the db server, db, table, or column level. Similarly, the change could be about data being sent to the database across the cf jdbc connection, and that has configurability regarding character encoding.

I don't think there's going to be one magic change in cf or its jvm args that will fix this, but again perhaps someone with more familiarity with the problem may say otherwise.

You may want to ask across a far broader set of eyes--even just within the cf community. I list several places where you can ask such questions at cf411.com/cfsocialhelp. Let us know here if you end up with a simple explanation and solution.
# Posted By Charlie Arehart | 4/22/26 9:59 PM
[Add Comment]
Copyright ©2026 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
xByte cloud Hosting