var TimeSeries series = new TimeSeries(TimeSeries.Policy.REPLACE)
is executed, it results in
2026-05-21 18:42:13.709 [ERROR] [mation.module.script.internal.handler.AbstractScriptModuleHandler] - Script execution of rule with UID 'netz-2' failed: An error occurred during the script execution: Cannot invoke "org.eclipse.xtext.common.types.JvmType.eIsProxy()" because "type" is null in netz
For me the below rule works with import in both 5.1.4 and 5.2.0 build 5381 (latest currently). It does not work with 5.1 or 5.2 when import is skipped:
import org.openhab.core.types.TimeSeries
rule a
when
System reached start level 100
then
logError("S", new TimeSeries(TimeSeries.Policy.REPLACE).toString)
end
I think the āsolvingā of this issue was a bit quick. Doesnāt anybody wonder why the behavior has changed? As far as I know, no implicit imports have been removed, so is there really something else that is going on? Some regression caused by all the other changes?
After some āinvestigationā this seems likely to have been caused by the upgrade of Xtext itself. Apparently, they have made the class loading much more strict to avoid āleaksā, where classes that could be resolved āvia other classesā would previously be resolvable. This is no more, so anything that isnāt either implicitly or explicitly imported will be rejected.
This means that 5.2.0 has the potential for a little āavalancheā of classes that used to be resolvable, but isnāt anymore. There should probably be a notice somewhere that this can happen, and what the remedy is. In addition, I will add org.openhab.core.types to implicit imports in an existing PR, which should take care of the following classes, including TimeSeries:
When I tried the above snippet, it behaved for me in identical way in openHAB 5.1.4 and 5.2 latest snapshot. So for that particular example, which I posted above, I see no difference in behaviour of implicit imports between openHAB 5.1.4 and openHAB 5.2.
If there is a difference of implicit imports between 5.1 and 5.2., it would be easier to track down its cause, if it is clarified, if the difference is only in DSL Scripts, or also in DSL Rules. As DSL Scripts cannot have import section, the above means, if a code snippet was working as a DSL Script before (without import) and now the DSL Script needs full-qualified names.
Are you saying that you donāt believe that what @mstormi reports is accurate? I didnāt really consider that an alternative, and rather tries to find an explanation for why it could be.
This depends entirely on whether or not you use one of those classes that have been āmagically resolvedā in the past by the removed āclass hierarchy walkingā. If you havenāt used any of them, you wonāt notice a difference - what worries me here, is that we have no way to know what classes that is - and how widespread their use is.
The difference is in Xtext itself and how classes are resolved. In previous versions there was some kind of āhierarchy walkā mechanism that resolved classes that were indirectly referenced, or perhaps that were parents to imported classes. Iām not sure of the details, you must dive into the changes done to Xtext to know the exact details.
They were worried about āclass leaksā, whatever that is, and removed this behavior so that only what is specifically imported (implicitly or explicitly) are resolvable. As a result, itās very hard to know what the impact will be when 5.2.0 is released.
The question is if that means that thereās not a problem. How many actually upgrade to milestones? How many of those use DSL? How many of those again happen to rely on some of these āmagical importsā that were effective because of some classpath traversal algorithm?
In my view, the remedy is to add the āmost likelyā impacted classes, like org.openhab.core.types and others that is likely to be widely used without explicit import, and then include a notice in the release notes that this might happen and that the remedy is explicit import or using the full class path.
Also, the reported āchange in resolutionā is very vague, and I havenāt been able to figure out what the details are. This makes it very hard to assess the potential impact. Weāre also currently running a milestone of Xtext - so this might also be caused by a bug somewhere.
It is very hard to get down to āfactsā here, Iāve tried to query Googleās āAIā to find what has actually changed. It seems that the change isnāt in Xtext itself, but is a consequence of Xtext updating its dependencies to more recent versions of the āEclipse Platformā.
Iāll paste some of what the āAIā reports, then everybody can make up their own mind if this is ārealā or not:
The behavior change is entirely a side effect of Eclipse Platform / OSGi Classloading visibility isolation and dependency convergence introduced during the openHAB 5.2.0 cycle upgrade to Xtext 2.43.
The Core Culprit: ClasspathTypeProvider vs OSGi
The Cannot invoke "JvmType.eIsProxy()" because "type" is null error isnāt a new bug in Xtext. It is a generic, long-standing fallback failure in Xtextās standard linking validation engine. Whenever Xtext completely fails to locate a type in its scope provider, it returns a null JvmType. The validation interceptor immediately calls .eIsProxy() on that object without a null-check, resulting in this exact error stack trace.
The root issue is that Xtextās ClasspathTypeProvider (or openHABās custom extension of it) can no longer find org.openhab.core.types.TimeSeries.
Why it broke in 5.2.0 (but worked in 5.1.4)
When openHAB bumped its target platform to the newer Eclipse version required by Xtext 2.43 (which enforces a strict Java 17 / Eclipse 2024-03+ baseline), the way OSGi bundles expose hidden or transitive class paths changed.
In 5.1.4: Due to older OSGi wiring configurations or looser bundle isolation paths in the old Eclipse runtime dependencies, the bundle wrapping the Xtext parsing engine happened to have org.openhab.core.types leaked into its unmapped class loader classpath natively. Xtext could see it globally even without an explicit directive.
In 5.2.0: The platform upgrade enforced stricter bundle bounds. TimeSeries is contained in org.openhab.core.types, which is decoupled from the immediate runtime scope of the Rules DSL interpreter engine unless explicitly exposed or implicitly declared. Because it can no longer see the package via unmapped classloading, it returns null.
