Rick Welykochy was once rumoured to have said:
> 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.
*cackle*
You think Perl is a Java competitor?
I haven't laughed quite so hard in a while.
Sorry, Perl's language syntax is too flexible again - 5.8.x has utilities to
address some of those issues, and maybe (if we're lucky 6.x will fix them
properly), but they're in completely different classes otherwise. Its
incredibly easy to shoot yourself in the foot, repeatedly, with perl.
> 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.
Which is why when timely destruction is required, there are methods provided
to force resource release - it, unfortunately, is one of the necessary evils
when you have a system like Java's.
If you can demonstrate a way to implement a GC'd object system with both
implicit destroy, and explicit destroy, whilst keeping the ability for safe
references, and without sacrificing performance, I'm sure you'd make a lot of
people happy.
Why is this an issue?
Lets create a magical 'delete' keyword, the opposite of 'new'.
Consider the situation:
---
class Foo {
public Object fooref;
private Object foo;
public void makefoo() {
foo = new MagicalObject();
fooref = foo;
}
public void breakfoo() {
delete foo;
}
}
---
Now, what is the CORRECT value of fooref after you've called makefoo()
followed by breakfoo()? How do you implement this correctly on the metal
efficiently? How do you resolve this in threaded situations when a thread
accesses fooref at the same time that the object is being deleted?
This is one of the reason swhy Java doesn't have explicit deconstructors.
Its to prevent you from doing something stupid with object referneces.
Perl's system is Ref Counting, which may work most of the time, but allows you
to leak memory if you create reference rings and lose the entry reference to
that ring. That's not exactly ideal either.
C.
--
--==============================================--
Crossfire | This email was brought to you
[EMAIL PROTECTED] | on 100% Recycled Electrons
--==============================================--
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
