RE: Java and OO Concepts

Joe wrote:

In fact, I prefer RPG procedures because I can pass multiple
input/output parameters; it's a very nice technique.

You can have multiple I/O parameters in Java easily by using a
"value holder" object, e.g. ValueHolder which has simply one
public property, "value". Simply pass a valueholder for each
I/O parameter and replace "value" with the object to be returned.

Date: Sat, 7 Mar 2009 12:19:04 -0600
From: joepluta@xxxxxxxxxxxxxxxxx
To: java400-l@xxxxxxxxxxxx
Subject: Re: Java and OO Concepts

Thorbjoern Ravn Andersen wrote:

So you like words (four byte values?) as they can be atomically compared
instead of the more complex String comparison?

Not to travel too far down this road, but multi-byte compares in i5/OS
are pretty low-level, and I don't think it's so much of a word thing.
Power chips are 64-bit machines, anyway, so my guess is that if you go
that far down anything less than eight bytes is a pretty fast compare.

An RPG aversion against calling subroutines? *B*

Not sure what you mean by this. I have absolutely no aversion to
calling subroutines or procedures. Good RPG, especially /free, is
every bit as modular as Java or indeed any other language. In fact, I
prefer RPG procedures because I can pass multiple input/output
parameters; it's a very nice technique.

Or just the subconsious doing continouos microoptimizations? That is
really a mind set hard to get rid of :)

I don't ever eant to get rid of continuous micro-optimizations. That's
why my code is very, very fast.

I'd like to hear them. Get it all out! Feel better!!

Nope. I've done it in the past. The BigDecimal alnoe is enough to kill
the entire language in my estimation. Add in a lack of an integrated
ISAM database and I get ill thinking about writing real business
applications.

So these performance problems is not per se the fault of the JVM but
somebody doing stuff in the wrong place, if I understand you correctly.
Probably much worse than allocating a few extra String objects :)

I think the JVM is a work of art. I think the i implementation of the
JVM, especially the seamless integration between Unicode and ECBDIC, is
nothing short of genius.

But I think the big problem with some Java projects is that the
programmers use classes without understanding them, and then someone
else builds on those classes, and then someone else builds on those, and
by the time you're done you have steaming fetid piles of doo-doo. :)
It depends on the programmer, of course. Some programmers are more
doo-doo-prone than others.

I agree on the varying quality of open source projects. That is where
reputation comes in - I tend to expect more from a mature Jakarta
project than from a stale sourceforge project with a single developer,
but both may be very useful to you in the situation.

Just don't put the latter into production. Use it for proof of concept
then rewrite it if you need it.

Joe
--
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.

_________________________________________________________________
De leukste online filmpjes vind je op MSN Video!
http://video.msn.com/video.aspx?mkt=nl-nl