A Java Brainteaser - a Static Factory method Narrative

[Tony Morris]

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).

As much as I'm sure you'd like me to, I will not concede and provide a full
explanation, despite the bitching, and the "oh I'm not going to use JTiger
now because of you! So there!".
Being the optimist I am, I will attempt to invoke thought on your behalf
again.
I acknowledge that this will attract the usual criticism, but after a while,
I will ignore it, and it will all go away.
So here goes:
When you want an int wrapped in an Integer, you called a public constructor,
which is in violation of encapsulation rules.
Ask yourself, is really a new Integer that you want, or is it an object that
wraps an int?
I understand that the untrained eye will intrinsically tie these two
concepts together and recognising the distinction will require some thought.
So really, which is it? The answer is, the latter. You don't care how you
construct, you just care that when you pass, say 7, you can back something
that is an object representing 7. You, as a client, should be abstracted
from the process of construction.
Now, I know what the cynics and people with epileptic tongues are thinking
right now, but before you say it, I offer you one more thing to think about:
Consider the following code sample:
http://qa.jtiger.org/GetQAndA.action?qids=7
Most people will get this wrong first up - at least, the 20 or so I have
seen attempt it have never got it right first go (well done if you do).
The usual response to the correct answer is "wtf?" and then that person will
read the relevant part of the JLS, then reflect and determine that it is a
somewhat hacky attempt at caching (that's my perspective - yours may differ,
but in any case, ensure you clarify the situation).
Now this is the part where you will really have to think:
Do you suppose that this would have been different if instead, an API was
exposed that "constructed an object from an int" instead of what we
currently have, which is "construct a new Integer that represents 7"? Think
about it. If you're wondering how you can achieve this, I can certainly
provide an example. Whatever the case, I am not on my own - this has been a
well known fact for a very long time, and I'm sure that those of you who
possess initiative are capable of using google to discover an alternative
explanation.
And before you (yes you) start carrying on:
mv high-horse /dev/null
mv the-bitching /dev/null
cp thought .
Book pending.

--
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/

 

[Tony Morris]

I'm not sure which doctrine you are referring to.


So now in addition to saying that they are stupid for not seeing the
obvious they are also close-minded.


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.


More insults.
inheritance).

Oh, I know there are alternatives. But in many cases I am sure the
"cure" will be much worse than the "illness".


No, I call it completely off topic.
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.


Now we have vague appeals to nameless authorities.


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 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.


Again with the insults!


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).


And wild statements without any explantion don't mean much to me.


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.

WTF are you on about?
Where are the insults? Please don't extrapolate your own context from my
words.
It is no secret that Java has many flaws - this is one of thousands.
A constant is defined in JLS 15.28 (off the top of my head - don't quote me)
Here's some fun:
http://qa.jtiger.org/GetQAndA.action?qids=13

--
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/

 

[Tony Morris]

Probably for the best since each time you open your mouth my estimation

of you seems to go down.

I am not here to provide you with an estimation of anything - so with all
due respect (if any), bugger off.

Are you making the claim that you can foresee how your software will be
used?
If not, on what basis do you decide to expose an implementation detail that
clients should never know about?
That is, suppose your clients tie themselves to a certain implementation
detail that is erroneously, such as how objects are constructed.
Do you just declare all fields, methods, classes public, ? After all,
clients will never use this and it will never change, not ever, right?
How do propose a basis for determining whether or not this detail should be
exposed?
I currently work on implementing the 1.5 spec., but before that I was in a
customer support role.
Have you ever seen what they can do to your software?

If you do claim to be able to foresee how your software will be used in any
way at all, or you do have a sound basis for predicting that future, please
go and get rich and leave us humble humans to our silly game (as I assume
you perceive it). And now that there are no absolutes, I may as well go and
do something completely retarded; after all, there are no fundamental rules
that can be broken.

// It is impossible to do anything incorrect - there are no fundamentals of
software engineering.
public class Seven
{
boolean m()
{
while(m())
{
m();
}
}
}

I'm being facetious, but I don't really enjoy it.
Please get off that horse of yours,
internet-childish-shit-whatever-you-want-to-call-it is just plain annoying.
I suspect a brain cell in your head, hence my attempt and suggestion to
communicate on an appropriate level.

--
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/

 

[Virgil Green]

Krasicki,

The larger argument is this. The static method I'm describing is
invoked for every web-based visitor. The server is rebooted every
night due to performance problems. [...] I'm trying to determine
if this static factory method might be contributing to this problem.

It's not; or rather, the sole fact that it's static is not a
sufficient or a necessary condition for this kind of problem to
arise. It's irrelevant. A thread's stack is the root of all object
references, together with static instance *variables*. The keyword
static means something different altogether for methods - unfortunate
overloading of the name. At any rate, a stack frame for a static
method is not treated differently from a stack frame of a regular
method.

I'm curious to know how you think the keyword static is different for
variables and methods. I've always taken it to mean the same thing for
both... members of a class rather than an instance of a class (or, an
object, if you will).

Anyway, I've read most of this thread and it seems that the entire point
that was missed by the OP was that objects are always created in the heap
and only references are found on the stack (flameproof suit on in case I've
oversimplified). When a static method creates an object it may retain a
reference to it only as long as any reference variables stay within scope on
the stack. There isn't any memory associated with the static method that
"grows" as new objects are created. The static method's memory could be said
to be the stack frame(s) created when the method is invoked... there are no
objects in that memory and the references in that memory go out of scope
when the stack frame is "popped" off the stack.

Anyway, oversimplification, I'm sure -- but I hope it helped rather than
hurt the discussion.

 

[Rich MacDonald]

I am not here to provide you with an estimation of anything - so with
all due respect (if any), bugger off.

You're the bugger who made the big claims and refused to justify them, all
in the same paragraph. I quite agree with Dale. You're posting to impress
yourself, and that's the only positive you're accomplishing.

Please get off that horse of yours,
internet-childish-shit-whatever-you-want-to-call-it is just plain
annoying. I suspect a brain cell in your head, hence my attempt and
suggestion to communicate on an appropriate level.

I suspect you have a small brain cell in your head too. Unfortunately its
obscured by a pompous pimple. You started it. Now you're being called out.
On the internet, sometimes one runs into smart people who won't put up with
arrogant bullshit. C'mon, you must have run into this before, surely?

 

[Rich MacDonald]

So here goes:
When you want an int wrapped in an Integer, you called a public
constructor, which is in violation of encapsulation rules.
Ask yourself, is really a new Integer that you want, or is it an
object that wraps an int? [snip] The answer is, the latter. You don't
care how you construct, you just care that when you pass, say 7, you
can back something that is an object representing 7. You, as a client,
should be abstracted from the process of construction.

Finally, you tried direct plain English and it worked. All you needed to
say.

http://qa.jtiger.org/GetQAndA.action?qids=7
Most people will get this wrong first up - at least, the 20 or so I
have seen attempt it have never got it right first go (well done if
you do). The usual response to the correct answer is "wtf?" and then
that person will read the relevant part of the JLS, then reflect and
determine that it is a somewhat hacky attempt at caching (that's my
perspective - yours may differ, but in any case, ensure you clarify
the situation).

Mine does differ: Sun screwed the pooch. Yikes that is unforgivingly
stupid. BTW, the answer to the example really addresses a different point
than yours.

Now this is the part where you will really have to
think: Do you suppose that this would have been different if instead,
an API was exposed that "constructed an object from an int" instead of
what we currently have, which is "construct a new Integer that
represents 7"? Think about it.

What's to think? That is the difference.

If you're wondering how you can achieve
this, I can certainly provide an example. Whatever the case, I am not
on my own - this has been a well known fact for a very long time ...

[needless ego aside snipped]

Yes, a well known fact for a very long time. Java took a step back there.
In Smalltalk ,classes as instances (and what that means for static
methods and object construction) was one profound idea Gosling had
insufficient balls to steal.

Here's one for you: Who says that "new Integer(7)" should return an
instance of the class Integer? Answer: A language that screwed the pooch
on constructors.

"Classes as instances" is one reason why Factories always bore me and
usually annoy me. I hope your proposal isn't going to add extra code
everywhere. Because the relevant Java warts are easily worked around, and
99.9% of the time an Integer instance is what you want anyway...unless
you're going to mix and match objects and primitives in Maps. Jeez, that
is so 'effing stupid!

 

[Dale King]

I am not here to provide you with an estimation of anything - so with all
due respect (if any), bugger off.

Apparently, you're not here to provide anything excpet some mile amusement.

Are you making the claim that you can foresee how your software will be
used?

[A bunch of meaningless grandiose questions that have absolutely nothing
to do with the point snipped]

Please get off that horse of yours,
internet-childish-shit-whatever-you-want-to-call-it is just plain annoying.
I suspect a brain cell in your head, hence my attempt and suggestion to
communicate on an appropriate level.

Nothing childish on my side. I asked some legitimate questions that you
completely ignored.

You would save yourself a lot of effort if you didn't waste so much time
avoiding talking about the subject and just talked about it.

How long would it take to just show here is how is a before example that
Tony thinks is an abomination and here is the version that Tony thinks
is nirvana?

 

[Dale King]

As much as I'm sure you'd like me to, I will not concede and provide a full
explanation, despite the bitching, and the "oh I'm not going to use JTiger
now because of you! So there!".
Being the optimist I am, I will attempt to invoke thought on your behalf
again.
I acknowledge that this will attract the usual criticism, but after a while,
I will ignore it, and it will all go away.
So here goes:
When you want an int wrapped in an Integer, you called a public constructor,
which is in violation of encapsulation rules.
Ask yourself, is really a new Integer that you want, or is it an object that
wraps an int?
I understand that the untrained eye will intrinsically tie these two
concepts together and recognising the distinction will require some thought.
So really, which is it? The answer is, the latter. You don't care how you
construct, you just care that when you pass, say 7, you can back something
that is an object representing 7. You, as a client, should be abstracted
from the process of construction.
Now, I know what the cynics and people with epileptic tongues are thinking
right now, but before you say it, I offer you one more thing to think about:
Consider the following code sample:
http://qa.jtiger.org/GetQAndA.action?qids=7
Most people will get this wrong first up - at least, the 20 or so I have
seen attempt it have never got it right first go (well done if you do).
The usual response to the correct answer is "wtf?" and then that person will
read the relevant part of the JLS, then reflect and determine that it is a
somewhat hacky attempt at caching (that's my perspective - yours may differ,
but in any case, ensure you clarify the situation).

By the way, your answer is incorrect. The correct answer response is
that either b or f are possible. It is not guaranteed either way by the
spec. The spec guarantees that -128 to 127 will be cached. 777 may or
may not be depending on the VM. While the JLS does not require it to be
cached it does not forbid it either.

Now this is the part where you will really have to think:
Do you suppose that this would have been different if instead, an API was
exposed that "constructed an object from an int" instead of what we
currently have, which is "construct a new Integer that represents 7"?

No, not really. We have the integer constructor and we have
Integer.valueOf. Apparently there is some magical third choice that is
substantially different that the others.

Think
about it. If you're wondering how you can achieve this, I can certainly
provide an example.

I'm not even sure what you are claiming "this" is.

Whatever the case, I am not on my own - this has been a
well known fact for a very long time, and I'm sure that those of you who
possess initiative are capable of using google to discover an alternative
explanation.

So now everyone is expected to solve riddles.

I'm fairly confident that this will be by last post in this thread since
I am confident that you will still refuse to carry on an intelligent
conversation regarding your claims.

 

[hawat.thufir]

Tony Morris wrote:
....

Do you suppose that this would have been different if instead, an API
was exposed that "constructed an object from an int" instead of what
we currently have, which is "construct a new Integer that
represents 7"? ....
this has been a
well known fact for a very long time

....


since it's a well known fact, far be it for me to disagree.

it's only a tiny Integer, it's not some massive object. small
immutable objects are favored over small mutable objects. I thought
this was well known, perhaps not. what's the basis for your objection
to constructing new objects?

-Thufir

 

[paul campbell]

You seem to be addressing me. Everything I've read says that the JVM
manages its own memory management.

The VM is a virtual processor executing vitual machine code in
a virtual process which follows the same basic principals of memory
managment as a real process i.e. it has seperate "areas" for executable
code, stack, heap, statics etc. Furthermore java objects and classes
and thier constituent parts are divied up into these areas in much the
same way as real code (say c++) is handled in a real process.

If you undestood this then you would understand why you are so far off
base with your reasoning about VM memory managment.

I say again that you are trying to reason from an unsound foundation
of knowledge - you are trying to understand CG behaviour without
an understanding of more fundamental concepts about how the various
aspects of objects and classes map onto diferent types of memory in
a running process (real or virtual).

I stand by that statement, you arnt going to get any further with your
understanding util you take that advice.

Paul C.