Whoa! Community!

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).

Now building/deploying on JDK 25

In early August I upgraded the build and deployment environments of most of my WO apps from JDK 24 to JDK 25 (release candidate). Happily, I didn't experience anything problematic or unexpected so when JDK 25 was actually released last week, I finished the job and updated the customer deployments I control as well. So; everything up and running on JDK 25, including JavaMonitor and wotaskd from wonder-slim-deployment.

This comes with the traditional warning that my setup differs from that of most WO users. Of the 12 apps upgraded, only one uses EOF and the original Project Wonder, the rest use wonder-slim and Cayenne, so YMMV depending on which WO/Wonder frameworks/features you use.

Caveat when moving from JDKs older than 24

WO (NSTimeZone) references the class sun.security.action.GetPropertyAction which was removed in JDK 24, meaning a plain WO/Wonder app will fail to start on JDK 24 and later.

I added a fix for this in wonder-slim by putting in a "replacement" class. Works fine and shouldn't interfere with functionality since GetPropertyAction doesn't really do anything anymore, with Java's Security Manager now more or less removed/disabled. If you have an application you'd like to upgrade and aren't using wonder-slim, you can drop that replacement class into your project and it should run fine. That's what I did with my one remaining Project Wonder/EOF project.

Why upgrade?

There are a number of great reasons to keep your Java installation up to date — that I won't go into. Plenty of folks out there talking about Java in general. But the main reason for my own early adoption was I'd already started using Compact Object Headers as a preview feature in JDK 24. Since that was finalized and released in JDK 25, I felt it was worth the experiment.

Although I haven't done any formal benchmarking suitable for publishing, Compact Object Headers resulted in reduced memory use and well perceivable performance improvements in my apps, so I can recommend trying it out if performance is something you care about. Just add -XX:+UseCompactObjectHeaders to your application's arguments and you're good to go.

Still doing development on JDK 21 though

Although my apps are now built and run on JDK 25 I still target and do development on JDK 21, mostly because I can't live without DCEVM, now released as a part of the Jetbrains Runtime. Now eagerly waiting for JetBrains to release a JDK 25 runtime so I can upgrade my development environment as well.

We now have a page showing a quick overview of WO/ng related development activity on GitHub, access it by clicking Dev feed in the main navigation bar.

For obvious reasons the list of repos is a little skewed towards my own repos, mostly because these are currently the repos I know of, use and care about. Let me know if you'd like to see some repos added; your own, someone else's or WOCommunity's. If many more repos get added, I'll probably enhance the functionality a little to allow some customization and filtering of the commit list.

Note that the list is a little skewed since it only shows the 20 most recent commits to each repo's main branch (what we get from github's RSS feed). So this isn't all development activity back to 2023, for that I'd have to use a different method.

Suggestions for more useful stuff to add to the list or the site in general very welcome.

Exciting times, we have a new WO version! Issues fixed include:

• EOF Database snapshot not updating
• Webassistant not available for D2W apps
• Exceptions when using WOTextField with formatters
• Duplicate primary keys generated by FrontBase JDBC Adaptor under load
• Additional issue fixes