On Mon, 26 Jan 2004, Crossfire wrote:
> As for those who are speaking out against Java, if you seriously think that C
> is a better alternative for writing reliable/robust applications, I suggest
> you toddle off and have your head examined. Part of Java's charm is that it
> is harder to write code with trivial bugs that can result in larger problems.
> If you want a language that is closer to metal in the same category, then look
> at Ada95. Although, if you hate Java, you'll probably hate Ada95 just as
> much.
Well, I wouldn't compare Java to C. Never have and never will.
Compared to Perl, Java is an insecure platform that does *not* reach its goal
of write once run anywhere. Perl can do this admirably. And securely.
Besides, Java's object model is distinctly broken: I cannot rely on the timely
destruction of an object to release the resources used by that object. Thus one
sees all sorts of time-consuming and bug-ridden "pool managers" (for DB
connections) and similar, just to get around the problem.
This is how it is:
The following example assumes MyResourcePig opens and locks some resources
for reading and writing. The destructor releases locks and closes the
resources:
-----------------------------
Java:
-----------------------------
int foo()
{
MyResourcePig abc = new MyResourcePig; /* fail here if resources not
available */
:
: get some work done
:
/* at this point and onwards, we know not when abc will be destroyed */
}
foo(); /* OKAY */
foo(); /* second call usually fails: abc's destructor will not be called until GC
occurs */
----------------------------------------------
Perl (and Python and C++ and ad nauseum):
----------------------------------------------
sub foo
{
my $abc = MyResourcePig->new;
:
: get some work done
:
### at this point, $abc is destroyed and the resources are freed up, i.e.
right now
}
foo(); # OKAY
foo(); # OKAY
This simple difference in language design makes Java far more onerous to use. To
workaround
the MyResourcePig problem, the following hack must be used:
int foo()
{
MyResourcePig abc = new MyResourcePig;
:
: get some work done
:
/* at this point and onwards, we know not when abc will be destroyed,
so we use a hack: close the thing manually - must REMEMBER to do this
consistently throughout or 20,000 line application :( */
abc.close(); /* manually release resources for next caller */
}
This approach does not scale well at all. It is like being back in the days
of tracking malloc() and free() calls in C. One VERY popular use of O-O, and I
deem it essential for scalable solutions, is to automate resource allocation and
freeing, which eases the burden on the programmer and code reviewer to get it
right: it automates the process of closing files, sockets, freeing memory, etc.
The Java approach is to eschew that paradigm and leave the programmer
the task to do it manually, except in the case of memory will will be freed
at some undetermined time in the future.
There are other serious probs with Java (like the container classes, and Java's lack of
support for generic programming) ... but I that's it from me today :)
cheers
rickw
---------------------------------------------
Rick Welykochy || Praxis Services Pty Limited
NAFTA might be friendly to investment but it was not all that
friendly to democracy.
-- Bill Moyers
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
