Re: Java error when updating existing Excel spreadsheets using HSSF

Hi Greg,

Is there some way I can reproduce this error on my box? I'm really struggling to determine what, specifically, is going on.

So I guess I'm saying that either you need to debug the code in detail to figure out what's going on, or you need to tell me how to reproduce the problem so I can debug the code in detail. Right now I just don't have any information about the problem other than "it doesn't work and the JVM crashes." Which is just a bit too broad for me to troubleshoot...




Fleming, Greg (ED) wrote:

Scott,

I downloaded your latest, installed the 3.0.1 POI, changed the upddemo
program to include the "if book = *null" code you mentioned below. It
never gets to the "if" block, though, because the error occurs inside of
the hssf_open procedure and the program terminates immediately.
I still get the same error, but now it happens on the next line "
wwPOIFS = new_POIFSFileSystem(wwFile);" which seems odd, given that this
line is inside a monitor block. As soon as I step into the line,
program terminates.

There aren't any messages prior to the JVM termination in the job log.
As you can see in this snippet, it goes straight from calling the
upddemo program to crashing:

*NONE Request 11/29/07 13:23:23.598896
QWTSCSBJ *N QCMD QSYS 0189
Message . . . . : -CALL
PGM(UPDDEMO)
MCH74A5 Escape 40 11/29/07 13:23:30.047264
realcftrap2 001728 QJVAJNI QSYS *STMT
To module . . . . . . . . . :
QJVAJNI
To procedure . . . . . . . :
CallVoidMethodA
Statement . . . . . . . . . : 1
Message . . . . : The Java
Virtual Machine has ended.
Cause . . . . . : Java Virtual
Machine 1 has ended because of reason 2. The
reason codes are defined as
follows: 01- A Java program called the
java.lang.System.exit method with
a zero status code. 02- A Java program
called the java.lang.System.exit
method with a non zero status code of 134.
Again as before, there is also a spooled file produced from the job
containing this text: FATAL ERROR in native method: native code passed a null object to a
non-static method
java.lang.Throwable

Anything else I can look at to find some kind of error messages prior to
the inglorious death of the JVM ?
Thanks again.

Greg


|-----Original Message-----
|From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-
|bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
|Sent: Thursday, November 29, 2007 12:39 PM
|To: RPG programming on the AS400 / iSeries
|Subject: Re: Java error when updating existing Excel spreadsheets using
|HSSF
|
|Greg,
|
|You are using an outdated copy of HSSFR4. Please download and use the
|current one. I know that your copy is outdated because the
|FileInputStream vs FileOutputStream thing was corrected in Aug 2006 --
|more than a year ago.
|
|The most recent version can be found in the following article
|(Systeminetwork.com membership required, but a free "associate"
|membership will work):
|http://www.systeminetwork.com/article.cfm?id=55032
|
|Having said that, it's important to understand that RPG's O=Object data
|type aren't the actual Java objects. They're just REFERENCES to the
|objects. Under the covers, they're just numbers -- and the numbers are
|used by the JVM to locate the actual object, which always resides in
the
|JVM itself. So whether I coded FileInputStream or FileOutputStream
|doesn't really matter, as long as the number does actually refer to a
|FileInputStream object in the JVM. The reason that code made it into
|wide use is because it worked, despite being coded incorrectly, because
|it still referred to the right type of object.
|
|
|Regarding the "JVM ended, Reason code 2" error:
|
|That almost always happens when you pass a *NULL object to a Java
|routine. Like I said, RPG's O=Object data type is only a number that
|refers to a Java object. If you set that number to *NULL (which under
|the covers is zero) the JVM will be trying to refer to an object that
|doesn't exist, and that causes it to become confused and end
abnormally.
|
|Note that hssf_open() returns *NULL if it can't open the file. Your
|code is SUPPOSED to check for that *NULL, and either try again, or end
|the program, or whatever it needs to do, when it encounters the *NULL.
|What it should NOT do is pass that *NULL object to another Java
routine.
| And I suspect that this is what it's doing.... it's not checking for
|the *NULL, and is proceeding as if everything is fine. And when Java
|gets that *NULL value, it crashes the JVM.
|
|So you can fix that by changing your code to something like this:
|
| book = HSSF_open('/path/to/whatever.xls');
| if (book = *null);
| *inlr = *on;
| return;
| endif;
|
|So... if the open failed, the program does not try to manipulate the
|workbook (since it was never loaded), it just ends.
|
|That'll stop the JVM from crashing, but won't cause the HSSF_open()
|routine to load your spreadsheet. There should be earlier messages in
|the job log (earlier than that JVM ended thing) that explain why the
|file didn't open...
|
|
|
|Fleming, Greg (ED) wrote:
|> Scott,
|>
|> Some further info may help us narrow this down.
|>
|> In debug, the error appears to occur in the HSSF_Open procedure at
|line
|> 1559
|> wwFile = new_FileInputStream(wwStr);
|>
|> I had read on another list somewhere that the preceding definition on
|> line 1553:
|> D wwFile s like(jFileOutputStream)
|> Was in error and should be corrected to:
|> D wwFile s like(jFileInputStream) .
|>
|> I did this, recompiled the module and re-created the service program,
|> then rebound
|> The upddemo program. But I still get the same error either way.