The problem with (some) Java collections in WO
October 1, 2025

Using good ol' Java collections usually works great in WO templates.

However, in the past years the JDK has been increasingly introducing the pattern of factory methods that return private implementions of public interfaces. Examples of commonly used methods that do this are List.of() and Collectors.toList().

This poses a problem for us WO-folks, especially in templating, since when KVC encounters a class like this (a private class implementing a public interface) it will fail to locate the correct method to invoke, causing an exception.

Examples:

var size1 = NSKeyValueCoding.Utility.valueForKey( new ArrayList<>(), "size" );
var size2 = NSKeyValueCoding.Utility.valueForKey( List.of(), "size" );

var filteredList = people()
					.stream()
					.filter( p -> p.name().startsWith( "H" ) )
					.toList();

var size3 = NSKeyValueCoding.Utility.valueForKey( filteredList, "size" );

Obtaining size1 will work fine since ArrayList is a public class - but the same will fail for size2 and size3 with an IllegalAccessException.

I occasionally worked around this by wrapping collections in a public class like ArrayList when returning from a method I expected to use in a WO template - but obviously, that's no solution and quite the bother.

A fix for WO's KVC

To make life easier, I've added a hack in wonder-slim to fix this: ERXKVCReflectionHack.

This is a small modification to KVC's default way of invoking methods, making an inaccessible method accessible on it's first invocation. If you're not using wonder-slim, you can drop this class into your own project to fix this - or add it to the actual original Project Wonder if you're brave enough. I have a general policy of not changing Wonder myself since I rarely use it, meaning I can't contribute much actual testing. Unfortunately, the best way wo know if a "fix" works is to see it running without problems for a while (this one's been in use in all of my projects for a couple of months).

While the patch works we'll probably have to update it soon since we're using deprecated functionality from Unsafe to replace a private static final field in KVC's default implementation. But that's for later.

A more acceptable/correct fix

ng-objects has a more generic fix in progress that attempts to properly locate an interface method to invoke when encountering an inaccessible method. Using this method in KVC would involve some hacking, but I'll probably look into it once the time arrives (as in; when the functionality we're using in Unsafe gets removed).