Currently, the code uses resultClass.equals(Map.class), resultClass.equals(List.class), etc. This means if a user passes a specific implementation class (like HashMap.class, ArrayList.class) or a sub-interface, it fails to match and falls through the built-in transformers. It should ideally use isAssignableFrom() to properly support implementations and sub-types.
The fallback logic delegates almost everything else (that isn’t a basic type descriptor) directly to NativeQueryConstructorTransformer. This makes it difficult to handle custom transformers or specialized parsing logic gracefully, often resulting in unexpected mapping errors for non-standard structures.
A globally defined parser should be allowed; currently, it can only be set each time using .unwrap(NativeQuery.class).setTupleTransformer(...) or .setResultTransformer(...).
It is our goal with these checks to be as abstract and specific as possible, to avoid over-promising a certain type. Using isAssignableFrom() is not an option, because the passed in class could have a proper constructor, yet the class extends HashMap.
This is on purpose and is the behavior we want to support.
You will have to set your own result transformer per query. There is no intention to do any special handling of result types at this moment.