knorrie
commented
4 years ago As git blame tells you, this code was introduced in 95738dd2abd2d169eb37794c350cb9ebf0148bbf to work around Mendix Runtime bugs in the versions (>=6 && < 6.6) || (>=5.18 && <= 5.21.5). During the Mendix 7 cycle it was not touched, so apparently it also DTRT for that.
The guess_java_version function is a workaround to, like it says, guess the java version because not all of the above mentioned versions have java_version in the about result. Mendix 7 and later always have the field in the response. It was added somewhere during Mendix 6 when discussing about all of this, so that if something similar happens in the future, the chance is bigger that we can "just" look at java_version instead of doing madness like "If Mendix 5, then see if used_nonheap is the exact sum of code and permanent. If so, then Java 7, else Java 8."
That means, first of all, that instead of fixing guess_java_version to work with Mendix 8, the code should never be reached instead, but only when < 7.
The whole memorypools array is just blindly passed from the JVM MemoryPoolMXBean info to the stats answer. Runtime team does not want to interpret it. One of the reasons mentioned for that was "if you choose a different garbage collector, or write your own which has different heap areas, then stuff with a different name and meaning might end up in different fields, and then you can still write your own monitoring for it", effectively leaving all the work to whoever calls the stats function in the admin api. That's us, here.
Now, hooray, we also need a new funny wrapper function to deal with java_version moving the major number as we like to use for if statements from the second to first position.
So, probably the work here is (thinking out loud): 1) Find out what JVM types and versions of it are officially supported to be used with Mendix 7 and 8. 2) Run all possible combinations and gather info about what the output of them looks like, and what it means etc... 3) make a new helper function (get_java_version?) that just returns the single int java version number as we want to see it, and maybe None if there's no java_version in the about info. In here fun stuff like if major == 1 then return minor else return major or sth needs to happen. 4) have guess_java_version call get_java_version instead of the code duplication. add some comment to it which points out that it's only used for Mendix 5 and 6. 5) rewrite all of the mess a bit so that the if/else logic is a bit logical to follow (it's not really, now) 6) the if else branches in get_stats_from_runtime should get a few small comments in the style of: "we can only end up here if X Y Z". I guess this is one of the first things that I should do myself in case anyone else wants to work on the rest of this, to try reduce the pain and reverse engineering efforts.
When making changes, always do it in a way that tries to more and more isolate the specific workaround for older versions, so that whenever support for them can be dropped, it's simply a case of removing part of the code.
As long as the official Mendix Cloud still allows running Mendix apps on all versions from 3.0.0 onwards, we have to keep supporting all of the old stuff in here...
In the about request on the admin port the java version is returned. For java 8: ""1.8.0_144" For java 11: "11.0.3"
The guess_java_version returns the minor version from the response which results in 0 for Mendix 8.