A Java Brainteaser - a Static Factory method Narrative

R

Rich MacDonald

Bingo - best answer. Let's repeat it, *The keyword static means
seen said in a technical discussion.

Never could have guessed that was what was hanging you up. Prior language
hangover? Yeah, I've just been reading this thinking "this is obvious, he
can't be serious, but he needs a shakeout, so go with the flow."

With my Smalltalk background, a static method is just another place where
things can happen ---> the *same* happenings that all methods follow. Is an
object created? Does something point to it when the method is complete?
Then it follows the same rules as always. Nothing to it. Don't
overcomplicate the thought process.
http://java.sun.com/docs/books/performance/1st_edition/html/JPAppGC.fm.h
Thanks. Yeah I read a lot but it's overwhwelming and everything gets
dated very quickly. I had not run across this before and being someone
who likes OO programming I don't look for workarounds - hence a
blindspot with this subject.

Although an aside at this point, the object reference nullifying is a
workaround, and hopefully an old wive's tale that's no longer relevant.
 
T

Tony Morris

Tor Iver Wilhelmsen said:
Since a lot of programmers disagree with you (ie. they think that
constructors can be non-private), calling it a "fundamental fact"
makes you look like an arrogant snob.

Perhaps so, but I have no qualms with that - the truth is of far more
importance than mere ego attacks.
Copernicus looked like one of those too, before the Earth orbitted the Sun.

--
Tony Morris
Software Engineer, IBM Australia.
BInfTech, SCJP 1.4, SCJP 5.0, SCJD

http://www.jtiger.org/ JTiger Unit Test Framework for Java
http://qa.jtiger.org/ Java Q&A (FAQ, Trivia)
http://xdweb.net/~dibblego/
 
T

Tony Morris

Joona I Palaste said:
Tony Morris <[email protected]> scribbled the following


I'd love to see that book of yours. I know something about Java, but I
can't think of any useful way to create new objects in Java without using
non-private constructors at some point. Unless you want to use the
static factory pattern in *every* class, which I find ugly.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"I am lying."
- Anon

The book is currently a set of scribble notes in a A4 pad.
I make no promises, but I do beg of you, please think about it some more -
it is blatantly obvious to any "practising purist".
That is to say, ask anyone else who is also part of this minority group and
they might provide a peek into the persecptive I speak of.
I dare not for fear of undermining the entire point, hence I intend
(actually, I 'hope') to cover it in full some day.
An example of undermining the points is the article written by Holub titled
'Why extends is evil'.
Any practising purist also knows that concrete inheritance implies a flawed
design (yes, always), but Holub makes the point in a horrible way.
I have refuted this article in somewhat minor detail (again, due to the
aforementioned apprehension) here:
http://www.jtiger.org/articles/why-extends-is-not-evil.html

--
Tony Morris
Software Engineer, IBM Australia.
BInfTech, SCJP 1.4, SCJP 5.0, SCJD

http://www.jtiger.org/ JTiger Unit Test Framework for Java
http://qa.jtiger.org/ Java Q&A (FAQ, Trivia)
http://xdweb.net/~dibblego/
 
R

Ross Bamford

The book is currently a set of scribble notes in a A4 pad.
I make no promises, but I do beg of you, please think about it some more -
it is blatantly obvious to any "practising purist".
That is to say, ask anyone else who is also part of this minority group and
they might provide a peek into the persecptive I speak of.
I dare not for fear of undermining the entire point, hence I intend
(actually, I 'hope') to cover it in full some day.
An example of undermining the points is the article written by Holub titled
'Why extends is evil'.
Any practising purist also knows that concrete inheritance implies a flawed
design (yes, always), but Holub makes the point in a horrible way.
I have refuted this article in somewhat minor detail (again, due to the
aforementioned apprehension) here:
http://www.jtiger.org/articles/why-extends-is-not-evil.html

Nice one Tony :) The original /is/ somewhat inflammatory ;) Out of
interest, have a quick look at some of the dependency injection stuff
around now, which I think has the potential to remedy the situation if
used properly. Particularly with respect to implementation hiding and
encapsulation. The goal for my current project is to be based entirely
around interfaces, with implementations being dynamically registered and
selected from those available to fit the need of another.

The only thing I would say is that final classes, while preventing
concrete inheritance, also prevents lots of clever stuff like dynamic
proxy classes and stuff, which helps make the above possible. Another
solution might be to simply remove it from the language, along with
making 'extends' illegal on classes. ;)

Cheers,
Ross
 
J

John C. Bollinger

Tony said:
This is the correct way to expose construction of objects.
Non-private constructors violate encapsulation.
If only this very fundamental, simple and obvious concept was taught from
the beginning.

This assertion is certainly simple to _express_, but it's correctness is
not obvious, at least to me. That being the case, I sincerely doubt
whether it is simple to explain or justify.
Book containing explanation pending...

That book seems always to be pending. It's the same one, I presume,
where you are going to discuss why you say all classes should be either
abstract or final? I at least have less trouble imagining possible
arguments for that one.

Any way around, it adds nothing useful to the discussion to make
controversial assertions and then duck all attempts to engage you in any
debate about them. Appeal to the authority of a nonexistent book in no
way supports your claims. When the book appears, however, let us know.
 
T

Tony Morris

Ross Bamford said:
Nice one Tony :) The original /is/ somewhat inflammatory ;) Out of
interest, have a quick look at some of the dependency injection stuff
around now, which I think has the potential to remedy the situation if
used properly. Particularly with respect to implementation hiding and
encapsulation. The goal for my current project is to be based entirely
around interfaces, with implementations being dynamically registered and
selected from those available to fit the need of another.

The only thing I would say is that final classes, while preventing
concrete inheritance, also prevents lots of clever stuff like dynamic
proxy classes and stuff, which helps make the above possible. Another
solution might be to simply remove it from the language, along with
making 'extends' illegal on classes. ;)

Cheers,
Ross

Indeed, hence for some frameworks, such as Hibernate that use dynamic
proxying, the best I can do is declare the class non-final and declare all
methods final (including, unfortunately, those of java.lang.Object). I agree
that dependency injection is one solution, though I'm not prepared to say
that it is the solution. A language fix would solve it, and the abolishment
of extends on concrete types is certainly better than my suggested
'convention', but even so, that's a workaround and you are forever tied to
concrete inheritance (java.lang.Object). Only a breaking on reverse
compatibility will ultimately fix it (a new language perhaps?)

Here are some thoughts:
- Swing is the most difficult of APIs to write unit tests for, and it is
also the core API that has the strongest dependancy on concrete inheritance.
- Whever you cannot achieve 100% coverage of your code due to test, it is
always because of concrete inheritance. That is to say, without concrete
inheritance, you can always achieve 100% coverage. If you cannot achieve
100% coverage, then why does the code exist? The test code is, after all,
the client.
- JTiger (http://www.jtiger.org/) achieves 100% class and 100% method
coverage, however, outright 100% coverage cannot be achieved in cases where
a third party dependancy exists since concrete inheritance is used e.g. Ant
task, JavaBeans, Java exceptions (all three of these mandate concrete
inheritance directly or indirectly). In all other cases, 100% coverage is
achieved. It is in these circumstance only where a trade-off is justified
(e.g. shall I rewrite Ant/JavaBeans/the Java language properly, or concede
and use concrete inheritance and expose a constructor in my types? I chose
the latter for obvious reasons). JTiger declares all classes final (hiding
the dependancy on concrete inheritance, but not exposing it itself).

I just realised I have gone from "constructors violate encapsulation to
concrete inheritance violates encapsulation", but the two assertions are
intrinsically related.
Still, what do you mean inflammatory? What exactly?

Tony Morris
Software Engineer, IBM Australia.
BInfTech, SCJP 1.4, SCJP 5.0, SCJD

http://www.jtiger.org/ JTiger Unit Test Framework for Java
http://qa.jtiger.org/ Java Q&A (FAQ, Trivia)
http://xdweb.net/~dibblego/
 
T

Tony Morris

John C. Bollinger said:
This assertion is certainly simple to _express_, but it's correctness is
not obvious, at least to me. That being the case, I sincerely doubt
whether it is simple to explain or justify.


That book seems always to be pending. It's the same one, I presume,
where you are going to discuss why you say all classes should be either
abstract or final? I at least have less trouble imagining possible
arguments for that one.

No, always final.
Any way around, it adds nothing useful to the discussion to make
controversial assertions and then duck all attempts to engage you in any
debate about them. Appeal to the authority of a nonexistent book in no
way supports your claims. When the book appears, however, let us know.

Agreed, I try to shut up, but it slips out every now and then and goes far
beyond the intended course.
Still, I maintain that if you (or anyone) has the right to suggest that, for
example, "you should inherit from this class" on no sound basis (which I
claim does not exist even if it were attempted), I also maintain the right
to say, "no, do not inherit from this class" (on a basis that I claim exists
and I *know* exists without doubt - at least in my mind).


--
Tony Morris
Software Engineer, IBM Australia.
BInfTech, SCJP 1.4, SCJP 5.0, SCJD

http://www.jtiger.org/ JTiger Unit Test Framework for Java
http://qa.jtiger.org/ Java Q&A (FAQ, Trivia)
http://xdweb.net/~dibblego/
 
K

krasicki

Rich said:
Never could have guessed that was what was hanging you up. Prior language
hangover? Yeah, I've just been reading this thinking "this is obvious, he
can't be serious, but he needs a shakeout, so go with the flow."

No, it was not 'hanging me up' but you're missing a back story context.
The code I was evaluating came with a requirements document that was
really a narrative functional specification. And it said, more or
less, "I'm using this technique to save memory."! That completely
turned me around and ignited a search for such effect and when none was
found, then this thread.

I'm smart enough to know I may not know and dumb enough to ask. My
hunch that this had nothing to do with saving memory I think is correct
but I was unsure of the scope and effect of the static keyword on the
factory method byproducts.

With my Smalltalk background, a static method is just another place where
things can happen ---> the *same* happenings that all methods follow. Is an
object created? Does something point to it when the method is complete?
Then it follows the same rules as always. Nothing to it. Don't
overcomplicate the thought process.
http://java.sun.com/docs/books/performance/1st_edition/html/JPAppGC.fm.html

This link is a bit crusty so I looked further. Check this out;

http://today.java.net/pub/a/today/2003/12/30/staticsSQ1.html
Although an aside at this point, the object reference nullifying is a
workaround, and hopefully an old wive's tale that's no longer
relevant.

Indeed. Take a look at what some gamers think of my old wives
technique;

http://www.javaspecialists.co.za/archive/Issue060.html
 
K

krasicki

D

Dale King

Tony said:
No, always final.




Agreed, I try to shut up, but it slips out every now and then and goes far
beyond the intended course.

Well, saying that it is "obvious" when it is not obvious to those here
is not an effective way of shutting up. You basically are insulting
anyone that disagrees with you.
Still, I maintain that if you (or anyone) has the right to suggest that, for
example, "you should inherit from this class" on no sound basis (which I
claim does not exist even if it were attempted), I also maintain the right
to say, "no, do not inherit from this class" (on a basis that I claim exists
and I *know* exists without doubt - at least in my mind).

It seems to me that you have two assertions that you are trying to merge
into one and I fail to see how they are related. The assertions I see are:

- Concrete inheritance is evil
- Constructors should be private

Even if one agreed with the first one the second one does not follow
from the first. Even with no concrete inheritance you still need a way
to create concrete instances.

For the first I would agree that concrete inheritance is quite often
abused and should be used less that it is, I do not agree that it is
always evil. For one thing every class in Java uses concrete
inheritance. Every object inherits some concrete implementations from
Object.

I find very little justification for your second assertion and you have
offered none.
 
T

Tony Morris

Dale King said:
Well, saying that it is "obvious" when it is not obvious to those here
is not an effective way of shutting up. You basically are insulting
anyone that disagrees with you.

I'm assuming that the doctrine is merely being iterated as fundamental fact
without any thought.
With a completely open mind, it is obvious, at least, to me. No insult is
intended.
It seems to me that you have two assertions that you are trying to merge
into one and I fail to see how they are related. The assertions I see are:

- Concrete inheritance is evil
- Constructors should be private

Even if one agreed with the first one the second one does not follow
from the first. Even with no concrete inheritance you still need a way
to create concrete instances.

They are very much related, but again, I'm being torn between 'shutting up'
and writing a book chapter.
I dare not fall somewhere in between for fear of undermining the truth and
potentially confusing an audience.
For the first I would agree that concrete inheritance is quite often
abused and should be used less that it is, I do not agree that it is
always evil. For one thing every class in Java uses concrete
inheritance. Every object inherits some concrete implementations from
Object.

Yes, Java is intrincisally flawed. I intend to offer alternatives to
concrete inheritance, including the special case of java.lang.Object (which
ties the language spec., not just the API spec., to concrete inheritance).
The only justification for concrete inheritance is where a third party
dependancy exists - should you reimplement that dependancy (in this case,
the Java programming language) or concede to the brokenness? In cases where
you concede, I intend to provide a neat solution (isolating the brokenness).
You would concede in some cases because of a trade-off; sure, reimplementing
Java is extreme and reality is reality. It certainly pays to acknowledge
that it exists though. For the case of concrete inheritance without a third
party dependancy, there is no trade-off. You have written broken code with a
huge expense for no benefit. You may call it dogmatism; I call it a
fundamental rule - in much the say way that implementing a for loop like
this...

int x = 1000;
for(int i = 0; i < x * 10; i = i + 10){System.out.println(i / 10);}

.... is fundamentally broken compared to this:

for(int i = 0; i < 1000; i++){System.out.println(i);}

One offers a significant hit for no gain. Do you call the latter common
sense, and the former fundamentally broken? I do. The analogy is perfect,
despite all the attempts to prove it otherwise. There is also another
potential justification for concrete inheritance, but its validity is
subjective. That is, when you have unskilled people. How often have you seen
fundamental rules broken because they were misunderstood by their audience?
I see it often - it would have been better if those unskilled people were
never introduced to the fundamental rule.

I know of an example of a hashtable (which should have O(1) lookup time) has
been implemented as a list (which should have O(n) lookup and average
O(n/2)), however, it has been done such that lookup is O(n) and average
lookup is O(n). If this person were never introduced to hashtables, then
perhaps they would have used a conventional list/sequence and gained. I
think you might see why I question the validity of this argument (but it
should be presented nonetheless).
http://thedailywtf.com/forums/33738/ShowPost.aspx to see it for yourself.

I have thought about this topic (and many more related) in massive detail,
and I have spent many hours (perhaps weeks when added up?) discussing these
with people of high credibility (in fact, I'll bet you'd know of some of
them, but I care not to release their name without their permission). Please
understand that I choose not to undermine the amount of work (which is
nothing much more than verbal communication, scribble on paper and defending
my case on forums but not really defending it) by providing a 'half-arsed'
explanation. I also know that I am not on my own, because I read about
similar topics in places from others, but never to the detail that I think
it it deserves. I reserve the right to say "concrete inheritance does not
solve your problem" just as much as anyone (who I believe would be less
informed) reserves the right to say "concrete inheritance solves your
problem" without providing a sound basis for the assertion - majority vote
for concrete inheritance as a solution doesn't mean much to me. I proved
this once by asking an audience of Java developers what the difference, if
any, between a final and a constant is. 93% erroneously said no difference,
yet it's well documented in the language specification as distinct (and for
the record, I provide a practical example here
http://qa.jtiger.org/GetQAndA.action?qids=13). Although this was a somewhat
formal experiment of my hypothesis that majority vote means bugger all, I
see examples of it every day. Copernicus was right!
I find very little justification for your second assertion and you have
offered none.

I *really* should shut up now.

--
Tony Morris
Software Engineer, IBM Australia.
BInfTech, SCJP 1.4, SCJP 5.0, SCJD

http://www.jtiger.org/ JTiger Unit Test Framework for Java
http://qa.jtiger.org/ Java Q&A (FAQ, Trivia)
http://xdweb.net/~dibblego/
 
T

Tony Morris

krasicki said:

At first glance, that looks to me like the strategy design pattern
reiteratively re-explained explained again.
This is related to the fundamental rule that the use of Java switch/case can
never be justified (no, not even in 1.5) :) Should I shut up or give reasons
why I don't want to justify that too? The article provides a half-arsed
explanation - the audience should get the gist.

--
Tony Morris
Software Engineer, IBM Australia.
BInfTech, SCJP 1.4, SCJP 5.0, SCJD

http://www.jtiger.org/ JTiger Unit Test Framework for Java
http://qa.jtiger.org/ Java Q&A (FAQ, Trivia)
http://xdweb.net/~dibblego/
 
L

Laurent Bossavit

Tony,
I choose not to undermine the amount of work (which is
nothing much more than verbal communication, scribble on paper and defending
my case on forums but not really defending it) by providing a 'half-arsed'
explanation.

A flawed strategy, unfortunately. It's more likely that you are
undermining the work by *not* providing more bad explanations.

Laurent
 
L

Lee Fesperman

--- retained for reasons explained below ---
- Whever you cannot achieve 100% coverage of your code due to test, it is
always because of concrete inheritance. That is to say, without concrete
inheritance, you can always achieve 100% coverage. If you cannot achieve
100% coverage, then why does the code exist? The test code is, after all,
the client.

I can't believe you're claiming that one can have 100% test coverage except for the most
trivial of applications. Then, you claim that concrete inheritance is the only reason
100% can't be achieved. What about multithreading, customer input, GUI complications?
- JTiger (http://www.jtiger.org/) achieves 100% class and 100% method
coverage, however, outright 100% coverage cannot be achieved in cases where
a third party dependancy exists since concrete inheritance is used e.g. Ant
task, JavaBeans, Java exceptions (all three of these mandate concrete
inheritance directly or indirectly). In all other cases, 100% coverage is
achieved. It is in these circumstance only where a trade-off is justified
(e.g. shall I rewrite Ant/JavaBeans/the Java language properly, or concede
and use concrete inheritance and expose a constructor in my types? I chose
the latter for obvious reasons). JTiger declares all classes final (hiding
the dependancy on concrete inheritance, but not exposing it itself).

Oh, now I see, you're touting unit test software. I think everyone will need to take
your pronouncements with a grain of salt.
I just realised I have gone from "constructors violate encapsulation to
concrete inheritance violates encapsulation", but the two assertions are
intrinsically related.
Still, what do you mean inflammatory? What exactly?

While there is some general agreement that concrete inheritance can be problematic, you
seem to be the only one claiming it is always wrong. I'm afraid your supporting comments
on that tack are vague. Get off your soapbox and write your book ;^)

BTW, you've also fallen back into bad quoting style. Please trim signatures when you
quote, please.
 
R

Rich MacDonald

Tony Morris said:
I don't understand that logic; can you elaborate?

Better to establish one's foolishness than let it fill a vacuum.

Its not like people are going to give you credit for finding a marvelous
proof but not having sufficient space in the margins to write it down.
 
D

Dale King

Tony said:
I don't understand that logic; can you elaborate?

You are starting to sound like a kook. If you make statements that
disagree with conventional wisdom and don't provide anything to back
them up and claim that the conclusions are obvious to anyone then people
will think there really is nothing to back them up and that you don't
have any idea what you are talking about and won't take you seriously.

By the way coincidentally, the day of this conversation was I taking a
serious look at your JTiger API and thinking that it probably wouldn't
be too hard to hack the junit support in Eclipse into a JTiger plug-in.
But now that I read your extremist view I am not sure how seriously I
want to consider JTiger.

For the moment, I am giving you the benefit of the doubt and assuming
that you have latched onto a design principle that in general is often
true and tried to turn it into an absolute.

--
Dale King

P.S. since you don't provide an email address anywhere that I can find I
wanted to let you know that your Java trivia quiz had an error. The
question whose title was something about ice cream had the wrong answer
given. The answer says it is c and then goes on to explain why b is the
correct answer (which it is).
 
L

Laurent Bossavit

Tony,
I don't understand that logic; can you elaborate?

I'm tempted to say, it's obvious.

A "half-arsed explanation" will provide a better basis for improvement
than "verbal communication", "scribble on paper", and "defending
[your] case but not really defending it". Criticism of the half-arsed
explanation will be more valuable in arriving at an effective
explanation.

Your logic appears to be the following - I caricature deliberately -
"I'll think and talk informally about the topic for a while, then I will
produce my magnum opus which will make it clear for the masses".

The problem is that thinking and talking informally does not provide you
with any practice at writing clearly and forcefully. Your attempts at
writing the book, then, would likely fail for lack of practice.

To write effectively, you must practice writing. The nature of
"practice" is that you will produce much bad writing. If you put your
mind to it, however, you'll eventually produce some good work. Don't
*intend* to write, don't *hope* to write - write.

Laurent
 
D

Dale King

Tony said:
I'm assuming that the doctrine is merely being iterated as fundamental fact
without any thought.

I'm not sure which doctrine you are referring to.
With a completely open mind, it is obvious, at least, to me. No insult is
intended.

So now in addition to saying that they are stupid for not seeing the
obvious they are also close-minded.
They are very much related, but again, I'm being torn between 'shutting up'
and writing a book chapter.
I dare not fall somewhere in between for fear of undermining the truth and
potentially confusing an audience.

And I fail to see how they are related in any way other than that to
have concrete inheritance you have to have constructors that are at
least protected.
Yes, Java is intrincisally flawed.

More insults.
I intend to offer alternatives to
concrete inheritance, including the special case of java.lang.Object (which
ties the language spec., not just the API spec., to concrete inheritance).

Oh, I know there are alternatives. But in many cases I am sure the
"cure" will be much worse than the "illness".
The only justification for concrete inheritance is where a third party
dependancy exists - should you reimplement that dependancy (in this case,
the Java programming language) or concede to the brokenness? In cases where
you concede, I intend to provide a neat solution (isolating the brokenness).
You would concede in some cases because of a trade-off; sure, reimplementing
Java is extreme and reality is reality. It certainly pays to acknowledge
that it exists though. For the case of concrete inheritance without a third
party dependancy, there is no trade-off. You have written broken code with a
huge expense for no benefit. You may call it dogmatism; I call it a
fundamental rule - in much the say way that implementing a for loop like
this...

int x = 1000;
for(int i = 0; i < x * 10; i = i + 10){System.out.println(i / 10);}

.... is fundamentally broken compared to this:

for(int i = 0; i < 1000; i++){System.out.println(i);}

One offers a significant hit for no gain. Do you call the latter common
sense, and the former fundamentally broken?

No, I call it completely off topic.
I know of an example of a hashtable (which should have O(1) lookup time) has

More off topic. Yes people write bad code all the time. Sun often more
than others. That however has nothing to do with your assertions.

This inability to stick the topic also makes you sound more like a kook.
them, but I care not to release their name without their permission).

Now we have vague appeals to nameless authorities.
understand that I choose not to undermine the amount of work (which is
nothing much more than verbal communication, scribble on paper and defending
my case on forums but not really defending it) by providing a 'half-arsed'
explanation.

I don't see that it takes a lot of time to explain what you intend to
replace non-private constructors with? You have code in class A and need
to create a B you pretty much have 3 choices:
a) use new and the constructor
b) use a static method that creates
c) call an instance method on an object that creates it. (a factory)

All I am looking for at the moment is to know if it is b or c that you
are advocating. Judging by a look at JTiger it appears to be factories.
Factories are certainly a good design pattern, but not one that is
ALWAYS better than just calling the constructor.
I also know that I am not on my own, because I read about
similar topics in places from others, but never to the detail that I think
it it deserves.

I think because everyone else believes that often concrete inheritance
is bad and often factories are a good idea but sometimes the opposite is
true. But you seem to want to go the extra step and turn a principle
into an absolute. Engineering is not about absolutes it is about
weighing tradeoffs and knowing when to apply certain design principles
and when it is not.

Take for example your ReadOnlyArrayFactory. It only consists of a static
method that creates instances of a private nested class that implements
your ReadOnlyArray interface. I'm not sure how this is any better than
just making the nested class top level and calling a constructor. I
suppose one could argue that you are decoupling the creation of new
instances from the caller, which might let you for example to use
pooling and reuse instances without the caller needing to know that.
That is a valid reason for using a static method factory, but I don't
agree with making that an absolute. I think it is overkill here.

Also it appears that your adherence to no concrete inheritance means you
duplicate code and end up passing state around rather than make that
state part of a common base class.
I reserve the right to say "concrete inheritance does not
solve your problem" just as much as anyone (who I believe would be less
informed)

Again with the insults!
reserves the right to say "concrete inheritance solves your
problem" without providing a sound basis for the assertion

Well there are many examples where it solves the problem quite nicely.
Of course there are many examples where it was a very bad idea (e.g.
java.util.Properties is my favorite example of why concrete inheritance
is often wrong).
- majority vote
for concrete inheritance as a solution doesn't mean much to me.

And wild statements without any explantion don't mean much to me.
I proved
this once by asking an audience of Java developers what the difference, if
any, between a final and a constant is. 93% erroneously said no difference,
yet it's well documented in the language specification as distinct

Completely off topic but you can definitely count me in the 7% since you
can find a lot of past messages in the Java groups by me asking what is
a constant in relationship to Sun's coding convention of using all caps
for "constants". They provided no definition of what a "constant" is in
Java, no clear standard can be gleaned from the Java API, and they
provided no justification on why one particularly needs to know that
something is a "constant" enough to make the name less readable, nor
have I been able to glean much of any from my discussion on the subject.

See:
I *really* should shut up now.

Probably for the best since each time you open your mouth my estimation
of you seems to go down.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top