It’s telling you to install Java 17. 
I discovered that issue some time ago, @J-N-K explained it here and is also working on a solution: in core Refactor WatchService by J-N-K · Pull Request #3004 · openhab/openhab-core · GitHub and for the addons Adapt addons to core watch service changes by J-N-K · Pull Request #14004 · openhab/openhab-addons · GitHub.
@ccutrer I haven‘t had a closer look at the addon PR yet, but it seems like a fix for JRubyScripting is also part of it.
@rlkoshak
I‘ve already migrated my JS transformations to SCRIPT, but currently inline scripts and a transformation profile for Items are missing. I can try to ping you when there are PRs for those, but I cannot promise to not forget
I know what you mean, like JS transform is providing it at the moment.
This is not supported yet, but @J-N-K said that it is not too difficult to add that.
1 Like
@JimT @florian-h05 I created an issue for the inline scripting. It’s not top priority, but I hope to be able to provide a PR latest around new year.
6 Likes
I upgraded to OH 4 #3245 right now and have no problem with zwave.
2 Likes
Note that if you use JDBC MySQL persistence, it’s currently broken (as of 21 Dec). Will be fixed shortly as soon as the mysql connector artifact is uploaded to jfrog.
Just spun up #3245 and Zwave is all good now.
Thanks!
However, I’m still seeing the “ScriptEngine for language ‘application/javascript’ could not be found…”.
After the first clean boot I installed the Nashorn add-on from the marketplace. Despite the errors during boot, the rules appear to work. There might be a race condition where rules are loaded before the add-on is loaded perhaps?
1 Like
I’m currently working on improving the script file watcher to solve the Nashorn missing issue.
3 Likes
Is there a roadmap for 4.0 anywhere?
Great work btw, I jumped into OpenHAB at v3 and it’s been super stable and seems to be having a lot of work done towards making things easier for the end user.
This is about as close as we get to a roadmap.
1 Like
FYI, @florian-h05 and I are already working on migrating blockly to jsscripting (based on graalsvm):
see Migrate Blockly to JS Scripting (GraalJS) · Issue #1597 · openhab/openhab-webui · GitHub
The current state is already pretty far and blockly already supports Nashorn and graalsvm at the same time and will even gracefully provide some new blocks on jsscripting only that can’t be easily done on Nashorn.
See the discussion on how we intend to provide the migration path because it does not only affect blockly but also all handwritten rules. We are also currently discussing how we want to address the migration.
1 Like
No, there is none
But feel free to open a new topic with your feature request.
The closest would be an issue in the appropriate repo on GitHub.
Just to add a little update on the application/javascript could not be found, if you have a Nashorn script triggered with a system start level trigger, it won’t trigger during startup and you’ll have to run it manually. I’m sure Nashorn isn’t becoming available until too late in the run levels to trigger the rule.
Of course I’m going to be converting my rules and rule templates to be JS Scripting based, but I’m leaving them for now to proved a better test environment and help out where I can.
The problem with the start level triggers is not exactly the same, but related.
The start level problem with all automation addons is because they start at level 80, and for file based scripts it can happen that they are loaded even after start level 100 has been reached.
See JSR223 scripts and start levels · Issue #3199 · openhab/openhab-core · GitHub.
True for file based rules, but these are all UI rules.
What appears to be happening is the rule is loaded prior to Nashorn being available so the rule is disabled. A little later on in the startup process Nashorn becomes available and the rule is enabled but the start level the rule should have been triggered by has already passed (in this case it’s start level 20) so it doesn’t trigger.
Since they are not file based I think that issue doesn’t apply in this case.
It’s not a really big deal for now and it’s clearly going to be fixed. I just wanted to make it clear that my specific problem is in the UI for other early adopters. 
1 Like
This is now fixed.
1 Like
Hi,
Well, found this post after wondering why my OpenHAB went t!ts up.
I managed to upgrade my OpenJDK from 11 to 17 and partially fixed it.
I’m now hitting the issue that the JS transform is gone and to use “SCRIPT”
Sorry, but what???
The only documentation I’ve found is this “Transformations | openHAB” which doesn’t even make sense.
What do I need to actually do to get this working again?
This is one of the errors I’m now getting:
2022-12-23 20:13:54.414 [WARN ] [t.generic.ChannelStateTransformation] - Executing the JSONPATH-transformation failed: Invalid path '$.DS18B20-2.Temperature' in '{"Time":"1970-03-03T22:54:15+00:00","Switch1":"OFF","Switch2":"OFF","Switch3":"OFF","DS18B20-1":{"Id":"3C01B556F54F","Temperature":0.3},"BME280":{"Temperature":19.4,"Humidity":47.9,"DewPoint":8.0,"Pressure":976.2},"BH1750":{"Illuminance":0},"PressureUnit":"hPa","TempUnit":"C"}'
Is there an add-on/binding or something else that I need to install to get the JS transform to work?
Thanks,
Richie
First of all: OH4 is in a very early stage there will be more breaking changes and since we there are some fundamental changes (Java 17, Karaf 4.4 and some larger refactorings - not all of that is completed yet) snapshots are expected to be unstable. In general it is NEVER recommended to use snapshots in a production environment.
Regarding your issues:
- JS transformation is not any will not be available in OH4 because it depends on Nashorn. The
SCRIPTtransformation should do everything you need regarding transformations. What is your issue there? Please note that the associated profile is not available at the moment. - Your error go is not related to the JS transformation but the JSONPath transformation. This is a different add-on. That aside: The input JSON does not contain an element for the key
DS18B20-2, so the transformation fails. Check if you picked the correct transformation for that channel (DS18B20-1is present). If this doesn’t help, please open a separate thread, this has nothing to do with OH4.
BTW: “Sorry, but what??? … .which doesn’t even make sense” is quite rude.