InaccessibleObjectException when accessing node properties

[ptziegler]

This is an issue that started to pop up after updating our product to the Eclipse 2025-12. Trying to access some properties of a GEF edit part is no longer possible (both during recording and during replay) and instead fails with an InaccesibleObjectException.

Below the error we get during recording:

Contains: Failed to get property nodes for path "getTargetConnections()".
java.lang.reflect.InaccessibleObjectException: Unable to make public int java.util.Collections$EmptyList.size() accessible: module java.base does not "opens java.util" to unnamed module @58c48311
	at java.lang.reflect.AccessibleObject.throwInaccessibleObjectException(AccessibleObject.java:391)
	at java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:367)
	at java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:315)
	at java.lang.reflect.Method.checkCanSetAccessible(Method.java:203)
	at java.lang.reflect.Method.setAccessible(Method.java:197)
	at org.eclipse.rcptt.tesla.swt.reflection.JavaMembersHelper.collectMembers(JavaMembersHelper.java:308)
	at org.eclipse.rcptt.tesla.swt.reflection.JavaMembersHelper.collectObjectMembers(JavaMembersHelper.java:295)
	at org.eclipse.rcptt.tesla.swt.reflection.JavaMembersHelper.fillProperties(JavaMembersHelper.java:121)
	at org.eclipse.rcptt.tesla.swt.reflection.JavaMembersHelper.fillProperties(JavaMembersHelper.java:94)
	at org.eclipse.rcptt.tesla.gef.GefModelMapper.getPropertyNodes(GefModelMapper.java:163)
	at org.eclipse.rcptt.tesla.recording.core.gef.GefFigureLocator.getNodeProperties(GefFigureLocator.java:657)
	at org.eclipse.rcptt.tesla.recording.core.gef.GefRecordingHelper.getNodeProperties(GefRecordingHelper.java:140)
	at org.eclipse.rcptt.tesla.ecl.internal.impl.commands.GetPropertyNodesService$1.run(GetPropertyNodesService.java:50)
	at org.eclipse.ui.internal.PendingSyncExec.run(PendingSyncExec.java:68)
	at org.eclipse.ui.internal.UILockListener.doPendingWork(UILockListener.java:166)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:132)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4137)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3753)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1147)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1038)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:153)
	at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:677)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:339)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:583)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:173)
	at de.dsa.prodis.automation.AutomationApplication.start(AutomationApplication.java:321)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:219)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:149)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:115)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:467)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:298)
	at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.lang.reflect.Method.invoke(Method.java:580)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:615)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:563)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1415)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1387)

Under the idea of "integrity by default", the Java team is trying their hardest to make the method setAccessible(...) as unusable as possible, which then causes problems when RCPTT tries to load those properties.

org.eclipse.rcptt/runtime/tesla/org.eclipse.rcptt.tesla.swt/src/org/eclipse/rcptt/tesla/swt/reflection/JavaMembersHelper.java

Lines 299 to 316 in f508ced

	private static void collectMembers(Class<?> clazz, MembersContainer acc) {
	for (Field field : clazz.getDeclaredFields()) {
	if (checkField(field)) {
	field.setAccessible(true);
	acc.addField(field);
	}
	}
	for (Method method : clazz.getDeclaredMethods()) {
	if (checkMethod(method)) {
	method.setAccessible(true);
	acc.addMethod(method);
	}
	}
	Class<?> parent = clazz.getSuperclass();
	if (parent != null) {
	collectMembers(parent, acc);
	}
	}

In this specific case, the problem is caused by calling size() on a List. Which is a public method, so the call to setAccessible(...) should not be needed here. Perhaps it is already enough to only call this method for protected methods and/or fields?

If I understand this correctly, RCPTT also only accesses public members, unless enable.protected.members is enabled. Perhaps the call could also be guarded by that?

The reason why it shows up for us now is likely because one of the projects we include uses BurningWave to break Java encapsulation. This behavior is now disabled by default with the version we updated to.

[basilevs]

@ptziegler Which version of RCPTT do you use?

I'm unable to test on Java 25 and would like to send you a blind patch build.

[ptziegler]

@basilevs I've just updated to the 2.7.3

[basilevs]

@ptziegler I've prepared an untested fix based on RCPTT 2.7.4 Nightly. Please find it in an repository(.zip) file at the bottom of build page https://github.com/eclipse-rcptt/org.eclipse.rcptt/actions/runs/21907057664
If you have installed RCPTT as a plugin, you may update from that ZIP. Otherwise install RCPTT IDE from that repository into Eclipse Platform 2025-06 (I think product updates are broken).

This fix will likely target RCPTT 2.8.0, to be released soon (likely this month).

The main idea behind the fix is to prefer public classes when looking for method definitions in an object class hierarchy. I've also suppressed setAccesible() for public members almost like you suggested (but not quite exactly so).

[ptziegler]

@basilevs Thanks! Sadly, the Maven build only spits out the gtk-based IDE. But our product exclusively runs on Windows. Nonetheless, I managed to integrate this patch and can confirm that at least during recording, the properties are shown again.

Sadly, things still blows during the replay. The expression is failing with something like:

get-property "getSourceConnections().size()" | equals 0 | verify-true

And the only error I'm getting is:

Assertion of getSourceConnections().size() failed. Unable to make public int java.util.Collections$EmptyList.size() accessible: module java.base does not "opens java.util" to unnamed module @25afa0f1
	at verify-true

...which seems to be produced by the SWTUIProcessor. I think there's a good chance the MethodNode/FieldNode also need to be adapted.

I've spun up a local build where I put the call to setAccessible(true) for those classes in a simple try-catch block, to see if this is the only place that needs to be adapted. I'll try to get back to you tomorrow.

[ptziegler]

Maybe just as an additional idea: With Java 9 there's a trySetAccessible() method for fields and methods. Why not simply replace the calls to setAccessible(true) with that? Things will still break when accessing an internal method, but when calling it on a method that is already public, it's effectively a no-op.

If access cannot be enabled, i.e. the checks or Java language access control cannot be suppressed, this method returns false (as opposed to setAccessible(true) throwing InaccessibleObjectException when it fails).

[basilevs]

Another fix is ready I now have an AJDT compatible with Java 25, so I need to test that more.

[ptziegler]

@basilevs That seems to have done the trick. 😄 Both recording and replay now work without issues again.