This repro case can be made much more simply like so

just using a JDK class.

Brad will tackle this one. We will follow suite with the no-arg constructor.

Yes, we need to be auto-calling the no-arg constructor, if found, when an instance method is called on a class. I pointed this out internally a few months ago. This is a documented feature of CF and quite simple.

Not really. Imagine if a class has 5 constructors. Which one would you call?

The no arg one As documented.

What if it doesn’t have ANY constructors?

CF errors, which is reasonable.

Will Adobe/Lucee call the constructor twice

No, they would not. The constructor is not called when the class is loaded, it’s called when and if you call an instance method but don’t have n instance. So basically, our dynamic object needs to detect if there is no targetInstance and the method being called is an instance method, and create the instance via the no-arg constructor on the fly like CF does.

Not really. Imagine if a class has 5 constructors. Which one would you call? What if it doesn’t have ANY constructors?
In reality, the concept of instantiating a class is not the same as creating an object proxy.

If you would have used new redis.clients.jedis.params.SetParams() Then the constructor is called, which one, it will match the arguments you sent to it. However, since in ACF/LUCEE, you can do what I just did of using the new operator in java classes.

Anyways, this is something to discuss if we want to venture into auto-calling the no-arg constructor or not. It’s also bad practice, because what happens if you do this:

Will Adobe/Lucee call the constructor twice

I was under the impression that init is always implicitly called when creating an object (in ACF anyway), I guess if you wanted that behaviour it would be better placed as a call to init in the constructor. But I guess ACF just goes right ahead and calls it anyway