Just in case you come across this error message in your log file:
ScriptEngine for language 'application/javascript' could not be found for identifier:
then you probably updated your Java engine to version 17 and still have JSR223 scripts.
In this case either convert your scripts to ECMAScript-2021 or revert back to Java version 11.
Note there are at least two issues I know of with running OH on Java 17 beyond this. So it is not recommended. Stick with JDK 11 and don’t try to upgrade until Java moves to support a later LTS version of Java.
Note that ECMAScript 5.1 will no longer be supported at that point so it makes sense to slowly start the conversion to ECMAScript 2021 now so you are not under the gun when the time comes.
I have started testing Java 17 but did not come across any problems yet.
What are the two issues you know of? I checked the forum but could not find any post.
Given that Java 11 is the one and only version of Java that openHAB officially supports, you wouldn’t find anything on the forum short of “don’t do that, use Java 11” when it doesn’t work.
You need to look on Github where the developers are working to find and fix any problems before the move. If you want to contribute to this effort, that’s where you need to start also since and changes required will involve changes to code, build scripts, versions of libraries, etc.
There’s now also a Marketplace add-on which you can use to get the old Nashorn engine back on Java 17. 
I didn’t think that was possible. Very nice! Thanks!
Today I updated from 3.4.4 to 4.0.2.
I got this error with all my rules where a blockly script is included:
2023-08-18 23:56:54.277 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language 'application/javascript' could not be found for identifier: b9dc05fb-01e0-4d37-ac42-91a1b3f70ffb
How can I fix this?
Thanks, fixed it!
I am now in the process of upgrading my scripts/rules/transformations… And now I have a little issue… I thought I found all old ECMA scripts and removed the NashornJS scriptingplugin from OH4 as I thought it is not longer needed… But obviously I missed one script and get following message:
ScriptEngine for language 'application/javascript;version=ECMAScript-5.1' could not be found for identifier: 065e3126-e2ec-4110-b94f-f97b9b4a12dd
Somehow the identifyer should help me to find where or what it is, but how?
(and yes I am aware, that reinstalling NashornJS Scripting would solve the error, I am also aware, that I hve to search my system, what it obviously doesn’t do anymore, but there must be a more elegant way utilizing the identifier)
Most probably it is a rule/script/transformation that I already checked for correct and just didn’t tell the system that it is an ECMA 262 compliant script now. I had such residuals with transformations, where I just didn’t open and did click the right version of the transformation type… Or did it and didn’t save the work… From that experience I know, that if it was a 5.1 script and the NAshornJS disapears, the system does not automatically set the flag that this is a ECMA 262 edition 11 transform, it just says no transform in the Web interface, but still tries to execute the modified script with the non existent 5.1 engine.
That’s why I strongly recommend that all rules define their UID instead of depending on the random ones that are generated when you don’t define the UID.
If you think this is a rule (the most likely culpret) navigate to Settings → Rules and search for that UID. If you don’t find it there, repeat in Settings → Scripts. Alternatively, open the developer sidebar (alt-shift-d) and search for the UID there. Alternatively you can search through `$OH_USERDATA/jsondb/automation_rules.json. Alternatively you can use the REST API Docs (under developer tools) to bring up that rule from the rules endpoint.
It’s not likely to be a transformation as transformations don’t have UIDs that look like that (if created through the UI the ID is much shorter, if created in a file the filename is the UID).
Thank you I will try again, cause searching by id in Dev Sidebar didn’t bring up anything…
About that thing, it’s most probably not a transformation, because of shorter UID , that’s my problem, I don’t even have an Idea who sets UIDs like that…
And a question, how to set that number with a e.g. rule script? Cause I am pretty sure I nowhere have a UID in a format like that in the error message:
so i tried again to search for that number… result: neither in scripts nor transformations nor rules it does find something… So I will try searching for that in the jsonDB later, as I finally don’t have an idea what it could be
–update: Now it gets really strange, greping over the JSON DB, there is nothing that looks like
065e3126-e2ec-4110-b94f-f97b9b4a12dd even not parts of it…
when i grep for ECMA i find in the backups some entries in automation.json, but not in the actual DB, which makes sense, as I am of the opinion I ported everything…
As a last resort, I may have something calling NashornJS explicitely, cause there is something that blockly does or did do that for some time operations.
Finally… I found the bad guy, by grepping the automation_rules.json for Nashorn…
there is nowhere a reference that gives back that identifier from the error message…
What happened here, at somepoint when started porting to OH4 and GrallJS the blockly behaved a bit strange on functions dealing with time, by explicitely declaring it wants NashornJS for that, even it should have set graalJS … After it was fixed, i thought I did redo it to get it right, yes I did it on one of the two scripts that run there, but on one not :-)… So solution was, open it and safe it again, in order to get the automatic entries fixed…
Thank u for your hint… And hope it can help others if they run in something like that… The question is now, where to propose a change and which kind of change, that this error message returns an identifier, that helps u in finding the script that wants to call an non existent Engine?
When you create the rule:
When you create a transformation through the UI:
In .rules files the UID becomes the name of the file with -N appended where N is the rule’s position inside the file (e.g. the third rule in a file named lights.rules would be lights-3).
For the other rules languages, there is usually an option to set the ID when creating the rule. If you do not you get a randomly generated UID.
As then screen shots indicate, you cannot change it once the rule is created. Therefore once the rule is created there’s no option to change it. But the Rule’s UID is shown on the Rules page and it can be searched.
Do you have an automation_rules.json file in the userdata/jsondb folder or only a backup of that file under userdata/jsondb/backups.
Unfortunately (I filed an issue on this some time ago) if the file doesn’t exist, OH just goes ahead and starts using the most recent backup.
Indeed, and that is odd for sure.
I don’t know that there is a change that can be made. OH is going to report the UID as it knows it. If you’ve found entry in the backups I’d have to conclude that it’s picking up the rule from that backup somehow.
The uuid also was not stated anywhere in the backups… As well as i nowhere see a uuid like that, and definitely as much as possible, don’t use automatic uuids, i always change them to something readable, unless i am very sleepy… But grepping for “Nashorn” over all the json DB files brought up, that in the screened ruleMeltingUnit… the bad boy was… The script evaluating to true checks for a timeframe and i ported it before i had the fix installed, that makes blockly set the right engine identifier for some time functions… So i thought this rule is already ported, but it wasn’t…
Opening it, disable the time block, enabeling it again and save the sh.t fixed the issue… But it still stays, the errormessage states an identifier that doesn’t make any sense / isn’t to find at any of the spots one may would look at…
And yes of course the grep did find it in the automation_rules.json… I don’t care that exactly about names of files… It’s linux… U just grep all…
Found the UUID? Well, open that file and look at the entry. That’s the rule this error is coming from.
Or are you talking about the Nashorn?
It was not findable by the UUID. This UUID is NOWHERE!! in the json.db… But one can find it, if one does a grep for “Nashorn” and a grep for “ECMA” over the complete .json DB… Then you get all rules, transcripts and whatever, that still relay on Nashorn instead of Graal.
so one may enter in $OPENHAB_USERDATA/jsondb folder:
grep -rni "Nashorn" *.json
grep -rni "ECMA" *.json
To find all the rules etc, that still use Nashorn Engine. This UUID statet in the error Message from Engine not found, doesn’t give you anything that u could find in the jsonDB, if your rules are named properly… Somehow this seems to be a created ID for Scripts, that are part of a rule, whose “clear name” becomes, the UUID you did set + the -N which identifyes the spor inside the rule as you mentioned before