× 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.



Scott, that's a pretty major backpedal.  Here's your original statement:

"I'm so tired of Java crashing on my '400 that 
it's ridiculous.  It's bad enough that it takes over a minute to run a 
"Hello World" program (if it's the first program to use the JVM in the 
job) but then when the @#(*% JVM crashes all the time with anything 
moderately complex, it just makes me sick."

This says specifically that the JVM crashes ON THE 400 over and over
again, with "anything moderately complex".  As it turns out, though, you
only know of one program that actually causes problems on the iSeries
JVM.

How about toning down the rhetoric just a tad, eh?  Even if you lost an
hour's work from WDSC, that's no reason to Java-bash (for one thing, it
means that you hadn't saved for over an hour, and I frankly don't have
any sympathy).  Statements of this nature from people like you who are
respected in the community are often repeated and cause a lot of
unnecessary damage.

"Scott Klement said that his iSeries JVM crashes all the time!" (and,
just like in the newspaper, later retractions seem to get little notice
<grin>).


> The big problem is how slow and resource-intensive Java is.

For what?  For web-page serving it's really very good.  For database
access it's really very bad.  As far as I can see, the big problem is
that you don't have a problem set for which Java is a good fit.

I'm the first one to pound my shoe on the table over the fact that RPG
is far better than Java for programming business logic.  At the same
time, Java is a stunningly powerful language for user interface.  It's a
matter of using the right tool for the right job.

Now, there is an argument to be had over which of the C variants is best
for a given job.  Straight C is nice for systems programming that
doesn't need a lot of code reuse.  Java is better when your problem
domain is complex but static.  C++ seems to fit somewhere in between,
and is probably the best suited language for database programming in
Unix (although I'd say Java is pretty good as well).  And of course
there's C#, which is the only real option in the .NET world outside of
VB.  Choosing among these probably has more to do with your history than
any objective measure.


> 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.

When's the last time you saw a benchmark that said this, Scott?  Have
you actually run production Java code?  Are you familiar with the JIT
compiler?  Thanks to the incredible work done by the JIT folks, these
days Java far outstrips any interpretive language and begins to approach
compiled code in performance, especially for computation-intensive
tasks.  In my arithmetic tests on my box (which is old and sports a
fairly out of date JVM), Java actually performs quite well with RPG.


Anyway, I don't want to get into a long involved argument.  It's my
opinion that each language has jobs for which it is well suited, and
jobs for which it is not well suited.  Many languages fill similar
though not identical niches, and choosing between them is as often a
pragmatic matter of expediency or personal knowledge as it is a purely
objective one.  But what I HAVE learned is that someone who consistently
bashes a language just as a language has probably been using that
language the wrong way.


Joe



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.