bugGNU Octave - Bugs: bug #58312, [octave forge] (io) Defer Java...

 
 

bug #58312: [octave forge] (io) Defer Java detection until a function is called

Submitted by:  Christian Häggström <saturn>
Submitted on:  Wed 06 May 2020 07:59:34 PM UTC  
 
Category:  Octave Forge Package Severity:  1 - Wish
Priority:  3 - Low Item Group:  Feature Request
Status:  Postponed Assigned to:  None
Originator Name:  Open/Closed:  Open
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)

Fri 08 May 2020 09:52:05 PM UTC, comment #8: 

Thanks Christian.
Intriguing that you see the warning with OpenJDK 1.8 (actually same as mine); in bug #55174 it was stated that the warnings started with OpenJDK 11. Maybe the relevant modifications got backported in your distro?
OpenJDK on Mageia 7 is at 1.8 as well so that must be the reason I didn't see the warning.

@Mike
I thought of that, but I doubt it's that easy. The init routine tries to do all checks and initialization for the XML routines and all spreadsheet "interfaces" at once, not just for the Java-based ones, because there is common stuff. When moving it elsewhere splitting it up is unavoidable. The XML routines currently get a "free ride" as regards initialization but would need separate routines then.
Then about the exit routine. Similar holds for that, although probably much less heavier.

The idea behind this bug report is in principle a good one and I'm not saying it can't be done. in fact large pieces have already been separated out. Nonetheless its going to be a lot of work and needs careful thinking over. Would the gains really outweigh this?

io's init and exit routines weren't made during a spare afternoon; the knowledge gained obviously isn't lost. If I could start all over I'd have done it differently but right now we are where we are, aren't we.

But anyway I'll really stop repeating myself.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 08 May 2020 08:03:15 PM UTC, comment #7: 

I get the warning both for javachk("jvm") and javaclasspath as the first command. java version is

$ java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-8u252-b09-1ubuntu1-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)

Christian Häggström <saturn>
Fri 08 May 2020 05:01:44 PM UTC, comment #6: 

My thinking was not to scrap the init routine, but to keep it exactly as is, just move it from PKG_ADD to each public or private function that uses the Java support that it sets up. You can add a persistent variable to ensure that it only runs once.

This is similar to several examples in Octave, such as the image functions which all call 'maybe_initialize_magick', or the symbolic package which initializes its IPC to SymPy as needed.

FWIW, I believe this warning started with OpenJDK 10 or 11, I have version 11.

Mike Miller <mtmiller>
Project Administrator
Fri 08 May 2020 07:12:02 AM UTC, comment #5: 

Mike's "lightweigt" argument made me think a bit more.

The io pkg initialization merely does this:
1. Check if Octave was built with Java support at all
2. Call Java as a shell command (= effectively outside Octave) to check minimum Java version
3. Try to add Java class libs to the javaclasspath.
If any step gives negative results the rest is skipped.

Formerly, step 1 comprised directly querying the value of one of Octave's internal build flags; IMO as lightweight as can be.
Since bug #47480 this check is done by calling javachk.m. That function somehow fiddles with the Java JVM; whatever it does, it's apparently not so lightweight as just querying some Octave value.

@Christian:
If you start Octave and as first command enter the command:
javachk ("jvm")

do you get that offending warning?
And the same for:
javaclasspath

If you get the warning only with javachk.m, I think we indeed may need to revisit bug #47480.

As to my previous comment #4, I wrote:

  • _it only occurs with a specific dependency on a specific OS, and_

but as I never hit this warning on my Mageia 7 Linux distro (I've only heard it from other users on other distros) it had better read:

  • _it only occurs with a specific dependency on specific distros of a specific OS, and_

BTW, what OpenJDK version do you run?
Mine is:

[philip@deskprn ~]$ java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)

Philip Nienhuis <philipnienhuis>
Project Member
Thu 07 May 2020 10:22:58 PM UTC, comment #4: 

I agree that all SW should be as lightweight as can be, but there's always a trade-off with other factors.

Automatic detection and loading of Java classes was added years ago specifically to stop the reports from users who didn't know how to prepare their system for spreadsheet I/O and/or got stuck with Java JRE issues. Doing quite some involved surgery on the io package just to silence some warnings and as trade-off getting such user reports back is not my ambition.

Obviously there's always a way to fix this but given that this is:

  • merely about cosmetics that are seemingly caused upstream or in core,
  • it only occurs with a specific dependency on a specific OS, and
  • no functionality is affected at all,

mending it features quite low on my priority list and I have little or no interest in spending time on it soon.

@Christian:
In the io package's installation directory, just edit PKG_ADD and PKG_DEL files to comment out the calls to __init_io__.m and __exit_io__.m, and your issue should be over. The flip side is that for more reliable spreadsheet I/O you'ĺl then have to check your Java installation yourself and sort out and add several .jar file to the javaclasspath manually.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 06 May 2020 08:58:04 PM UTC, comment #3: 

Aren't there functions in the io package that don't depend on Java libraries? For example, the statistics package depends on the io package, but only for the cell2csv and csv2cell functions. I think there is definitely a case to be made for package loading to be as simple and lightweight as possible, regardless of the original symptom here of spam on stdout.

Mike Miller <mtmiller>
Project Administrator
Wed 06 May 2020 08:53:57 PM UTC, comment #2: 

Thanks Philip for your insight with the full picture. In principle I agree with "If you don't need the functions, just don't load the io package." but now io loads automatically when statistics is loaded. Perhaps we could change the statistics package to load io lazily, i.e. do "pkg load io" just before running one function from that it needs from io.

What do you think?

Christian Häggström <saturn>
Wed 06 May 2020 08:45:18 PM UTC, comment #1: 

Thanks for your bug report (initiated in bug #47480).

The spam you refer to seems to be an upstream issue.

In a more general setting I think your suggestion is in principle a valid one. However, in the real ugly world things aren't so easy.

As far as the io package's Java usage is concerned, I foresee significant code complexity just to silence undue messages ("spam") from maybe somewhat buggy external SW. As io package maintainer I am not prepared to go that route (yet, that is; but that "yet" may last quite some time).
Another motive is that the io package is only loaded to use the functions inside; the vast majority of it is for spreadsheet I/O. I see little advantage in only detecting Java at the time the first function call is made versus at the time the io package is initialized. If you don't need the functions, just don't load the io package.

BTW in bug #55174 I've just uploaded a patch (also submitted earlier in bug #58266) that fixes the issue that provoked you to enter this bug report. If you're able to build Octave I'd like to invite you to try this patch and report back in bug #55174.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 06 May 2020 07:59:34 PM UTC, original submission:  

Calling external programs at module load time can cause confusing spam on the terminal, such as reported on https://savannah.gnu.org/bugs/?55174 .

Therefore, I suggest postponing the detection of java until an octave function is called, and not have any side-effects at module load time.

Christian Häggström <saturn>

 

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

Attach Files:
   
   
Comment:
   

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 saturn (Submitted the item)
  •  

    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 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-05-08 philipnienhuis StatusNeed Info => Postponed
    2020-05-08 philipnienhuis StatusConfirmed => Need Info
    2020-05-07 philipnienhuis Priority5 - Normal => 3 - Low
    2020-05-06 mtmiller Severity3 - Normal => 1 - Wish
        Item GroupOther => Feature Request
        StatusNone => Confirmed
        Release5.2.0 => dev
        Summary[octave-forge](io) Defer Java detection until a function is called => [octave forge] (io) Defer Java detection until a function is called
    2020-05-06 philipnienhuis Operating SystemGNU/Linux => Any
        Summary(io) Defer Java detection until a function is called => [octave-forge](io) Defer Java detection until a function is called

    Back to the top


    Powered by Savane 3.5