RE: maximum memory for gcj-compiled executable?

["Erik Poupaert" <erik dot poupaert at chello dot be>]

>>>>>> It's a known Java best-practice (well, not so well known
>>>>>> unfortunately) to null
>>>>>> unused references (and their references, and so on) and to
>>>>>> explicitly close or
>>>>>> clean objects that represent system resources like
>>>>>> connections and statements.

It's also the jdbc interfaces that are quite counter-intuitive. I mean,
closing the connection sounds reasonable, since you need to close the
underlying socket. However, the need to close statements and resultsets
explicitly is less obvious. What system resources should be involved with
formatting incoming and outgoing messages? All of that should be
automatically transient and should not hang on to any resources ... If it
does anyway, it is probably related to little-known features, that are of
little use.

The memory management problems with jdbc are therefore -- as usual -- the
result of extensive over-engineering along with unbounded feature growth; in
other words, it boils down again to the number one source of bugs in any
piece of software.