[Octave-bug-tracker] [bug #60058] Feature request: function javaversion()

[Philip Nienhuis]

Follow-up Comment #17, bug #60058 (project octave):

Matlab's "version" returns the version of the *bundled* Java JRE; in Octave
one must select an external one from perhaps several Java releases installed
side-by-side, easily done by setting JAVA_HOME. So it works differently to
start with.

That said, I wonder why in version.m all those Java properties are requested
and wrapped into a convoluted string that needs quite some back-untangling
before it can be used for automating Java version analysis.

In the io package there's private function __chk_java_sprt__.m  that invokes a
different Java method, that until now AFAICS has worked with all Java releases
and -vendors on at least Windows and Linux:

  :
    jver = ...
      char (javaMethod ("getProperty", "java.lang.System", "java.version"));
    cjver = strsplit (jver, ".");
    ## Before Java 9 the numbering scheme is "1.ver.x_y".
    ## For Java 9 it is "ver.x.y".
    ## For Java 10 and 11 it is just "ver".
    java_ver = [];
    if (numel (cjver) > 1 && (sscanf (cjver{1}, "%d") == 1))
      java_ver = sscanf (cjver{2}, "%d");
    elseif (! isempty (cjver))
      java_ver = sscanf (cjver{1}, "%d");
    endif
  :


(I just saw that it works with Java 15 as well BTW).
I suppose this code could be morphed into s/th returning an 'x.y.z' version
number and then be included in javamem.m to return a second output arg
returning that version number.
javamem.m has no Matlab counterpart so it's easy to amend.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60058>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/