× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




Something is wrong if Java crashes frequently on your system. Is there
a pattern?

Hmmm... There's three problems that are relatively consistent:

a) The applet that runs on the left-hand side of the window in the information center. Works in some browsers, not in others. Different browsers require different versions of the JVM in order to stop from crashing. When you don't strictly adhere to the ones that IBM tells you you should use, all sorts of bad things happen... browser randomly closes, or it'll lock up, or it'll chew up all the CPU resources, etc.

b) WDSC crashes about once a day. The error message says it's the JVM crashing.

c) On the iSeries, there's a particular program that crashes the JVM. It's one that uses the HSSF classes to load a spreadsheet and update certain columns. Sometimes it works fine. Other times, it gets an error with memory access (illegal teraspace offset or something like that.) Considering that there aren't any pointers in Java, that's a little weird. After that happens, the next time I run it, the JVM comes crashing down, and won't run again until I sign off and back on again.

IMHO, an application should not be able to crash the JVM!


My experience with RPGIV and Java shows that performance and stability are not a deciding factor. Java can be stable just like RPGIV can be unstable. The first major Java application I wrote was a shop floor program for a mill that runs 24x7x363 days/year. It doesn't crash and has about 50 users relying on it at any given time.

That's good...

We have a couple of hundred iSeries users users that run applications
written in Java all day long that used to be written in RPGIV. The last
time we installed some Java code that caused a crash was about two years
ago. The last time we had some RPGIV code crash was about two months ago
when a vendor supplied RPGIV program looped on an authority failure and
loaded up our audit journal and took our system to a restricted state. I
just fixed a problem with an RPGIV program one of our developers wrote
that opened an IFS file but never closed it, which led to a job
crashing. Testing should have identified these problems.

That sounds like a bug in the app, not a bug in the RPG runtime. Please note the distinction -- my problems have to do with the JVM crashing, not a program crashing.


If I write a program and it crashes, it's a bug in my program. I can't blame Java for that! But when the JVM crashes, that's another story.

But, some day they'll fix those problems. That's not the big issue with Java. (At the time I wrote that message, I had just lost an hour's work from WDSc crashing and complaining that it was the JVM that crashed, so I was frustrated.)

The big problem is how slow and resource-intensive Java is. If I can write the same program in Java and RPG, the RPG one will work better. Likewise, any other language (C, VB, Perl, etc) will outperform Java in a major way. It's always shocked me that Java should be a fraction of the speed of interpreted languages like Perl! Java is compiled, even if it's just down to byte code, it should still be quicker than interpreting the source as you run it.

I've yet to find anything that makes sense to write in Java because of this performance issue. I can pretty much always write the same thing in RPG, and it'll run much faster. Or, if it's something that does not lend itself well to RPG, I can write it in C. So, why would I want to write it in Java?



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.