Switching java regex engines on the fly

documentation
1

I noticed a few people pointing out because of legacy / third party code, it wasn’t really feasible to adopt the new java regex engine option in Lucee via an Application.cfc setting

I was discussing this with @micstriit and suggested the following workaround

<!--- classic regex stuff --->
<cfapplication action=“update” regex=“java”>
<!--- do modern regex stuff --->
<cfapplication action=“update” regex=“perl”>
<!--- back to classic regex stuff --->

Application.cfc and <cfapplication>, only affects the current request, of course the application scope is shared, but settings are per request / thread, something I didn’t have nailed down in my mental model

2 Likes
2

Would be groovy if we could define this on per-component basis. That would make it really easy to pull new components in , regardless of their choices.

3

we probably will add an engine argument to all the regex BIFs

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

4

If expanded further this would open up a whole new level of coolness, why stop at regex?

perl :slight_smile:

5

This would seem to have the same issue that any of these code-behaviour-change-switches in Application.cfc have: third-party code.

It’s fine if in my app I decided to use [variant x] of whatever one of these switches does, but we all pretty much use third-party dependencies that will have to use the default setting. Which means one can’t change it on a request by request basis in an app that uses third-party code, because that code will be assuming [default].

It’s just… not a very good approach to solving the perceived problem. Never has been.

Why don’t you just leave the built-in functions alone, and if someone wants to use the Java regex engine… they just can. It’s easy. If they can’t work out how, then they’re probably not the sort of dev that would be giving a shit about which regex engine is being used anyhow, cos they have NFI what a regex engine is in the first place.

Or if someone really thinks this is a significant enough gap in the Lucee community, then they can write a lib and sling it up on ForgeBox and ppl can use it if they want.

Or on Lucee 6 just say “there is a breaking change, we are switching regex engines”, and JFDI. Ppl can either heed the breaking-change warning and do something about it. Or ignore the breaking-change warning, get bitten on the bum, and then you can remind them “shoulda paid attn to the break-change warning, yeah?”.

Please don’t add more of these switches. Please.

6

This is the only not-terrible suggestion on this thread. But I still think it’s a solution looking for a problem.

7

hahaha, seems you can’t decide between which hat you are wearing, either it’s “only do what ACF does” (hint they did it) and “don’t do what ACF does”?

it’s a programming language, developers can decide what they do to solve a problem

if somebody is perfectly fine with the old oro engine, but they hit a problem, which is solved in the java engine well look, they can solve it using the above approach and get on with their day…

this ain’t Twitter 2.0, nobody is holding you hostage at tweet point

1 Like
8

ColdFusion does this:

?

I will freely concede I do not keep up with every stupid thing CF does. You are positioning this like “a new idea” not “what CF does”. Had you said “should we do what CF does?”, I’d’ve just gone “yes”.