Jan 4, 2018 12:00 AM is invalid in JAVA 21

We have updated our development lucee servers to Java 21 and are seeing a date time issue:

false in:

|Version |Lucee 6.1.1.118|
|Release date |Nov 11, 2024|
|Loader Version |6.0.3.1|
|Servlet Container |Apache Tomcat/9.0.89|
|Java |21.0.5 (Eclipse Adoptium) 64bit|
|OS |Windows Server 2022 (10.0) 64bit|
|Architecture |64bit |

true in:

|Version |Lucee 6.1.1.118|
|Version Name |Gelert|
|Release date |Nov 11, 2024|
|Loader Version |6.0.3.1|
|Servlet Container |Apache Tomcat/9.0.89|
|Java |11.0.23 (Eclipse Adoptium) 64bit|
|OS |Windows Server 2022 (10.0) 64bit|
|Architecture |64bit |

Someone can correct me if I’m wrong, but I don’t believe Lucee 6.1 supports Java 21 yet. (I do know that while cf2025 will, 2023 supports only Java 17, and cf2021 supports only Java 11.)

And as you had things working with Java 11, since that’s still supported/updated. Why the jump? You were on 11.0.23 (from Apr 2024), and as you may know 11.0.26 came out Tuesday. More on that in my post here:

While my focus there is on Oracle Java (since that’s what acf supports), the openjdk’s are updated at the same time.

And as noted there, Java 17 was also updated the same day. It, along with 21 and 11 (and even 8), are still supported/updated LTS (long term support) Java versions.

On this point, is there any single page that lists what Java versions are supported by what Lucee versions? I keep a table like that for cf, in a blog post, since I can’t offer updates to cf docs.

If none yet exists for Lucee, I or anyone could certainly offer a pr for such a Lucee docs page–but it would need to be kept updated by whoever knows the state of things. That seems to change within versions, which doesn’t seem easy to track here or in jira tickets.

Anyway, let us know if you’re open to updating Java 11 as an alternative to running 21.

I am successfully running Lucee 6.1.118 and Oracle Java 21

Of course, it should be said that successfully running Java 21 with Lucee and having it run your particular app/s doesn’t mean that that’s supported–or that folks should expect all code to work. :slight_smile:

Anyway, while we await confirmation from anyone knowing the state of Lucee’s formal support of Java 21, I was wondering if the OP might find that an updated Java 11 or even 17 could both run their code and serve whatever Java needs they have.

In the 6.1 sections is says

Lucee 6.1 introduces full support for Java 17 and 21, as well as Java 11

It does look like there have been changes to the way Java handles dates in recent versions which has had knock-on effects on Lucee.

https://luceeserver.atlassian.net/browse/LDEV-4658

FWIW, Lucee 6.2 on Java 21 still returns false for:

Dump( IsDate( "Jan 4, 2018 12:00 AM" ) )

… whereas Lucee 5.4.6.9/Java11 returns true.

But if you remove the comma, 6.2/Java21 reports true:

Dump( IsDate( "Jan 4 2018 12:00 AM" ) )
1 Like

Excellent. Thanks, Jed. Great to see that’s clarified there. That’s what I was hoping for.

As for the OP’s date problem, I don’t see that page indicating anything related to changes in date handling. Again, they may want to test Java 17 or even the latest 11–if only to narrow in where the issue was introduced. It may not be 21 itself.

BTW I’m writing from my phone, which is why I don’t just “try it” myself now. (And trycf doesn’t let us change the Java version it uses.)

You mean the ticket I referenced, Charlie? The description says

“With Java 19+, i.e. java 21 for most users, the space before AM/PM is no longer a space, but a non breaking space, which breaks existing behaviours”

Doesn’t that indicate changes to date string parsing at least? Maybe “date handling” was the wrong phrase. Working with Boxlang lately I’ve noticed date parsing to be quite different to Lucee/ACF and I wondered if that was connected with the minimum Java 21 requirement. Of course you know a lot more about this than I do so please correct me :slight_smile:

Julian, my reply ws to Jed (as indicated in its salutation). :slight_smile: And my reference to “the page” was the helpful Lucee docs page he pointed us to. I was simply saving folks the time of looking to see if that page made mention of anything related to dates: it did not.

As for your subsequent comment and the jira ticket info, that may well help the OP or others facing this, and thanks for sharing it.

Though I will use this as a chance to observe how this sort of situation can happen: that something is discussed in a jira ticket or forum thread, perhaps proposing a workaround or even a solution…but it never makes it to the docs.

And here’s a perfect example where we can’t just expect someone to “do it now” for this issue, at least based on info shared here. It’s unclear (for now) what the cause was, and while your workaround may well suit some, others would hope the problem might be solved in the engine instead.

So we wait…and ultimately either it WILL be fixed (and so nothing needs to be documented), or it will remain unresolved (and someone participating in this thread or viewing it later would need to take steps to get the issue added to that doc–if indeed it started with 6.1 and a move to Java 21).

I’m not complaining, just lamenting how things can languish/get lost/forgotten. And as I said originally, I’m open to being corrected if some process would or could address this sort of situation.

Ah, sorry Charlie. I misunderstood.

Should I be submitting this as a bug?

Short answer: yes. Before you do, I can offer another workaround to consider (beyond Julian’s). And I’d proposed that gathering some more info could be helpful. I can now offer that also for you and interested readers.

First, I’d proposed you might want to first confirm if the same problem happened if you used Java 17, or the most recent Java 11. I can now confirm it does not happen with them: this is new to Java 21–technically Java 20, which was a short-term release. (I tested both.)

And I’d said it would help if you might give us a single line standalone example that any of us could run, to test things out for you. (I don’t see one in your initial post".) Thankfully, Julian’s is sufficient to demonstrate the issue.

As for the other workaround I can offer, note that if you add this JVM arg to the startup of Lucee, the error goes away:

-Djava.locale.providers=COMPAT

I found this in in a 2020 spring discussion of a similar problem, and it worked. As it notes, Java 23 is due to remove that COMPAT option (also a synonym for JRE as an option there), so this is not a long-term solution. And such a JVM arg change could have side-effects worth someone exploring.

Yet another discussion (totally unrelated to CFML) indicated that an option is to NOT have that “newer” CLDR locale provider (from Java 11) being first in that list, so one could do COMPAT, CLDR, SPI ,HOST (as the default seems to be instead 1CLDR, COMPAT, SPI ,HOST1). Again, though, there may be other impacts of such a change.

There’s some discussion of the CLDR matter in that Lucee Jira ticket Julian referenced–so they were aware of that a couple of years ago. But I’ll note that ticket was solving a slightly different problem and it was indeed closed as fixed back in 6.1.0. Like you, I was testing on 6.1.1.

if you might not want to go with the jvm arg change, I’ll add that besides Julian’s suggestion of removing the comma (which did work for me also), it’s perhaps worth noting that removing the time also “solves” the problem, but you may want that. And FWIW, changing the date to a numeric one also works, as in:
Dump( IsDate( "1/4/2018 12:00 AM" ) )

But perhaps removing the comma alone may be “easier” for you. :slight_smile: Anyway, those are other options for folks to consider, if faced with this, until it may be “fixed”.

FWIW, all these variants and your original one as well work just fine in CF2025 beta, which runs on Java 21. Interestingly, I see it’s that Adobe does by default set that -Djava.locale.providers=COMPAT,SPI, and in fact they even did that for CF2023, which is interesting to see.

Finally, let us know the bug report link if you go that route: we here are not all notified when such bug reports are filed.

It need not be more than a sentence or two, really. You can offer just that one line of code as Julian did, and perhaps show the alternatives that do work. Mentioning that jvm arg may be helpful. The engineers should be able to sort it out from there. If you added a link to this thread, it MIGHT benefit them…or at least tie things together for future readers.

2 Likes

First and foremost I want to thanl everyone for their time on this issue.

A simple single line example is:
Dump( IsDate( “Jan 4, 2018 12:00 AM” ) )
returns false when on java 11 it returns true.

We found the problem when we attempted to add use dateadd() on that specific date.

Fortunately we found the issue in our development environment which we recently updated to Java 21. We still run Java 11 on our production environment and as it stands it looks like that is where we will be staying.

I will open a ticket with lucee.

Thank you

Are you “staying” because you don’t want to implement the simple jvm arg workaround? Maybe you mean you don’t want to wonder about unexpected side-effects or test for such things, and fair enough.

I just wanted to make sure that that simple solution didn’t get lost in the shuffle. And again, Adobe implements it by default in acf for better or worse.

It did get lost in the shuffle. We changed our code to format dates differently. That is our workaround for now. I rather not add anything to the java args in order to get around this issue. We have 4 different tiers with a combined 50+ lucee installations. The would be quite a bit more work than fixing code at this point. I hope that this issue can be resolved on the lucee side. I will however add -Djava.locale.providers=COMPAT to some of our development VMs for testing purposes.

I can attest that adding -Djava.locale.providers=COMPAT does fix the issue.

Here is the open issue with lucee. Jira

1 Like

This might be due to Java 21 CLDR change.

What locale?

Thanks, and understood. I’d proposed code fix alternatives also, but I suspected most would find that MORE work than changing the jvm arg. :slight_smile: But certainly for some setups it’s the opposite. Glad you’re sorted.

Kabuto, the issue is indeed with cldr, and FWIW I can confirm that for me I was using the default locale for the US (I don’t set it, leaving that to the jvm and os to sort that out.) But again the jvm arg change solved things readily, and the resources pointed to above elaborate on the details of the cldr issue.