bugGNU Octave - Bugs: bug #60054, feature request: package install...


bug #60054: feature request: package install with dependency on java.

Submitted by:  Ernst Reissner <ernstreissner>
Submitted on:  Sun 14 Feb 2021 05:36:41 PM UTC  
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Installation Failure
Status:  Invalid Assigned to:  None
Originator Name:  Reissner Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Mon 01 Mar 2021 02:44:37 PM UTC, comment #8: 

AH! That s the argument!
Java is not packaged with octave
THus versions may be different depending on config.
So if loading twice i could load with different versions.

Ernst Reissner <ernstreissner>
Mon 01 Mar 2021 01:25:36 PM UTC, comment #7: 

I agree with you that the package manager should probably manage dependencies between different packages. But Java is no package. It is a different software.
Other packages depend on some libraries. These library dependencies aren't managed in the package file either. Some packages use configure scripts to detect these libraries.

Like Philip already wrote, Java is not bundled with Octave (like it is with Matlab). It is easy to switch to a different Java version in Octave. If your package depends on some Java version, it makes much more sense to check that at runtime (in the PKG_ADD script) instead of at package installation time.

If you need help in figuring out which code you need to write for your PKG_ADD script, I'm sure there are people that can be helpful (maybe including myself).

Markus Mützel <mmuetzel>
Project Member
Mon 01 Mar 2021 12:48:18 PM UTC, comment #6: 

@Marcus, I dont have a question,
I dont be unable to check version of sth myself.

This is not figured out, it is a feature request.
Java is not just 3rd party software as you write.
Matlab offers a java interface and octave does so as well
because it is a clone.
It is documented in the manual.

The package manager shall manage dependencies where possible.
Thus it is the package manager and not the package
which manages depencencies between packages.
This helps to prevent invalid install and uninstalls
not relying on the work of the package developer.

Similarly, it is possible to specify the version of octave
a package relies on.
It is of high value to provide all that in a single
Description file.
If you have a look at that, you can see that besides the Depends,
also BuildRequirements and SystemRequirements are mentioned,
although not checked.
This is to give an overview of the requires and provides.

For java it is by no means different:
javachk('jvm') checks whether available.
version('-version') is not the right way to determine
what we would call the java version.
From java 9 on it is given by Runtime.version().
It is has the form x.y.z,
although, trailing 0's are frequently not displayed.
Please have a look at the api docs.

This is the version to be compared.
Not System.getProperty('java.runtime.version') or sth else.

The comments show, it needs knowledge to check version.
Please dont tell me the package provider shall do that work.

I am sorry that i did not file a feature request.
Your comment #2 is the point where we shall go on talking about.

I admit it is confusing, but in java trailing 0's
are not shown in versions.
From java 9 on the version is at least 3 numbers.
And those we shall take into account.

Ernst Reissner <ernstreissner>
Mon 01 Mar 2021 08:12:52 AM UTC, comment #5: 

Like you wrote in other reports, you seem to have figured this out.

It would have been better if that would have been discussed in one of the channels that are dedicated to help requests. That way, another user who might have a similar issue in the future would have been able to profit from the information.

Closing as invalid.

Markus Mützel <mmuetzel>
Project Member
Mon 15 Feb 2021 05:49:59 PM UTC, comment #4: 

I think, I have a concept based on octave functions:
version(feature) and compare_versions.
The problem is, that these functions are not at all as required.

Roughly speaking, one could use these two functions
for dependency management.

version() yields octave version,
version('-java') yields java version,
and there are other features, which are also desirable to specify.

One could say that dependencies are allowed for 'octave',
sth starting with '-' like -java or -blas or sth else.

Then one could use compare_versions to check validity.

The problem is, that compare_versions is strange,
10 < 8 but 10 > 08, what a mess!

Also version('-java') gives a lot of stuff,
which has nothing to do with the version.
Likewise for blas and others.

So formally, version and compare_versions dont play together.
In reality, they do better as one could expect.

Ernst Reissner <ernstreissner>
Mon 15 Feb 2021 02:18:42 PM UTC, comment #3: 

A note about PKG_ADD/PKG_DEL:

Rather than incorporate a lot of code in PKG_ADD / PKG_DEL files, it's better to make PKG_ADD / PKG_DEL call dedicated initialization functions or scripts.
In addition, watch out for polluting the workspace by silently introducing variables used for initialization w/o clearing them afterwards.

Other than that I think both of you have valid points.

Entering required Java versions in DESCRIPTION won't work as TTBOMK  Octave has no function to request version info from JAVA. The io package has a very rudimentary function (./private/__chk_java_sprt__.m) with the following code:

    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");

(I don't claim it's Good but it Just works)

My advice would be to create e.g., __init_<pkg-name>__.m and __exit_<pkg-name>__.m scripts or functions, call them from PKG_ADD and PKG_DEL, resp., and use those to init and de-init the required Java stuff.
These days Octave can select a specific Java version from multiple Java installations installed side-by-side by setting JAVA_HOME with setenv(), so there you have additional flexibility.

Philip Nienhuis <philipnienhuis>
Project Member
Mon 15 Feb 2021 01:05:42 PM UTC, comment #2: 

I can understand your concerns on third party software.
In report 60058 I suggest a function versionjava(), or versionJVM().

It is possible to check version of java in PKG_ADD
and to issue error if not fits.

v = javaMethod("version", "java.lang.Runtime");
printf("Found JVM version %d.%d.%d-%d.\n",
              v.feature(), v.interim(), v.update(), v.patch());
vMin = javaMethod("parse", "java.lang.Runtime$Version", "${versionJavaMin}");
vMax = javaMethod("parse", "java.lang.Runtime$Version", "${versionJavaMax}");
if (v.compareTo(vMax) > 0 || v.compareTo(vMin) < 0)
   error("JVM version is not in range [${versionJavaMin}, ${versionJavaMax}]");

On the other hand, I think, dependencies are better in the description.

I think there is a small number third party software
octave really depends on.
There are a lot of functions in octave depending on java,
see the manual. javaclasspath, javaObject, javaArray, javaMethod... isJava maybe also.
And there is even a data type for java object.
So thus octave really relies on java.

I would also say, the math libs octave directly depends on shall be among the dependencies which shall be possible to add on the dependency line.

Ernst Reissner <ernstreissner>
Mon 15 Feb 2021 08:28:29 AM UTC, comment #1: 

The pkg functions are already quite complex without having dependencies on third party software. I'm not convinced yet if it is a good idea to add those dependencies.

Would adding an appropriate check to the PKGADD script instead also work for you?

Markus Mützel <mmuetzel>
Project Member
Sun 14 Feb 2021 05:36:41 PM UTC, original submission:  

There was a time, where java integration was in fact a package.
Still, java runtime is needed by some packages.
It would be nice if one could add a dependency
not only on other packages or on octave but also on java runtime.

In the manual Section 37.4.1 description file of packages is described and also the dependency.

I would find it useful to be able to write something like

Depends: java (>= 9)

Ernst Reissner <ernstreissner>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by ernstreissner (Submitted the item)
  • -email is unavailable- added by ernstreissner

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-03-01 mmuetzel StatusNone => Invalid
        Open/ClosedOpen => Closed
    2021-02-14 ernstreissner Carbon-Copy- => Added rei3ner@arcor.de

    Back to the top

    Powered by Savane 3.5