[Octave-bug-tracker] [bug #55174] java warning about java.system.class.loader property

[Philip Nienhuis]

Follow-up Comment #10, bug #55174 (project octave):

Apologies for quite a long post. I just want to document what I did to
investigate the safety of my patch.

First off, 'make check' shows no FAILs with the patch.

As to "slowness", it turns out there's apparently some issue with LibreOffice,
that is, its UNO-Java bridge that the io package invokes. Maybe it is just my
system.

With and without patch makes for little or no performance difference. But I
still don't know how representative it is what I did.

My procedure:

(install io-2.6.1 package). Then:

>> pkg prefix ~/octave6 ~/octave6  ## just to not interfere with my 7.0.0
installation
ans = /home/philip/octave6
>> pkg local_list ~/.octave6_packages; ## Needs patch from bug #58332
>> pkg local_list
/home/philip/.octave6_packages
>> pkg load io

## Amend following path to LibreOffice on your system:
chk_spreadsheet_support ("", 3, "/opt/libreoffice6.4")
;
; <long listing>
:
UNO interface supported now.

ans = 128
>> javaclasspath
   STATIC JAVA PATH

      - empty -

   DYNAMIC JAVA PATH

      /opt/libreoffice6.4/program/classes/ridl.jar
      /opt/libreoffice6.4/program/classes/unoloader.jar
      /opt/libreoffice6.4/program/classes/juh.jar
      /opt/libreoffice6.4/program/classes/jurt.jar
      /opt/libreoffice6.4/program/classes/unoil.jar
      /opt/libreoffice6.4/program

>> ts = cputime; tic; io_testscript ("UNO", "io-test.xlsx"); tt = cputime;
printf ("cpu time = %f\n", tt - ts); toc

Testing .xls interface UNO using file io-test.xlsx...

 1. Initialize arrays...
 2. Insert first empty sheet...
 3. Add data to test sheet...
 4. Add another sheet with just one number in A1...
 5. Explore sheet info...
 6. Read data back...
 7. Tests part 1 (basic I/O):
    ...Numeric array... matches...
    ...Cellstr array... matches...
    ...special characters... matches...
    ...Boolean... returned as numeric '1' rather than logical TRUE.
 8. Repeat reading, now return formulas as text...
 9. Tests part 2 (read back formula):
    ...OK, formula recovered ('=C2+D2').
10. Cleaning up..... OK
cpu time = 1.742070
Elapsed time is 114.236 seconds.
>>


and CPU time and elapsed time vary from .81 - 1.75 and 50 - 150 seconds,
resp.

I don't know why LibreOffice (through the Java UNO bridge) is so exruciatingly
slow on my Linux system, on Windows it's > 20 times faster.
On the whole, taking into account the wide range of CPU and Elapsed time, I
see little or no difference with and without the patch.

W.r.t. the other Java based spreadsheet I/O interfaces there's no significant
difference either; the same tests run within a few seconds Elapsed time for
all of them together:


## <following up from above verbatim block>
## unload previously loaded class libs:
>> chk_spreadsheet_support ("", -1)
ans = 0
>> chk_spreadsheet_support (tilde_expand ("~/Java"), 0)
ans = 126
>> javaclasspath
   STATIC JAVA PATH

      - empty -

   DYNAMIC JAVA PATH

      /home/philip/Java/jOpenDocument-1.4rc2.jar
      /home/philip/Java/xml-apis.jar
      /home/philip/Java/xercesImpl-2.11.0.jar
      /home/philip/Java/odfdom-java-0.8.8-incubating.jar
      /home/philip/Java/gwt-servlet-deps.jar
      /home/philip/Java/OpenXLS-10.jar
      /home/philip/Java/jxl.jar
      /home/philip/Java/commons-collections4-4.1.jar
      /home/philip/Java/dom4j-1.6.1.jar
      /home/philip/Java/poi-ooxml-schemas-3.17.jar
      /home/philip/Java/xmlbeans-2.6.0.jar
      /home/philip/Java/poi-ooxml-3.17.jar
      /home/philip/Java/poi-3.17.jar
>> ts = cputime; tic; test_spsh; tt = cputime; printf ("cpu time = %f\n", tt -
ts); toc
:
: <even longer output listing>
:
- End of test_spsh -
cpu time = 8.467224
Elapsed time is 8.37337 seconds.  ## ?? smaller nr. than CPU time ??
>>


and those execution times are consistently around 8.4 seconds for each run,
with or without the patch.

==> As far as I'm concerned the patch should be safe to apply.
Any opinions from other Java users ?

    _______________________________________________________

Reply to this item at:

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

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