NullPointerException at ExpressionHelper.java:386 during zoom when connections with volatile control-point anchors are present (JavaFX 25)

[Gerhard-2026]

Component: GEF FX

Severity: Regression (broken on JavaFX 25)

Summary
A NullPointerException occurs in ExpressionHelper.fireValueChangedEvent during mouse-wheel zoom whenever a Connection carries volatile control-point anchors (i.e. anchors inserted by an AbstractRouter subclass). The crash is a regression introduced by JavaFX 25 (or before, presumably by a change in ExpressionHelper).

Stack trace (abridged):
java.lang.NullPointerException
at com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:386)
at javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(...)
at javafx.beans.property.ObjectPropertyBase.set(...)
at org.eclipse.gef.zest.fx.behaviors.ConnectionClickableAreaBehavior (stroke-width change)

Root cause:
In org.eclipse.gef.mvc.fx.behaviors.ConnectionClickableAreaBehavior 'scaleXListener' is a manual invalidation workaround that can trigger re-entrant invalidate() calls during lifecycle transitions which cause the NPE.

Reproducer:
Create a Connection that is routed by a custom AbstractRouter subclass which inserts and removes several VolatileStaticAnchor control points on each routing pass.
Trigger several re-routes (e.g. by resizing the window or panning the canvas).
Scroll the mouse wheel to zoom.
→ NPE at ExpressionHelper.java:386.

Suggested fix:
Consider binding the DoubleBinding directly to mxxProperty() and removing the explicit listener.
Also unbind clickableAreaWidthProperty() before disposing the binding in doDeactivate().

Environment:

• GEF version: 5.5.1
• JavaFX version: 25
• Java version: 25
• OS: Windows

Note: I encountered the NPE - all the technical analysis (including a workaround for me) and a draft for this issue report was done by GitHub Copilot (no adverstising, just to let you know).

[azoitl]

@Gerhard-2026 thx for your report. Please note that currently there is nobody to maintain Eclipse GEF 5. Therefore we are considering to archive this repository. See also: https://www.eclipse.org/lists/gef-dev/msg02240.html

If you can provide PRs for your issue or want to step up to take over Eclipse GEF 5 please let us know.

[Gerhard-2026]

@azoitl sad to hear that there is no maintainer any more. I don't feel able to take over GEF 5 (concerning time and full understanding). Our RCP (which I'm currently porting to E4.39 / Java25 / JavaFX 25) depends on GEF. What are the alternatives to GEF (GEF5). Stepping back to classic GEF (GEF3) is not an option, because it introduces E3 dependecies.
GH Copilot brought patching AbstractRouter into play, but as this class is part of GEF5 I declined. So, no I haven't a PR. Copilot came up with a solution (workaround) for me, that does not require touching GEF5 code.

[azoitl]

We had a similar situation with Eclipse GEF Classic (formerly kown as GEF3) before others and I stepped up to keep it alive. For a long time we did what Copilot suggested you. Patched on our side. From my experience with GEF Classic up-streaming the patches is most of the time a better solution. But I understand that this is not easy.

Stepping back to GEF classic is for several reasons not an option. Mostly because of the different application and rendering model. E3 is the smaller issue.

[Gerhard-2026]

@azoitl : in our case we have a standard SWT-based app with two parts using GEF within a FXCanvas, so replacing it seems feasible but must be done without introducing E3 dependencies. On the other hand, what we use of GEF does its job pretty well and therefore I'm somewhat reluctant to replace it. Contributing to GEF in the sense of providing patches to keep the status quo might be possible, but it must be at lowest effort. Is there a way to achieve this?

[azoitl]

I fear that patches alone will not safe GEF5 because we need people that would then also be able to provide releases. While i can support for the former I'm not able to help with the latter.

[vogella]

I think the future orientated approach would be to offer a Eclipse 4 GEF classic variant of the 3.x API but I'm not sure how much work that would be.

[ptziegler]

I think the future orientated approach would be to offer a Eclipse 4 GEF classic variant of the 3.x API but I'm not sure how much work that would be.

GEF 4.x has a different package-name (org.eclipse.gef4.*) than both GEF 3.x (org.eclipse.gef.*) and GEF 5.x (org.eclipse.gef.fx.*). Both GEF 4.x and GEF 5.x also lack the Draw2D abstraction layer and instead, they talk to the JavaFX API directly.

A migration layer is just not going to happen unless, as Alois already mentioned, someone is willing to step up and do the work.

[vogella]

I meant Eclipse 4 (e4) for get classic

[ptziegler]

As discussed in eclipse-gef/gef-classic#580, you can already use GEF 3.x in a pure E4 environment (likely with a lot of caveats). Though right now, you still carry a required dependency to org.eclipse.ui.workbench.

[Gerhard-2026]

@vogella & @ptziegler: thank you for joining the discussion :-)
@ptziegler: yes, I know that GEF Classic can be used in a pure e4 app. But it brings in org.eclipse.ui and org.eclipse.ui.workbench.

In our app we have a big (concerning the amount of code) part using GEF.FX and a rather small one using GEF Classic and a bunch of pure e4 parts using neither. While porting to E4.39, GEF5.5.1, Java25 and JavaFX25 I ran into troubles with the part using GEF Classic and thought, well that's the point to get rid of GEF Classic (and its E3 dependencies). While porting this part to GEF.FX I discovered the JavaFX25 regression, this issue is all about. For the time being I have a ported and running RCP app and I'm not eager to reintroduce GEF Classic... But, nonetheless I would feel better, if there was a proper perspective for the future (including the possibility to use JavaFX in parts where appropriate).

@azoitl: sorry for the naive question, but what does it effectively mean to 'provide releases'?

Maybe someone of you can answer this: let's assume that GEF5 will no longer be maintained and no newer versions are published, further let's assume I would maintain the required GEF5 artifacts as part of our project. What would be our legal obligations?

[ptziegler]

But it brings in org.eclipse.ui and org.eclipse.ui.workbench.

That is true, but even if not immediately, it might be possible to restructure GEF 3.x in such a way that those dependencies can at least be marked as optional, which is also what Lars suggested. Though you won't be able to use any of the E3 concepts like IEditorPart, IMemento and so on, but that shouldn't matter anyway for a pure E4 application.

sorry for the naive question, but what does it effectively mean to 'provide releases'?

Meant is all of the additional overhead that comes with maintaining a project. Making sure that the builds are working, that the project is compatible with the latest Eclipse release and then of course also building and publishing the artifacts.

let's assume that GEF5 will no longer be maintained and no newer versions are published, further let's assume I would maintain the required GEF5 artifacts as part of our project. What would be our legal obligations?

If you decide to fork the project, it has to remain under the EPL-2. I think the important part is that upon request, the sources of your fork must be made available:

a) the Program must also be made available as Source Code, in
accordance with section 3.2, and the Contributor must accompany
the Program with a statement that the Source Code for the Program
is available under this Agreement, and informs Recipients how to
obtain it in a reasonable manner on or through a medium customarily
used for software exchange;

That's how I understand this. But please don't take anything I say as legal advice :). The rest of your application can remain proprietary, of course. I think a lot of people did something similar for GEF 3.x when the initial move to JavaFX was made.

[Gerhard-2026]

Meant is all of the additional overhead that comes with maintaining a project. Making sure that the builds are working, that the project is compatible with the latest Eclipse release and then of course also building and publishing the artifacts.

OK, but what does this mean in detail? (To be honest: I'm a bit temped, but i must know what I'm getting into) Is there a way to comunicate and discuss this more directly (not through this issue)?

[azoitl]

Meant is all of the additional overhead that comes with maintaining a project. Making sure that the builds are working, that the project is compatible with the latest Eclipse release and then of course also building and publishing the artifacts.

OK, but what does this mean in detail? (To be honest: I'm a bit temped, but i must know what I'm getting into) Is there a way to comunicate and discuss this more directly (not through this issue)?

I can give a rough overview, but details would depend on how GEF 5 is structured (which I don't know). So normally it means you need to understand the build system. It looks like GEF 5 uses maven for that. From that to learn how to build binary images and p2 update site. Then to find out how to deploy these update sites to the right GEF 5 download pages (normally at Eclipse Foundation this is done with Jenkins jobs).

Then you need to know your dependencies and find out when and how to update then.

Half of it you would also need to do when you fork the project.

We can setup a meeting. Feel free to drop me an e-mail. However I can only give you the information that I gathered from Eclipse GEF Classic and other Eclipse projects I'm contributing to.

[merks]

I’ve been keeping this afloat but I don’t think it makes a lot of sense to invest here because the consumer base is too small and no one has actual resource and skills to invest.

[Gerhard-2026]

Thanks for the offer and for the assessment.
Currently, everything we need from GEF 5 seems to work with JavaFX 25 (including the workaround that avoids patching). So, for the time being, we are settled.
Nonetheless, I think I will fork the project and explore it further. If more problems surface, I should be prepared to deal with them. And if the GEF 5 project is resurrected, I can contribute the fixes (if there are any).
If GEF 5 vanishes, we will have to look for a future path, but for now we are not under pressure and can observe how things develop.