Lucee 7.1.0.71-BETA

news release
1

We’re excited to announce Lucee 7.1.0.71-BETA, the second public beta of the Lucee 7.1 series.

This release builds on top of everything in Lucee 7.0 and adds 33 improvements and fixes focused on performance, Query of Queries, compiler robustness, Java 25/26 support, and a landmark feature: line debugging.

This is a beta release intended for testing and feedback — please do not use it in production.

Download: https://download.lucee.org/

What’s new in 7.1:

Docker and Installers Bundle

  • Java 25.0.2+10-LTS
  • Tomcat 11.0.20

Highlights

Line Debugging

  • LDEV-1402 — Enable line debuggers for Lucee — step-through debugging support for CFML

Java 25 & 26 Support

  • LDEV-6110 — Lucee 7.1 builds and distributes with Java 25
  • LDEV-6092 — Update to ASM 9.9.1 for Java 26 bytecode support

Performance & Memory

  • LDEV-3051 — Replace O(n²) temp folder checkSize with single-pass sort and delete
  • LDEV-3335 — Store component properties and accessor UDFs statically per class, reducing runtime creation overhead
  • LDEV-5908 — Switch to Java ConcurrentHashMap
  • LDEV-5920 — Improve performance loading resultsets from JDBC
  • LDEV-5923 — ThreadLocal PageContext registration optimization
  • LDEV-5953 — Use ThreadLocal buffer pools for IOUtil
  • LDEV-6059 — Avoid using NoSuchElementException as flow control
  • LDEV-6060 — CFMLExpressionInterpreter.identifier() no longer does unnecessary PageSource lookup
  • LDEV-6076 — Eliminate Integer autoboxing in SourceCode constructor
  • LDEV-6077 — Defer ParentException creation for closure calls (99.98% reduction in object allocation for each/map/filter)

Query of Queries (QoQ)

  • LDEV-4182 — Allow QoQ concat() to accept unlimited parameters
  • LDEV-4183 — Add Oracle’s || operator for string concatenation in QoQ
  • LDEV-5897 — Remove bundled HSQLDB bundles from Lucee core (now loaded on demand)
  • LDEV-5992 — Use a connection pool for QoQ HSQLDB queries
  • LDEV-6062 — Avoid exception-as-flow-control in QoQ
  • LDEV-6151 — QoQ case sensitivity and dbtype struct options
  • LDEV-6152 — Fix HSQLDB QoQ column optimization (== instead of .equals() caused silent fallback to loading all columns)
  • LDEV-6153 — Fix QoQ native engine sqrt() function
  • LDEV-6154 — Fix QoQ || string concatenation excluding NULL and empty string rows

Compiler & Bytecode

  • LDEV-5832 — Improve parser/compiler performance
  • LDEV-6126 — Fix MethodTooLargeException with large CFCs (split constructor when CFC has many functions)
  • LDEV-6134 — Fix MethodTooLargeException in <cinit> when CFC has thousands of unique string keys
  • LDEV-6140 — MethodTooLargeException now includes CFC source path, function name and bytecode size

Extensions Moved Out of Core

Lucee 7.1 continues the effort to slim down the core by moving functionality into standalone extensions. These extensions are still bundled by default — your existing code will continue to work — but they can now be updated independently of the core.

Extensions now use GAV (Group/Artifact/Version) notation instead of GUIDs:

The full list of default extensions is defined in the core manifest:

Moved to extensions:

  • LDEV-5825 — Move SMTP/mail functionality to the mail extension
  • LDEV-5914 — Move compress/extract functions and TGZ/Tar resource provider to the compress extension
  • LDEV-6042 — Move FTP functionality to the FTP extension
  • LDEV-5897 — Remove bundled HSQLDB from core — if you use QoQ with the HSQLDB engine, install the HSQLDB extension (it will be downloaded on demand if missing, but pre-installing avoids the delay)
  • LDEV-6002 — Remove old JTDS extension from FAT JAR

Extension infrastructure:

  • LDEV-5959 — Restore basic extract/compress BIFs for zip/gzip in core
  • LDEV-6044 — Refactor OSGi system packages to use Felix JPMS auto-detection
  • LDEV-6054 — Fix extension startup-hook with Maven coordinates not recognized as valid class definition
  • LDEV-6093 — Fix mail and FTP extensions bundling parent POMs

New Functions

  • LDEV-6204 — Add getTransactionIsolation() BIF

Full changelog: Lucee Server Changelogs - 7.1

Testing

We’d love your help testing this beta. Please try it with your applications and report any issues you find here on the Dev Forum.

4 Likes
2

Could you please confirm that the new Mail Extension is working on this version? My tests have failed so far.

Also, I could not find a section at Lucee Admin to review my SMTP configuration, but I assume it is being read from .CFConfig.json.

Thanks in advance!

1 Like
3

I have also tested using SMTP configuration through cfmail tag attributes, but this is not working either.

4

7.1.0.202 quietly came out. You might try that.

5

Thanks! I’ve updated to Lucee 7.2.0.13-BETA, still not working for me.

6

Same issue, cannot send emails with 7.1 or 7.2

7

Michael and Eduardo, I’m only reading along not testing things, but here are a couple of thoughts both for diagnosis and perhaps resolution:

  • it may help to confirm whether you are seeing any logs related to the mail failures, and indeed if mail may be being created/spooled but fails to send
  • it may help to clarify how each of you have implemented the update. There are multiple ways, and sometimes folks who quietly think “works for me” (and say nothing) might have updated Lucee quite differently than you did. Indeed, they may not “update” at all but just implement a new engine via Commandbox, docker, or zip extraction
  • have you tried clearing the felix-cache folder? It’s sometimes needed based on how the update process was done. You would stop Lucee, delete that folder, restart Lucee and test again. Here again, the location of that folder depends on how you run Lucee. I can’t list all the variants. The easiest thing is to search for that subfolder within your Lucee folder.

Let us know if these points are helpful (or not).

8

Hi @carehart, in my case I did a fresh install of Lucee 7.1, and then I updated to Lucee 7.2 via Admin.

I also have a install of Lucee 6, running on another port, so that I can compare things that are not functioning on Lucee 7. In this instance of Lucee 6, e-mail is working perfectly.

9

Ok, and thanks for the clarification.

  1. That said, it was just one of the three points/suggestions I made. Please consider the other two.

The logs could be really helpful here, to know what’s amiss.

  1. And let’s remind folks that you said mail wasn’t working for you from that first install of 7.1, right, before even updating to 7.2?

As a guess, it may be about the version of Java (which underlies Lucee) that’s at issue. Let me elaborate on this here. I hope it may help you or others.

The Java version is raised with different Lucee installers. Your 7.1 would have implemented Java 25, while your 6.1 baseline could be Java 17–but it could even still be Java 11, if you’d started with 6.0 before updating to 6.1.

  1. So first can you look first at the Lucee admin and report what version you’re running?

Note also that the Java version is NOT changed by a Lucee update (such as done within the Lucee admin). It’s changed only per the Lucee installer (if one implements Lucee via its installer).

Indeed, though Java itself gets updated quarterly (by Oracle and the openjdk community), your Lucee (or ACF) instance won’t benefit from such an uodate unless you do it manually. Many never bother. (FWIW I’ve done a blog post on each such Java quarterly update the day it came out, identifying what changed and more, at Charlie Arehart - Server Troubleshooting)

  1. Now, why am I blathering on about this Java version stuff? Because in fact even within a given Java version, it’s those jvm updates which themselves often tighten what java allows, such as when calling out to a mail server, or another web server via cfhttp, etc. Especially if done via tls/ssl.

And yet it may be that you never updated the Java within your Lucee 6 env. The latest Java 11 as of last week is Java 11.0.32, or if your Lucee 6.1 install implemented Java 17, its update last week was 17.0.20. Those last digits increase by 4 each year, for those quartely updates.

And I wonder if you may find you’re years behind. It happens. Not throwing you under the bus, if you may confirm it. (I’m also writing for all others who may read along.)

  1. And if you DID update such an old Java (updating only within that major Java version, I mean), perhaps you’d find that mail on your old Lucee would stop also.

I realize you’d not WANT that to happen. But it would at least show that it’s not Lucee which changed the mail behavior but Java. And then you could change it back to whatever Java version it came with.

  1. If this was the issue, would you be stuck? No. But I’m NOT suggesting you downgrade the Java used by your Lucee 7 implementation.

Instead note that when such jvm updates may “tighten the reigns” in a given update, they document in that update’s technote how you might “loosen them” again.

One prime example is if you may find your Lucee 6 running on Java 11.0.10 or earlier. There was a major change removing support for calling out to servers offering no better than tls 1.1 support. Maybe the mail (smtp) server you’re calling out to has not yet implemented tls 1.2 or above. Java 17 and above (including 21 and 25) would block an attempt to reach it, as would 11.0.11 or above.

But as I noted in [my post about that update](Announcing Java updates of Apr 2021 for 8 and 11 - thoughts and resources - Charlie Arehart - Server Troubleshooting Announcing Java updates of Apr 2021 for 8 and 11 - thoughts and resources - Charlie Arehart - Server Troubleshooting), there is a tweak one could make in the java.security file underlying the Java you implement. And that same tweak could (and would need to) be made in later Java versions–indeed it would need to be made in each Java update. See my post for details. Or, of course, the folks running the smtp server could upgrade their tls support to 1.2 or above, but we often have no influence on forcing that.

Or there may have been some other change of significance in one of the jvm updates.

  1. In conclusion, again sorry for the wall of text. The key questions for you are 1, 3, and perhaps 5.

Folks often want simple answers to what seem simple questions. It’s when those are not forthcoming here nor readily found via their AI searches that more might need to be considered.

Again, only the two of you so far have reported email problems here on 7. I’m just trying to help identify what may be unique for you. Sorry if somehow none of this turns out to be your issue. That takes us back to step 1 here.

10

I fired up my 7.1 VM and tried. With both 7.1.0.71 and .202 I get the NotSerializableException.

Error was added to:
https://luceeserver.atlassian.net/browse/LDEV-5825

11

@KabutoTX1, was this a new install of 7.1, or an update? And what java version are you running? See my last note for more on both points.

And have you tried clearing the felix-cache? See my note before that.

12

More testing. Tried my 7.1.0.202-BETA docker. I still get the NotSerializableException messages in the log but it sends.

Went back to my 7.1.0.202-BETA Debian VM.
*Cleared felix-cache
*Added debug=“true” to cfmail
*Tried 7.1.0.71 (Went back to .202 after didn’t change)
*Changed remote-client and mail logs to DEBUG
*Ran catalina to console
None of the above spits out any error or debug messages.

Added async=“false” to cfmail and that works and get debug.
I assume something with the Spooler.

1 Like
13

@KabutoTX1 nailed it. I changed to async=“false” and it worked.

It might have something to do with the Spooler, indeed.

14

@carehart thanks for your help, anyway.

15

Glad to hear you guys have found a workaround. Two more things.

First, instead of changing every cfmail, know that you can also change that via application.cfc, the Lucee admin, or cfconfig json. (Async is indeed an alias for spoolenable, regarding mail in Lucee.)

Second, I’d hinted at this possibly being at issue in my first reply, when I’d asked “if mail may be being created/spooled but fails to send”. No one ever confirmed. It could be helpful for diagnostic purposes if you would. Either way, hopefully the team can take it from here.

1 Like