[CRITICAL] FXML Validator: False-Positive 'Not assignable' error due to ClassLoader/OSGi Shadowing
Environment
- Eclipse: 2026-xx (Standard IDE)
- Plugin: e(fx)clipse
- JDK: Zulu JDK 26 (with Integrated OpenJFX)
- Project Structure: Non-modular (Classpath-based)
Description
The e(fx)clipse FXML validator flags a false-positive compilation error on standard @FXML controller methods using javafx.event.ActionEvent parameters. The error states:
Parameter 'event' is not assignable to javafx.event.Event
This occurs despite the project building successfully via javac/Maven and all imports being correctly resolved to the OpenJFX API provided by the Zulu JDK 26.
Root Cause Analysis
The validator runs within an isolated OSGi context that does not reflect the project's actual build path. This leads to Type Shadowing:
- Compiler: Correctly resolves
javafx.event.ActionEvent from the project's Zulu JDK / OpenJFX modules.
- Validator: Compares the event parameter against an internal, isolated representation of the JavaFX API (likely bundled within the e(fx)clipse plugin), causing a failed compatibility check.
Architectural Critique: Validator Overreach
The validation logic is functionally overreaching. It attempts a Deep Type Inference that the plugin environment is not equipped to handle reliably. A validator should perform a basic signature check (validating method existence and @FXML annotation) rather than a deep, inference-based check that conflicts with the project's ClassLoader.
The validator is effectively attempting to "know better" than the project's own Build Path, which is a structural flaw.
Expected Behavior & Required Action
The validator should defer to the project's configured Build Path/JRE System Library. At minimum, a configuration toggle is required to disable this deep type-inference validation, allowing the user to trust the project's own compilation results.
Note on Future Compatibility
This issue is a critical blocker for modern JavaFX development (JDK 26+). Without a fix or a way to suppress this overreaching inference, the e(fx)clipse plugin becomes incompatible with the current standard of the JavaFX ecosystem. We require a swift resolution or a way to bypass this internal validation to ensure continued compatibility with modern JDK environments.
[CRITICAL] FXML Validator: False-Positive 'Not assignable' error due to ClassLoader/OSGi Shadowing
Environment
Description
The e(fx)clipse FXML validator flags a false-positive compilation error on standard
@FXMLcontroller methods usingjavafx.event.ActionEventparameters. The error states:This occurs despite the project building successfully via
javac/Maven and all imports being correctly resolved to the OpenJFX API provided by the Zulu JDK 26.Root Cause Analysis
The validator runs within an isolated OSGi context that does not reflect the project's actual build path. This leads to Type Shadowing:
javafx.event.ActionEventfrom the project's Zulu JDK / OpenJFX modules.Architectural Critique: Validator Overreach
The validation logic is functionally overreaching. It attempts a Deep Type Inference that the plugin environment is not equipped to handle reliably. A validator should perform a basic signature check (validating method existence and
@FXMLannotation) rather than a deep, inference-based check that conflicts with the project's ClassLoader.The validator is effectively attempting to "know better" than the project's own Build Path, which is a structural flaw.
Expected Behavior & Required Action
The validator should defer to the project's configured Build Path/JRE System Library. At minimum, a configuration toggle is required to disable this deep type-inference validation, allowing the user to trust the project's own compilation results.
Note on Future Compatibility
This issue is a critical blocker for modern JavaFX development (JDK 26+). Without a fix or a way to suppress this overreaching inference, the e(fx)clipse plugin becomes incompatible with the current standard of the JavaFX ecosystem. We require a swift resolution or a way to bypass this internal validation to ensure continued compatibility with modern JDK environments.