Why next gen rules are experimental?


I am moving to write my rules with JSR223, it has advantages over DSL (at least from my point of view). My concern is that it depends on the next gen rules, and the documentation says:

this is available within openHAB 2 only as an experimental feature.

Is the next gen rules are here to stay? Is there a chance that they it will be deprecated and the JSR223 will not be supported?

Yes. They will replace the Rules DSL as the default Rules Engine. The plan is to write a module that will allow Rules DSL Rules to execute on the NGRE.

No. As of right now they are the future.

It is important to make a distinction. Rules DSL, as it exists right now is completely separate.

Then there is JSR223 and the NGRE. Both use the same execution engine. But when referring to JSR223 we are usually referring to Rules written in Jython, Javascript, or Groovy in text files. When referring to NGRE often we are referring to PaperUI created Rules which get stored as JSON in the JSONDB (right next to Things and Items). These Rules support a significantly different structure and approach to Rules writing (see Experimental Next-Gen Rules Engine Documentation 1 of : Introduction).

They are Experimental because the NGRE are not well documented yet nor are they complete (missing some important Rule triggers). JSR223, which run on the same execution engine, are more mature though the documentation is hit and miss depending on which language you choose. But since they use the same execution engine to execute, I see no reason why JSR223 won’t be supported for the foreseeable future.

That being said, anything can change at any point. New technologies are invented all the time, major problems encountered that are insurmountable, technologies are dropped, etc. For example, if Java 15 (or some version) decides to drop support for JSR223, we will probably have to find an alternative.

1 Like

No I am more worry … :slight_smile:

There are no guarantees in technology and nothing lasts forever.

1 Like

You don’t have to wait until version 15 :frowning_face:


JEP 335: Deprecate the Nashorn JavaScript Engine in JDK 11


It also says This deprecation does not affect, in any way, thejavax.scriptAPI.

Does it mean that JSR223 will still be supported?

I believe it affects the JavaScript part only. So with JavaScript you might or might not be in trouble in the future (although that still might be far away and possible something else will come up) and not JSR223 itself. So for example it doesn’t affect Jython.

The javax.script API has been become an integral part of the Java 9 platform and onward. In that sense, there is effectively no longer a JSR 223 as of Java 9.

That’s unfortunate. Or what I should say is it was unfortunate that the NGRE devs chose Nashorn JS as the default scripting language for PaperUI developed NGRE Rules.


Nashorn, NGRE, Jython, JSR223 … :slight_smile:

I am not that familiar with the internal engine of OpenHAB / SmartHome eclipse so now I am confused. I am using the jython jar and write py scripts using this package.

I am not sure from the answers above if it will be supported in the future or it is something that is going to be deprecated very soon .

Jython should be fine. I believe it uses the script API.

Nashorn JavaScript appears to become deprecated soon so it’s future is in doubt.

The NGRE is a way to write Rules using PaperUI. Currently it only supports Nashorn JavaScript. See Experimental Next-Gen Rules Engine Documentation 1 of : Introduction. By all appearances other languages will be supported at some point but at this time there will be a good deal of new work necessary to NGRE (and the docs I’m working on, grumble grumble).

In all likelihood someone else (not Oracle) will pick up implementing some sort of JavaScript alternative that works with the Java Script API. But whether that is in time to give OH continuity is not known.

Nashorn JavaScript appears to become deprecated soon so it’s future is in doubt.

@rlkoshak, yes, Nashorn will go to be deprecated in java 9.

Nashorn is integrated into java over JSR223. But Nashorn is a no longer up to date! So it is better to exclude it from Java.

But much more modern alternatives are of course on the horizon (works over JSR223 too):

It’s all good with your documentation !!!

EDIT: If we know at what time the development of openHAB on Java 9 is changed. Only then does it make sense to deal with Oracle GraalVM and to follow a migration path. But I see no special problems, rather the opposite.


My understanding is they are working to jump straight to Java 11 and that is currently in work and should be available by OH 2.5 release. One of the big hurdles has already been done, moving to a newer version of Karaf. Last I heard there were only a few problems in the core and other bindings to be resolved. Some have successfully run OH on Java 11 already.

Oh, then lets go to test GraalVM next Time. :slight_smile:

1 Like