Am wondering if someone can cast some light on Lucee's inner workings when it comes to creating Java objects. Here's a gist: https://trycf.com/gist/8b67cae6202d341ed8ade82c913a5250/lucee5?theme=monokai Relevant bit:

try {
    radix = 36
    result = CreateObject("java", "java.math.BigInteger").init("42", radix)
    writeDump([result, radix.getClass().getName()]) // 146, java.lang.Double
} catch (any e) {
    writeDump([e.message, e.detail])
}

What I'm wondering is... given

radix

is a Double, and BigInteger doesn't implement a constructor that takes a Double for the radix (see https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/math/BigInteger.html), how this code runs, rather than giving something along the lines of "no suitable constructor found for BigInteger(String,Double)"

@Adam Cameron I thought it might be casting the double to an int, seeing that the value could be safely converted to an int, but changing the value to a decimal still does not throw an error.

@Adam Cameron You're dumping out the class name of the

radix

variable, not the

result

variable.

I think perhaps you need to re-read what I asked, Brad

NP mate

What happens is Lucee, upon not finding a perfect match for the constructor args, attempts to see if it can cast your args to suitable values

I'm just wondering why using the "wrong" type works

My guess is Lucee is using this constructor https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/math/BigInteger.html#%3Cinit%3E(java.lang.String,int)

I can "see" why that might be an approach to have considered I guess

Since it figured it could cast your double to a string

I guess the radix param is an int not an Integer so perhaps not so straight fwd to create a Java primitive in CFML

it converts a Double to an Integer https://github.com/lucee/Lucee/blob/c21e2d280f2b27e15c6f00e1990e0b83d7e274c6/core/src/main/java/lucee/runtime/reflection/Reflector.java#L685

(from RTFMing, not testing it...)

looks like it tries very hard to find a match, bdw is right about auto/magic conversions

Still: I think Java is well and clearly documented, so just leaving out the magic would have been fine I think.

message has been deleted