What behaviour in Lucee which is too "clever" would you like to see gone in 6.0?

Any behaviour where Lucee decided it could be more clever than CF and does stuff differently just because it can.

I'd get rid of the Gzip compression option in the admin (as recent conversations brought up), this is much better to be handled by the web server. The more of the edge case that can be removed, the better.

Ooh the way it tries to resolve mapping paths and gets confused on *nix? Does that count?

I think @Adam Cameron would vote for it not randomly changing JAR files too 😃

Does this count? https://luceeserver.atlassian.net/browse/LDEV-3738. Lucee is second-guessing (badly) what one might want to see in an exception and losing important stuff

but honestly, what is the problem with an opt in gzip setting?

Igal would like to make localmode=true default

Do you mean the application setting, or the attribute on a function (and a component?) If the latter... I can't see why not? One would have to tread cautiously if one is writing cross-platform code (basically: don't use it). Other than that, it's intrinsically opt-in, and it's localised to the code leveraging it, so doesn't cause any "surprises".

what is the problem with an opt in gzip setting?

I know there was a thread somewhere about this issue, but it's more likely to cause issues than not. It's really something the web server should be doing for you. Since it's not really a feature that's needed, it makes sense to remove it. Less code = less bugs, less issues, less code to support. Sometimes it's easy to go "oh that's easy to add, let's just add it so we have more features/options", but I'd rather Lucee concentrate on the hard stuff and leave stuff like this out that's better handled elsewhere. Unless I'm missing some use case where having this enabled is critical functionality.

it's about OOTB being modern cfml (localmode)

it's about OOTB being modern cfml (localmode)

Absolutely not then. For the reasons you cite. Indeed the application-setting implementation would be a good one to remove for being "too clever". It just can't work with modern applications that use third-party libs. It woulda been fine back in 2003. It's too late now.

yup, we don't have even have component localmode="true" {}

I would deprecate the lot.

nup, it's not apparently

Really? I mean like third-party code could not use it, as it's meaningless in CF. However for one's own applications that are destined to only run on Lucee... I don't see the downside? What am I missing?

This one fits the description, I think. Looks like it might already be set for 6.0 though? https://luceeserver.atlassian.net/browse/LDEV-2164

@danmurphy Good call on the URL Encoding thing. It's a compatibility issue with ACF too.

You know how Ortus is adding things to ColdBox, that are in Java but nicely managed. That is my standard, Kudos to Ortus for the awesome progress. Now, to answer your question... not just Lucee, but could we get rid of things like CFML version of CFThread! Seriously difficult solution that could be depreciated.

What about moving features out to extensions that are no longer commonly used? That way if you have an old app using the feature all is not lost, and it allows lucee’s core code base to be lighter and cleaner.

I had suggested a similar thing for all the stuff that Lucee actively (but generally needlessly / unhelpfully) has decided to do different to CF. The default Lucee install then just behaves as close to CF as poss, with add-ons that override or "improve" or add-to behaviour.

@foundeo you mean remove unsupported old tech, applets, flash, mediaplayer, video (473 KB) https://luceeserver.atlassian.net/browse/LDEV-3343 (merged) 6.0.0.178

My interpretation of that is to split out stuff like <cfajax* />, <cfdiv>, <cfform>, <cfinput>, <cfmap>, <cflayout>, etc. which really aren't recommended to use anyway (but keep as an extension for people trying to convert legacy apps) and remove things like <cfapplet /> or any other tag that wouldn't be supported by any of today's browsers.

you mean this? https://luceeserver.atlassian.net/browse/LDEV-4072

Anything that's really better off by just doing implementing the work manually client side I'd split out into it's own extension.

they are all already extensions

depreciation and extension seem like mixed meaning, lol

Yes, that ticket looks like it would cover it

exactly

Tomcat 10, seriously, beat adobe to this. A spool / debug attribute / tag (HEH) so you could see the inner workings of anything called. Example CFDOCUMENT SPOOL = MYSPooL1 l= /someplace/ see exactly what was fired off at the bite code level, the second argument could be the staging of the execution of the code, ie . read, executed, files touched. Think of it as a PRE-HOOk for the JVM just as the lucee engine reads the file, It would be great to stop it at the lowest level without a CFUMP, and see what happened to the code. It could even output all 4 parts of the code, be it the read, the lookup, the logic then the execution. Seeing exactly what was run is huge in learning how to write better code, plus, my god a built-in function to debug (beyond CFUMP)