Hmm, ok. I have made some updates to the caster. The rule of thumb used to be this

• if the type passed was on our "short list" of known java types (string, boolean, int, double, float, etc), you get a native java array back

• all other types (struct, array, BL types like numeric, CFC names, or any other java class) then you get a BL array back

I’ve changed it to this

• if the type is a Java type (class, super class, interface, or super interface) then you get a native Java array back.

• all other types (struct, array, BL types like numeric, CFC names) get a BL array back

We test whether it’s a java class in bullet 1 by checking our list of “known” names (which allows case insensitive and shortcut versions only having the class name). If it’s not in that list, we try to ask the java class loader if it can find it in the class path. In that last case, it must be spelled exactly correct.

This means you can cast a struct to a Map, a map, a java.util.Map, or a java.util.map since we’re just doing string matching on the name, but only a java.util.Map[] will work as an array since that isn’t in our list of “known” classes so it must be the fully qualified name, and with the proper case. And, in that case, you would get a native java array since the type was found to be a Java class.

hmm, beta14 seems to work with the test and so does the current snapshot. I have been testing the snapshots as fixes are rolled out so no idea which one the error occurred in I'm afraid.

We are having issues with a bunch of direct java calls not finding the function called so there is something up with the interop I think but we haven't got a reproducible test yet

That sounds like an issue with our java interop though. BoxLang should have no issues turning a BoxLang array of strings into a java array of string automatically, even without the java casting. What was the actual error?

it broke our code as we are calling a java function directly and it wasn’t finding it due to the argument not being cast to a string

This was the actual code that broke:

CF’s casting also has situations in which this same syntax deals with normal CF arrays as in Struct[]. There are basically no docs for Adobe and Lucee in regards to what their guaranteed behavior is for the [] syntax and the caster in BL doesn’t necessarily guarantee which type of array you’ll get back because due to our java interop, it really shouldn’t matter. Did this difference cause you an actual issue in your code, or did you just notice it was different?