vdmj
vdmj copied to clipboard
nickbattle
ClassMapper terminates JVM on error
The classmapper contains both System prints and System.exit call which makes it hard to embed into other software. Before this class only raised error messages while it currently both prints error information and terminates the JVM if something goes wrong. Any change that the old behaviour could be restored. I have problems with this when used in https://github.com/INTO-CPS-Association/FMI-VDM-Model
The System.exit and System.err output has been there from the very beginning (2016). It seemed reasonable to abort because it means the classpath provided has something fundamentally broken on it and the mapping cannot complete.
We added this property to allow classes to be loaded from multiple locations... but that's still there?
What is going wrong?
# An alternative search path for the ClassMapper (default null)
# vdmj.mapping.search_path = null
PS. I'd lost the "watch" on the VDMJ repo, which is why I missed this originally :-(
First system exit is not good in any case as it will terminate the JVM. I have other code running that loads VDMJ, so just because someting is not found in the classpath doesnt mean that my program should exit too.
My issue with vdmj.mapping.search_path was that it worked before but then you added a check for already loaded and then I could not directly use it anymore as I was using it to override one of the mappings. Also here you also do system exit as I recall.
There was no way to allow me to still use VDMJ with the System.exit int he class mapper. And also no way to allow me to continue to use the override of the mapping. So had to do this https://github.com/INTO-CPS-Association/FMI-VDM-Model/blob/development/fmi2/vdmcheck/src/main/java/com/fujitsu/vdmj/mapper/ClassMapper.java which I do not like. Could we do someting such that the class mapper doesnt call System.exit and also allow me to override a mapping intentionally.
Okay, I suppose I can change the System.exit to a ClassMapperException (runtime exception). That will have more or less the same result in most cases, I expect.
I can't easily compare the link above with the latest in 4.5.0, but I can see how you're throwing an exception and the logic for processMap doesn't include the "existing" check. I can see how overriding a mapping could be useful (what are you doing here?). It's easy enough to remove those safety checks, they're there for a reason - presumably this caught someone out (probably Leo) and it took a while to debug. I'd like to at least replace it with a warning to stderr.
If I make these changes in the latest 4.5.0 snapshot (development branch to start with) can you try it?
Yes this seems to work. Can you make another constructor where the (error) stream you write to can be set from the outside having the default being what you use now. I just want to silence it for these errors as they are intended
Mmm, constructors are a bit awkward because of the getInstance(). How about a setErrStream method that you can call at any point (defaulting to System.err, of course)?
Pushed this to development... haven't tried it :-)
/**
* Set the instance error stream to be something other than System.err.
*/
public ClassMapper setErrStream(PrintStream err)
{
errorStream = err;
return this; // Convenient for getInstance().setErrStream(...).convert(obj)
}
ok yes that sounds sensible. Forgot about the getInstance so the method above is fine
hmm how to do I call setErrStream without calling getInstance. Its getInstance which writes to the stream?
Ah :( Sounds like we need an overloaded getInstance in that case. Sorry. Will fix, but in meeting at the moment...
Okay, I've added a PrintStream argument to getInstance (and the constructor within that). But the default getInstance() will use System.err as before. Does this do what you need (I've not tested)?
ok it works. Whenever you make a new release let me know then I will try out the new release process I'm setting up for https://github.com/INTO-CPS-Association/FMI-VDM-Model
Okay, I've deployed a new 4.5.0-SNAPSHOT to both Maven Central and to the GitHub repository.
I'll let you know when I deploy new snapshots or make a release - we're long overdue the 4.5.0 release, but we need the VSCode client to catch up with various things before I can do that really. I push development changes to GitHub all the time though, while working on "QuickCheck".
ok it builds now with the snapshot. Not sure about the structure but you could probably point the VSCode client to the compatible version for it and then release is all. Then make a new release once the VSCode client catches up. Anyway let me know when you make a release. If you want I can also assist with setting actions up to deploy the snapshots automatically and make an other job for the release if you want
I've just pushed another snapshot of VDMJ to Maven Central to get over a build problem with the FMI-VDM-Model. I've created a new @DocLink annotation which I'm using in the (new) rule-model for FMI2 (and I'll update the FMI3 version if this works). But to do this, I had to tweak the @OnFail annotation to use the DocLinks.
The idea is that the model includes "rules" which can be used to produce an appendix to the FMI Standard, with hyperlinks into the main document for the place(s) where the rule is explained. So the natural route for MaestroCheck is to pass back these hyperlinks in the OnFailError, as well as an error code and the basic message. Then, in principle, when there's a problem users can click something and zoom over to the right place in https://fmi-standard.org/docs/3.0.1/ (or wherever).
Just pushed another small tweak. OnFailError now contains a list of doclinks, and the text of the links can be retrieved with getDocLinks. They're just strings, but one would expect them to be URLs or perhaps raw HTML anchor locations etc. The FMI model's doclinks are currently like "<FMI3_STANDARD>#header-files-and-naming-of-functions". The idea is that the placeholder can be substituted for a "base" URL for the Standard, which could therefore be a local HTML document.
Do I need to change anything in FMI-VDM-Model for this? I would like to make a release of FMI-VDM-Model such that I can freeze that in maestro (and release maestro) but to do that I need a release of VDMJ as well. Can we schedule that? its been some time now and really want to stabalize the maestro build
Yeah, there's a lot of interlinked things going on here. I've tried to keep the old MaestroCheck in place and working, but I need to write a new version of MaestroCheck to use the @DocLinks - ie. that uses rule-model rather than static-model. I would like to get all of this released too, and yes a 4.5.0 release of VDMJ is long overdue.
But with VDMJ we were also hoping to include QuickCheck in the next VSCode release, which requires some UI updates. But the guy PGL found to do this has dropped out. I wanted to wait before a VDMJ release, in case the new UI for QuickCheck needs LSP extensions or whatever.
There's never a good time. Let me talk to PGL and I'll get back to you - what's the best email for you now?