bugGNU Octave - Bugs: bug #46010, methods.m: often fails if applied...

 
 

bug #46010: methods.m: often fails if applied to more complicated Java objects

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Sun 20 Sep 2015 11:02:26 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  philipnienhuis
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * 4.0.0 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 02 Oct 2015 03:46:43 PM UTC, comment #4: 

I pushed a slightly adapted changeset on stable:
http://hg.savannah.gnu.org/hgweb/octave/rev/5d31cd795c21

Philip Nienhuis <philipnienhuis>
Group Member
Tue 22 Sep 2015 04:49:35 PM UTC, comment #3: 

I think this should go on stable; I also see it in octave-4.0.0

Philip Nienhuis <philipnienhuis>
Group Member
Mon 21 Sep 2015 05:45:36 AM UTC, comment #2: 

Title adapted a bit

Philip Nienhuis <philipnienhuis>
Group Member
Sun 20 Sep 2015 11:04:54 PM UTC, comment #1: 

Here's the changeset

(file #34941)

Philip Nienhuis <philipnienhuis>
Group Member
Sun 20 Sep 2015 11:02:26 PM UTC, original submission:  

methods.m always applies the (Java) "getMethods" method to the class names rather than the actual Java object.
For some (several) more complicated Java objects this will fail.
Sample using JExcelAPI (just to illustrate):

>> javaclasspath
   STATIC JAVA PATH

      - empty -

   DYNAMIC JAVA PATH
:
      /home/philip/java/jxl.jar
:
>> xls = xlsopen ('new.xls', 1, 'jxl')
Checking requested interface(s):
JXL*; (* = default interface)
xls =

  scalar structure containing the fields:

    xtype = JXL
    app =

<Java object: java.io.File>

    filename = new.xls
    workbook =

<Java object: jxl.write.biff.WritableWorkbookImpl>

    changed =  3
    limits = [](0x0)

>> methods (xls.workbook)
error: [java] java.lang.ClassNotFoundException: jxl.write.biff.WritableWorkbookImpl
error: called from
    methods at line 53 column 14


However, applying getMethods() to the Java object itself:

>> strsplit (javaMethod ("getMethods", "org.octave.ClassHelper", xls.workbook), ";")
ans =
{
  [1,1] = java.lang.String getName(int)
  [1,2] = void write() throws java.io.IOException
  [1,3] = void close() throws java.io.IOException, jxl.write.biff.JxlWriteException
  [1,4] = java.lang.String getExternalSheetName(int)
:
<many methods snipped>
:
  [1,43] = void notifyAll()
}
>>


A try-catch where getMethods() is first applied to the Java object and if this fails, converting to the class name in the catch clause, is a simple fix for this bug.

I'll upload a changeset as soon as I have the bug number.

Philip Nienhuis <philipnienhuis>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #34941:  java_methods.cs added by philipnienhuis (1KiB - text/x-csharp)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by philipnienhuis (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-10-02 philipnienhuis StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
        Releasedev 4.0.0
    2015-09-21 philipnienhuis Summarymethods.m: often fails if applied to complex Java objects methods.m: often fails if applied to more complicated Java objects
    2015-09-20 philipnienhuis Attached File- Added java_methods.cs, #34941
        StatusIn Progress Patch Submitted

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code