Could someone explain why there is no destructor in Java classes?

There are many times you need to be called WHEN an object goes out of scope
and not when it will eventally be freed.

mlw <mlw@nospamnoway.zzwrote:

Could someone explain why there is no destructor in Java classes?
>

The explanation I remember is destructors are generally used to free
memory, and Java has garbage collection. Doesn't make it right, but that
is the way it is.

- Kurt

~kurt wrote:

mlw <mlw@nospamnoway.zzwrote:

>
The explanation I remember is destructors are generally used to free
memory, and Java has garbage collection. Doesn't make it right, but that
is the way it is.

That's one of the things that bothers me about Java. So many newbe CompSci
people think it is wonderful, but it has so many glaring omissions and all
too often it falls short of a real and useful programing language. Like
Windows, skill in Java comes from knowing the trivia of Java, and not from
the theory and science of your algorithms.

In article <duGdnaEi0J4EvLXbnZ2dnUVZ_q_inZ2d@comcast.com>, mlw <mlw@nospamnoway.zzwrote:

>~kurt wrote:
>

>
>That's one of the things that bothers me about Java. So many newbe CompSci
>people think it is wonderful, but it has so many glaring omissions and all
>too often it falls short of a real and useful programing language. Like
>Windows, skill in Java comes from knowing the trivia of Java, and not from
>the theory and science of your algorithms.
>

There are a large number of places running real and useful enterprise
applications that were written in Java.

Being skilled in algorithms makes you a good developer. Java does nothing to
take away from that. Being skilled in Java "trivia" - aka the language and
"libraries" - makes you a better developer, but that's true of any language.

Java has its warts. Also true of all other languages I've seen.

Eric

"mlw" <mlw@nospamnoway.zzwrote in message
news:duGdnaEi0J4EvLXbnZ2dnUVZ_q_inZ2d@comcast.com. ..

~kurt wrote:
>

>
That's one of the things that bothers me about Java. So many newbe CompSci
people think it is wonderful, but it has so many glaring omissions and all
too often it falls short of a real and useful programing language. Like
Windows, skill in Java comes from knowing the trivia of Java, and not from
the theory and science of your algorithms.
>

Total nonsense. Destructors have nothing whatever to do with general theory
and science of algorithms.

In the C++ object model where objects (class instances) and the lexical
reference to them have a one-to-one relationship destructors make sense. The
fact that C++ does not offer GC makes them even essential. And yes, many
other usefull constructs can be expressed using destructors.

In Java (and most other contemporary programming/scripting languages) the
object instance and the syntactical construct referencing it are loosely
coupled. Objects can have zero or more references pointing to them, not
unlike C++ pointers (or C++ references, for that matter). Such an object
model does not allow the definition of a destructor like construct because
the lexical scope of an object reference and the lifetime of the actual
object instance are at best indirectly related.

If you value a theoretical approach to programming than you should be able
to distinguish abstract algorithms from language constructs that allow you
to implement them. If you find yourself unable to implement your abstract
algorithm in a language without destructors (which would not leave you many
options anyway) then you obviously are unable to make that distinction.

Silvio Bierman

Silvio Bierman wrote:

>
Total nonsense. Destructors have nothing whatever to do with general theory
and science of algorithms.
>

Well, for that matter, neither do constructors.

The reason for not implementing destructors in Java is,
I think, that many found it difficult to properly use them
(if not completely omit them), and this is compatible with not
implementing pointers.

Personally, the thing I miss the most from C++ is operator overloading.
(Readability is to blame here, I guess.)

Obviously, the designers had in mind things other than
developing a scientific computation or a system programming language
when designing Java.

Faton Berisha

"Faton Berisha" <fberisha@uni-pr.eduwrote in message
news:jOudnWNAmvxCCd_bnZ2dnUVZ8qLinZ2d@giganews.com ...

Silvio Bierman wrote:

>
Well, for that matter, neither do constructors.

Off course. Only a language as a whole represents a view on implementing
algorithms.

>
The reason for not implementing destructors in Java is,
I think, that many found it difficult to properly use them
(if not completely omit them), and this is compatible with not
implementing pointers.
>

I already stated why a destructor is in contradiction with the Java language
logic. Java object references are quite close to pointers in C(++). Only the
concept-mix of arrays and pointers that C++ inherited from C (as much as
Stroustrup said to regret that) is totally missing which means no pointer
arithmetic.

Being an old time C (and since its early conception, C++) programmer I kind
of liked pointer arithmetic and I must admit I sometimes miss it when doing
some array fiddling in Java.

Personally, the thing I miss the most from C++ is operator overloading.
(Readability is to blame here, I guess.)
>

I welcomed it when it was added to C++ and used it enthousiasticly. In
retrospect I find it is only suitable when implementing very generic classes
(like strings, collection classes etc). I always found application level
logic to be expressed best with descriptively named operations
(functions/methods).

Obviously, the designers had in mind things other than
developing a scientific computation or a system programming language
when designing Java.

My guess is they started with C++ but wanted something managed (Virtual
Machine based) and simpler (quirk-free as opposed to C++ which is full of
quirks that only language theorists like to play with). They made some good
design decisions, some bad. The resultng Java environment just works,
despite some things I would like to have seen different about the language.
The cross-platformness and the enormous amount of freely availably libraries
for almost anything a developer could need in combination with an OK
language has effectively won me over.

I find it pointless to discuss isolated language details or doing
apples/oranges comparisons between programming languages. In the end the
quality and timely availability of the resulting software systems is all
that counts, whichever languages where used to implement them.

Silvio Bierman

>
Faton Berisha