finalize()

[cy]

Is there a way to make sure that finalization always occurs; that an
object's finalize() method is always called before program exit?
Thanks

 

[Eric Sosman]

cy wrote On 02/09/07 17:04,:

Is there a way to make sure that finalization always occurs; that an
object's finalize() method is always called before program exit?

There are ways to improve the chances the finalization
will occur, but as far as I know there is no way to be
completely sure.

Why do you care? Are you a C++ convert who thinks
finalizers are destructors? They're not, and can't act
as destructor substitutes -- not reliably, anyhow.

 

[grasp06110]

I believe the spec states that there is no guarentee that finalize
will ever be called. Also, there is certianly no guarentee as to
*when* finalize will be called.

A fairly effective way to ensure resources are deallocated is to write
a super class that alocates the resource and subclasses to use the
resource. Something like the following:

public abstract class DoSomething {
public abstract void doIt();
public void doSomething() throws Exception {
File file = null;
try {
this.doIt();
} finally {
if(file != null) {
file.close();
}
}
}
}


public class Doer extends DoSomething {
public void doIt() throws Exception {
throw new Exception("i hope this doesn't cause any problems");
}
}

 

[cy]

thanks, grasp
so the compiler (javac) produces one error when given the following:
class File {
void close(){}
}
abstract class DoSomething {
public abstract void doIt();
public void doSomething() throws Exception {
File file = null;
try {
this.doIt();
} finally {
if(file != null) {file.close();}
}
}

}

public class Doer extends DoSomething {
public void doIt() {};
public void doSomething() throws Exception {
throw new Exception("i hope this doesn't cause any problems");
}
public static void main(String[] args) {
Doer d = new Doer();
d.doSomething();
System.gc();
}
}

 

[cy]

cy wrote On 02/09/07 17:04,:


There are ways to improve the chances the finalization
will occur, but as far as I know there is no way to be
completely sure.

Why do you care? Are you a C++ convert who thinks
finalizers are destructors? They're not, and can't act
as destructor substitutes -- not reliably, anyhow.

thanks, Eric
yes, I learned C++ first 'cause was told would facilitate learning
java;
appreciate difference between java finalize() and C++ destructor, just
wondering if finalization can be essentially forced -- apparently not.
Greg

 

[Lew]

class File {
void close(){}
}
abstract class DoSomething {
public abstract void doIt();
public void doSomething() throws Exception {
File file = null;
try {
this.doIt();
} finally {
if(file != null) {file.close();}
}
}

}

public class Doer extends DoSomething {
public void doIt() {};

You failed to implement the abstract method.

public void doSomething() throws Exception {
throw new Exception("i hope this doesn't cause any problems");
}

The idea is not to override doSomething() but to let the superclass
doSomething() call the overridden doIt().

public static void main(String[] args) {
Doer d = new Doer();
d.doSomething();

This must be line 26. (You might have considered helping on this matter.)

You failed to catch the Exception that doSomething() might throw.

System.gc();

This is a dilatory call. It is not guaranteed to run the gc, and if it does
might cause a full generational collection instead of a simple nursery one,
thus possibly reducing performance.

}
}

The call to d.doSomething() (notice where the message points that out?) might
throw an Exception, which "must be caught *or* declared" [emphasis added - you
misspelled the message - next time copy and paste it to avoid typos], just
like the message says. Either put a try ... catch around the call or declare
the method that uses it to rethrow the Exception. (Which makes no sense to do
with main().)

Perfect sense.

- Lew

 

[Lew]

You failed to implement the abstract method.

My mistake, I mean there is a syntax error in the implementation. There should
not be a semicolon there.

- Lew

 

[Chris Uppal]

yes, I learned C++ first 'cause was told would facilitate learning
java;

Whoever told you that was an idiot^H^H^H^H^H^H^H^Hwrong.

-- chris

 

[nukleus]

Whoever told you that was an idiot^H^H^H^H^H^H^H^Hwrong.

Huh?
What is java on the first place, mr. mouth foaming smart?
Can you describe it?

Before you do that, i can just tell you,
it is about 90% C code and the object oriented concepts
come from C++ ideas that were ALREADY implemented
and verified to be viable.

I did read some rants by one of the highest priests,
architects at Sun, but his arguments as to the very
language seemed to be nothing more than mouth foaming,
claiming that C++ is completely wacky and incomprehencible.
This dude, who is probably the CHIEF architect at Sun
is simply a lunatic.

Simple as that.

Zo...

Kindly describe what constitutes java as such
and what makes it fundamentally different.

Sure, some things like thread concepts and other
operating system level ideas are expressed on a language
level, which I do support because it makes it more portable.
But that is just a beginning of the story and not the end.

 

[Lew]

Huh?
What is java on the first place, mr. mouth foaming smart?

The /ad hominem/ attack does not go far to support your point.

Can you describe it?

Before you do that, i can just tell you,
it is about 90% C code and the object oriented concepts
come from C++ ideas that were ALREADY implemented
and verified to be viable.

Aside from the arbitrary nature of that "90%", it is the similarities of C++
to Java that contribute to the difficulty of making the switch. For example,
C++ "reference" semantics and Java "reference" semantics are not the same,
which can mess up anyone moving back and forth between them until they get
used to the differences. It is the subtlety of the differences that makes them
difficult.

I did read some rants by one of the highest priests,
architects at Sun, but his arguments as to the very
language seemed to be nothing more than mouth foaming,

The word "seemed" in its passive voice disguises the semantic of making a
judgement while obfuscating the lack of evidence for it.

claiming that C++ is completely wacky and incomprehencible.
This dude, who is probably the CHIEF architect at Sun
is simply a lunatic.

Simple as that.

Zo...

Kindly describe what constitutes java [sic] as such
and what makes it fundamentally different.

What constitutes Java as such is the Java Language Specification:
<http://java.sun.com/docs/books/jls/index.html>
.. There are many things that "make... it fundamentally different" from C++ -
built-in Hoare monitors, GC, lack of templates, no preprocessor, different
reference semantics, lack of pointer arithmetic, pragmatic culture vs.
ivory-tower culture, little variegated parrots that peck at suet, ...

Sure, some things like thread concepts and other
operating system level ideas are expressed on a language
level, which I do support because it makes it more portable.
But that is just a beginning of the story and not the end.

You are exactly right.

- Lew

 

[nukleus]

The /ad hominem/ attack does not go far to support your point.


Aside from the arbitrary nature of that "90%", it is the similarities of C++
to Java that contribute to the difficulty of making the switch. For example,
C++ "reference" semantics and Java "reference" semantics are not the same,

This is probably one of the REAL "major" differences
as Java attempts to get away from the very idea of a pointer,
and especially a pointer to a function. But, no matter how
you twist it, you still can not abandon the idea of a pointer
and an address as such. You'll just have to wrap it up in a
different wrapping, but undelying meaning is still the same.

In C, you have a direct access to addresses via concept of pointer,
and you can cast that pointer into any kind of object, even though
the very notion of cast violates some of the major object orienter
programming principles as it exposes the error prone cast approach.

But even to call this one a "major" difference is but a joke.

which can mess up anyone moving back and forth between them until they get
used to the differences. It is the subtlety of the differences that makes them
difficult.

Yep. Working with java, you have to forget about the way
you thought before, and the differences are more subtle
than fundamental.

The word "seemed" in its passive voice disguises the semantic of making a
judgement while obfuscating the lack of evidence for it.

"Seemed" because I did not have much time at the moment
to start thinking what he actually means by saying things
like: These (C++) designers are screwed up in their head
because the very concepts of their (object oriented)
languages simply do not make sense to mere mortals.
Than, if I remember correctly, goes into isoteric and
philosophical formulations.
But Java makes is clear ans simple.

I do not remember what was the very point he was trying
to make as it was all nothing but pure grade slugging,
even on the level of english language.

When you get into computer language philosophical
discussions, it can get pretty isoteric.

Now, that you seem to be making some big deal out of it,
i would like to his his article again and get into it
in more detail. I just don't remember where i saw that
article.

Simple as that.

Zo...

Kindly describe what constitutes java [sic] as such
and what makes it fundamentally different.

What constitutes Java as such is the Java Language Specification:
<http://java.sun.com/docs/books/jls/index.html>

Thanks, not interested at the moment.

.. There are many things that "make... it fundamentally different" from C++ -
built-in Hoare monitors, GC,

You mean GC is wired into the very language spec?

lack of templates,

And what am I seeing here in just about any code exaple?
Well, generics, that are only recently introduced.

no preprocessor,

Is is something fundamental?
I, personally like the idea of preprocessor.
First of all, you are not forced to use it,
and, by its very name, it implies that it is not
part of a language proper. It simply goes though
your source files and does a string substitutions,
and, after it is done, the compliler proper does its job.

So, the very preprocessor simplifies things and makes it
easier to define some constants that do not even exist
in terms of being stored somewhere in your program.
They only exist on compile time level.

That is pretty much one of the first things I had to
deal with when i inherited this pile of java code as i
wanted to define some constants and was not so plesantly
surprised with what i saw in documentation.

different
reference semantics, lack of pointer arithmetic,
Well...

pragmatic culture vs.
ivory-tower culture,

Huh?
What I am seeing with java is that very iviory-tower
images all over the place, going to the point of mouth
foaming lunacy with all this upper/lower case issue,
and, to this moment, nobody presented an argument
on why in the world it is so important of an issue?

Do you understand the meaning of some label if it is
ALL written in lower case? Or meaning somehow magically
evaporates?

Just like one individual said: When Microsux introduced
their "Hungarian notation", it was nothing different than
raging nazism in terms of being presented as a holy word
of God and enforced with art twisting viciousness.
If you did not use that "hungarian" notation,
you couldn't get a job or a contract.

Is it supposed to be funny?

I have my own way of looking at things
and I could care less who thinks what about it
and whether THEIR eyes get ripped appart because of
the most innocent things imaginable, such as starting
method names in lower case. But why?

- (voice from above) This is just a convention.
You MUST follow it.
Otherwise, the ivory-tower java priests
are not going to talk to you,
as they'll INEVITABLY consider you
as some "unswivilized" entity,
and their minds are programmed
to consider such entities
as non Aryan, and, therefore, filth of human race,
to be exterminated at all cost,
to purify the blood of mankind.

Funny, ain't it.

You, just about the highest priest I have seen
around here, are talking about IVORY TOWERS?
While sitting on that very ivory tower
and making all the ivory tower proclamations
as to the very nature of things?

According to what kind of monkey logic?

I bet you can't even read my post without
your blood temperature raising to the point
of boiling. Just of this stupid lil capitalization
issue, not even worth a minute to be even mentioned.

And what have you made of it?
Just about the BIGGEST difference between C, C++ and Java?

(Well, not sure whats the deal with your humor department,
and, from what i have seen to date, it seems to be
UTTERLY abscent. There ain't such a thingy on the first place)

little variegated parrots that peck at suet, ...

Well, that is about the extent of it all.

But, strangely enough, you did not mention the very
JVM idea and never commented on that other post
where I asked what is so fundamentally different
between JVM and a P code idea of Pascal?

So far, the differences you mentioned do not look like
something fundamental in nature. Some of it could be
simply added as libraries to C/C++ without even winking
an eye.

You see, at the end, you'll still rely on underlying
operating system for memory management, file system
operations, threads and all the other MAJOR mechanisms
and concepts.

I am not here to argue Java is "bad" and C++ is "good".
Because I am not a priest on the first place.
I do not operate using the fascist black and white model
of the world.

To me, life force is a rainbow, where it is literally
impossible to distinguish one color from the next one
in spectrum. Just about ALL you can come up with, is
fracturization and compartmentation of life force,
trying to dissect the Infinite Intelligence and
place it into nice lil boxes
with labels,
such as
"Coca Cola is GOOD. DRINK Coca Cola!"

And not only it is a rainbow, undivisible,
but MULTI-DIMENSIONAL one at that.

You comprehende?

Existence is a MULTI-DIMENSIONAL reality.
There exists no central point,
from which all is to be defined or seen.

You can look at it from just about any point
in this Infinite, multi-dimensional structure,
and no specific point of view
can possibly be classified as valid,
as they are ALL vaild.

It is just a matter of different point of view.

I do not wish to waste my royal time
on teaching you the most basic stuff there is,
the stuff of LIFE itself.

You just keep walking wherever you wish to walk.
But when you cross my path,
beware.

You'll have to put aside all your rigid assumptions
and "constraints" of all kinds and be ready to
deal with RAW energy, and not your puppet world
in a shadow theatre,
where your strings are pulled
and you jump like a bunch of puppets.

As you will be exposed to all 5 fire signs
and not tripple armor will help.
Trust me.

What will be left of you
isn't even worth mentioning,
and I am giving you a BIG favor
by telling you that.

Cause I am a destructor of those ivory tower sitting
priests of your kind.

You see, in C++ they have a concept of destructor,
which I personally like. Because, first of all,
you are not forced to put anything to it,
but when it is hit in run time,
you are GUARANTEED that certain rules apply now,
as as soon as you exit it,
just forget about that object.

So, in my main Processor class,
i have a routine --}) called
Terminator.

Now, it is legal to call Terminator from just
about any place in the program conceivable,
and what Terminator guarantees
is that
1) Your main thread will be terminated
and terminated gracefuly.
2) Your frame will be properly disposed of.

So, if you are in a deadly situation and can not
figure out how to handle some out of the blue error,
just call the Terminator.
Guaranteed to work just fine.

Get it?

You are exactly right.

About what?
The begining or the end?

Well, from the standpoint of multi-dimensional reality,
all pervasive, it is BOTH.

Ever heard of 7 folded Truth?

Goes back about 5000 years BC.

It goes something like this:

1. It IS.
2. And it is NOT.
3. And it is BOTH.
4. And it is NEITHER.
5. And it is all of the above
6. And it is none included
(Sorry, do not remember the last one)

Now, your entire modern science
breaks on step 3, and, to be more strict,
on step 2.

Because, starting with step 2, your entire logic
systems are blown to pieces
as they state.

Either it IS,
or it is NOT.
"You can't have it both ways".

THAT is how your minds are programmed.
And THAT is the EXACT reason
"Cocal cola is good"
"works".

And you don't even question ANY of it.
You simply accept it
and eat it yammy yam yammy,
gimme more of that.

But what IS coca cola?
Well, about 97% water, hopefully clean,
some artificial nukelar sugar,
some coloring,
and a few chemicals
to stimulate those buds on your tongue.

How can it POSSIBLY be good?
And it costs nearly the same as a natural fruit juice.
And THAT is the puppet world you live in.

Tell me, how many empty coke/pepsi cans
do you have near your puter's desk?

Because I have seen people, making the LITERAL
towers in their offices out of empty coke cans.
It is like a religious ceremony.
All the labels are facing you,
all nicely stacked in geometric structures.

All 5000 of them!

There isn't even a place for a book shelf!

:---}

Well...

In case of trouble,
call Terminator()
Guaranteed to woik,

oik,




oik,











oik,
























oik.




























oik,






















oik...

ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

Oh, thanks God,
DA Terminator did its thing.

Zee ya.

 

[Lew]

The /ad hominem/ attack does not go far to support your point.

Kindly describe what constitutes java [sic] as such
and what makes it fundamentally different.

What constitutes Java as such is the Java Language Specification:
<http://java.sun.com/docs/books/jls/index.html>

Thanks, not interested at the moment.

But, but ... you asked for it.

You mean GC is wired into the very language spec?

Yes. Well, actually, into the JVM spec, but Java is predicated on running on
the JVM. That is why it does not have destructors.

And what am I seeing here in just about any code exaple?

Not templates.

Well, generics, that are only recently introduced.

Still not templates.

Is is something fundamental?
Yes.

I, personally like the idea of preprocessor.
First of all, you are not forced to use it,

Have you seen any non-trivial C/C++ program without #include?

and, by its very name, it implies that it is not
part of a language proper. It simply goes though
your source files and does a string substitutions,
and, after it is done, the compliler proper does its job.

It is a part of the language, albeit not "proper".

Huh?
What I am seeing with java is that very iviory-tower
images all over the place, going to the point of mouth
foaming lunacy with all this upper/lower case issue,

The /ad hominem/ attack does not go far to support your point.

The culture may seem "ivory tower" in newsgroups, but the proffering of idioms
and theoretical underpinnings is pragmatically motivated. In the workaday
world of creating commercial systems, I have never encountered an argument
over whether Java should support closures, for example.

And the "foaming lunacy" to which you colorfully allude is simply the
suggestion that the conventions are useful.

and, to this moment, nobody presented an argument
on why in the world it is so important of an issue?

It is not if you will it not. Conventions exist to make life easier between
people. You are certainly free to violate the convention and incur the extra
effort. (A pragmatic concern.)

Do you understand the meaning of some label if it is
ALL written in lower case? Or meaning somehow magically
evaporates?

Case does not in most cases contribute mightily to semantics per se, but the
use of conventional case and other conventions in source does help human
communication.

But this is not a matter of differences between C++ and Java.

I have my own way of looking at things
and I could care less who thinks what about it
and whether THEIR eyes get ripped appart because of
the most innocent things imaginable, such as starting
method names in lower case. But why?

Huh? "eyes"? "ripped apart"?

Cannot answer "why" because the premise is flawed.

- (voice from above) This is just a convention.
You MUST follow it.
Otherwise, the ivory-tower java priests
are not going to talk to you,
as they'll INEVITABLY consider you
as some "unswivilized" entity,
and their minds are programmed
to consider such entities
as non Aryan, and, therefore, filth of human race,
to be exterminated at all cost,
to purify the blood of mankind.

Funny, ain't it.

The /ad hominem/ attack does not go far to support your point.

You, just about the highest priest I have seen
around here, are talking about IVORY TOWERS?
While sitting on that very ivory tower
and making all the ivory tower proclamations
as to the very nature of things?

The /ad hominem/ attack does not go far to support your point.

According to what kind of monkey logic?

The /ad hominem/ attack does not go far to support your point.

I bet you can't even read my post without
your blood temperature raising to the point
of boiling. Just of this stupid lil capitalization
issue, not even worth a minute to be even mentioned.

The /ad hominem/ attack does not go far to support your point.

And what have you made of it?
Just about the BIGGEST difference between C, C++ and Java?

I lost your antecedent here. Are you referring to source-code conventions? I
did not mention those as being part of the difference between these languages.

Well, that is about the extent of it all.

But, strangely enough, you did not mention the very
JVM idea and never commented on that other post
where I asked what is so fundamentally different
between JVM and a P code idea of Pascal?

I wasn't answering that post, I was answering a different one.

So far, the differences you mentioned do not look like
something fundamental in nature. Some of it could be
simply added as libraries to C/C++ without even winking
an eye.

The definition of "fundamental" is at issue. I accept yours; ultimately there
is no "fundamental" difference between Java and assembly language.

You see, at the end, you'll still rely on underlying
operating system for memory management, file system
operations, threads and all the other MAJOR mechanisms
and concepts.

And this is relevant because ...

I am not here to argue Java is "bad" and C++ is "good".
Because I am not a priest on the first place.
I do not operate using the fascist black and white model
of the world.

To me, life force is a rainbow, where it is literally
impossible to distinguish one color from the next one
in spectrum.

And yet blue and yellow are still different, perhaps even "fundamentally" in
some sense. And yet similar, perhaps simultaneously "fundamentally" so, in
some sense.

Just about ALL you can come up with, is
fracturization and compartmentation of life force,
trying to dissect the Infinite Intelligence and
place it into nice lil boxes
with labels,
such as
"Coca Cola is GOOD. DRINK Coca Cola!"

What? Huh? How did we wind up talking about theology and Coca-Cola (r)? Not
that I don't see the connection between them, but to this discussion?

And not only it is a rainbow, undivisible,
but MULTI-DIMENSIONAL one at that.

You comprehende?

I understand the words, but not the relevance.

Existence is a MULTI-DIMENSIONAL reality.
There exists no central point,
from which all is to be defined or seen.

I would say rather that there exists an uncountably infinite set of such points.

You can look at it from just about any point
in this Infinite, multi-dimensional structure,
and no specific point of view
can possibly be classified as valid,
as they are ALL vaild.

At the level of heat death of the universe, we are all just low-level infrared
radiation. Distinctions occur at a lower level.

It is just a matter of different point of view.

"Just"? IF you got hit by a bus, would your point of view extend your mortality?

I do not wish to waste my royal time
on teaching you the most basic stuff there is,
the stuff of LIFE itself.

Good. I would question your chops to do so.

My /ad hominem/ attack does not go far to support my point.

You just keep walking wherever you wish to walk.
But when you cross my path,
beware.
You'll have to put aside all your rigid assumptions
and "constraints" of all kinds and be ready to
deal with RAW energy, and not your puppet world
in a shadow theatre,
where your strings are pulled
and you jump like a bunch of puppets.

What? How is this remotely sensible? I think you left out a few steps of the
syllogism, but perhaps I am simply unable to see how this relates to the
differences between Java and C++.

As you will be exposed to all 5 fire signs

There are only three in Western astrology: Aries, Leo and Sagittarius.

and not tripple armor will help.
Trust me.

What will be left of you
isn't even worth mentioning,
and I am giving you a BIG favor
by telling you that.

Cause I am a destructor of those ivory tower sitting
priests of your kind.

Are you threatening me?

Should we take this outside?

You see, in C++ they have a concept of destructor,
which I personally like. Because, first of all,
you are not forced to put anything to it,
but when it is hit in run time,
you are GUARANTEED that certain rules apply now,
as as soon as you exit it,
just forget about that object.

So, in my main Processor class,
i have a routine --}) called
Terminator.

Now, it is legal to call Terminator from just
about any place in the program conceivable,
and what Terminator guarantees
is that
1) Your main thread will be terminated
and terminated gracefuly.
2) Your frame will be properly disposed of.

So, if you are in a deadly situation and can not
figure out how to handle some out of the blue error,
just call the Terminator.
Guaranteed to work just fine.

Get it?

Sounds like a finally block.

Ever heard of 7 folded Truth?

Goes back about 5000 years BC.

It goes something like this:

1. It IS.
2. And it is NOT.
3. And it is BOTH.
4. And it is NEITHER.
5. And it is all of the above
6. And it is none included
(Sorry, do not remember the last one)

Actually, I really find this idea intriguing, as it resonates with many
aspects of my own philosophy. I would even say that "I do not remember the
last one" is the last one.

I still don't see the relevance to this discussion, but you have some
fascinating and intriguing idea.

But what IS coca cola?

Absolutely delicious. Far better than Pepsi-Cola.

- Lew

 

[Karl Uppiano]

Is there a way to make sure that finalization always occurs; that an
object's finalize() method is always called before program exit?
Thanks

In my 10 years of programming in Java, I have never found a need to
implement/override finalize. I think it was one of those things that seemed
like a good idea at the time, but it never really took off. There is almost
always a better design option.

 

[Lew]

In my 10 years of programming in Java, I have never found a need to
implement/override finalize. I think it was one of those things that seemed
like a good idea at the time, but it never really took off. There is almost
always a better design option.

Joshua Bloch addresses this specifically in /Effective Java/. Basically
finalize() is useful either as a safety net (just in case you forgot to close
that connection), or for things that specifically must be done prior to GC
(like releasing JNI-allocated memory).

- Lew

 

[Karl Uppiano]

Joshua Bloch addresses this specifically in /Effective Java/. Basically
finalize() is useful either as a safety net (just in case you forgot to
close that connection), or for things that specifically must be done prior
to GC (like releasing JNI-allocated memory).

- Lew

The safety net thing doesn't appeal to my sense of good programming style,
but I do understand that there are probably times when finalize is the only,
correct option, like the JNI thing you mentioned.

 

[Chris Smith]

Joshua Bloch addresses this specifically in /Effective Java/. Basically
finalize() is useful either as a safety net (just in case you forgot to close
that connection), or for things that specifically must be done prior to GC
(like releasing JNI-allocated memory).

I don't know if Bloch says it or not, but the latter should be done with
extreme caution. Better to deallocate the memory if needed, but also
log a message informing someone that there's a bug in the code. It is
not acceptable to rely solely on finalizers to deallocate native memory.

Part of the reason garbage collection works is that the JVM has specific
mechanisms in place to ensure that if there is no Java heap space
available when an application needs it, a garbage collection will run to
retrieve that space. These mechanisms are not in place for JNI-
allocated memory. Running out of native heap space will likely cause
your program to just abort unexpectedly in an unrecoverable way.

Hence, if you allocate memory from JNI, then it needs to be treated just
like any other native resource; namely, help only for as long as it is
actually used, and then actively disposed of in a proper way. Relying
on the garbage collector to collect JNI memory is equivalent to gambling
with the correctness of your program. If the Java heap doesn't fill,
then there's no guarantee that the memory will ever be freed, even as
your program dies from lack of memory.

(To make the problem worse, excessive use of finalizers is also the one
way to break Java's assurance that it will always reclaim Java heap
space in time for future allocations.)

 

[nukleus]

nukleus wrote:

Have you seen any non-trivial C/C++ program without #include?

Not yet. Why?

This is below the belt!

But you COULD write one
and it would woik too.

:--}

Hope you're not gonna ask me to write one.

main()
{
printf("Hello, Lew. How's yer project?");
}

It is a part of the language, albeit not "proper".

Jeeez, it impossible to talk to those priests.

The /ad hominem/ attack does not go far to support your point.

Yep, attacks!!!!!!

:--}

The culture may seem "ivory tower" in newsgroups, but the proffering of idioms
and theoretical underpinnings is pragmatically motivated.

I like that.
Fer breakfast.

In the workaday
world of creating commercial systems, I have never encountered an argument
over whether Java should support closures, for example.

And the "foaming lunacy" to which you colorfully allude is simply the
suggestion that the conventions are useful.

I guess so.
What ELSE could be the case?

Which issue was that again?

:--}

Stripping good, I tellya.

It is not if you will it not. Conventions exist to make life easier between
people. You are certainly free to violate the convention and incur the extra
effort. (A pragmatic concern.)

Hey, but its more fun that way.

Case does not in most cases contribute mightily to semantics per se,

Wut?
MIGHTY?
SEMANTICS?

Did yer royal CPU get locked up?

:--}

See that smiley above?

but the
use of conventional case and other conventions in source does help human
communication.

Maaaan. These conventions are about everywhere.
They are like that "display area".
Where's that rope?
Ima gonna go hang myself
if you mention this "convention" thing one more time.

:--}

See?

Ima nice feller!

But this is not a matter of differences between C++ and Java.

Well, I hope before it gets too dark,
we WILL find out what IS the difference.

Huh? "eyes"? "ripped apart"?

What?
Zomething wrong again?

Zorry.

You like "ripped off" better?
Or may be rippled thru?
Or rip it up?

Cannot answer "why" because the premise is flawed.

Nice touch.

The /ad hominem/ attack does not go far to support your point.

What "attack", sire?

The /ad hominem/ attack does not go far to support your point.

Again?

Did that CPU between your ears locked up?

The /ad hominem/ attack does not go far to support your point.

Well, its getting boring WEALLY fast here.

The /ad hominem/ attack does not go far to support your point.

Oki, doki.
Looks like a dead loop.

Zee ya.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Before you do that, i can just tell you,
it is about 90% C code and the object oriented concepts
come from C++ ideas that were ALREADY implemented
and verified to be viable.

It is actually very rare that a Java program and a C++
program doing the same is constructed similar.

Besides some basic syntax they share there are different
ways of doing things.

Kindly describe what constitutes java as such
and what makes it fundamentally different.

Try look at C++ templates and Java generics.

The syntax looks pretty similar, but when you start
working with them you find out that they must be used
very differently.

Arne