impl a collection

[NOBODY]

The original statement was generalised - the topic of this forum is
Java so it was assumed that the statement was related to Java, in
which case, it is incorrect.

Is there a particular VM implementation that behaves in that fashion?
No VM implementation that I am looking at causes that statement to
become true (even after being given a context).

I looked at sun's jdk 1.4.2.
Source code show it.
Real time debugging shows it.
Test yourself and you will see it.
Now this is with string buffer. But you may take the string out of the
string buffer and call substring(0, 1), and you will see that you cannot
create more strings, they are still holding the char[] underneath.



import java.util.LinkedList;

public class TestStringBufferToStringHeapCost {

public static void main(String[] args) {
LinkedList ll;
int i = 0;

try {
ll = new LinkedList();
i = 0;
while(true) {
StringBuffer sb = new StringBuffer(100);
sb.append('x');
ll.add(sb.toString());
i++;
if(i%1000 == 0) {
//System.out.println(i);
System.out.print('.');
System.gc();
}
}
} catch(OutOfMemoryError e) {
ll = null;
e.printStackTrace();
} finally {
ll = null;
System.err.println(i);
}


try {
ll = new LinkedList();
i = 0;
while(true) {
StringBuffer sb = new StringBuffer(10000);
sb.append('x');
ll.add(sb.toString());
i++;
if(i%10 == 0) {
//System.out.println(i);
System.out.print('.');
System.gc();
}
}
} catch(OutOfMemoryError e) {
ll = null;
e.printStackTrace();
} finally {
ll = null;
System.err.println(i);
}

}
}

/* because of:

public String (StringBuffer buffer) {
synchronized(buffer) {
buffer.setShared();
this.value = buffer.getValue(); //THIS!!!!!!!!!!!!!!
this.offset = 0;
this.count = buffer.length();
}
}
*/

 

[NOBODY]

That's a bit of a misnomer. Nothing is changed. All you do is make an
immutable copy of part of the original String.

What you are doing I called "unencumbering" the string.

(Just for people reading it
I corrected myself later on:

new String(substring_inside_the_line.getChars())

hope this clarifies.

 

[Chris Smith]

I looked at sun's jdk 1.4.2.
Source code show it.
Real time debugging shows it.
Test yourself and you will see it.

You're misunderstanding Tony here. Tony doesn't mean that Sun's
implementation of Java acts any differently from what's being discussed.
He doesn't even mean that the language or API specs contradict that
implementation (though I could see how you could interpret his words
that way; especially when he says that the behavior is "incorrect" for
the Java language). Tony only means that neither the language nor API
specs *require* this implementation. He's right about that, although in
the larger scheme of things it is obviously implied by the general API
design, and I know of no one who has implemented the core API without
providing that behavior.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Roedy Green]

When you will be forced to buy a special motherboard that is not limited
to 1.5 gig ram, you will understand.

I hear you and I don't understand why you should blanket "not use
arrays" as the OP commanded. What alterative is there? Arrays are the
most efficient ways to store data in Java.

The overhead he was worried about is one of the most insignificant
factors in RAM usage.

 

[NOBODY]

Listen Roedy,

It's not small overhead when the guy's case is to use an array of two
elements for a double value map entry!!!

An object with to fields is 16 bytes. An array of 2 refs is 24 bytes. That
is 150% for EACH entries in the poor guy's map...

Answering every questions in this forum won't make you non-disputable...
Don't answer just because you feel like it. Answer because you got a
certitude to share.

Thanks.

 

[Roedy Green]

It's not small overhead when the guy's case is to use an array of two
elements for a double value map entry!!!

An object with to fields is 16 bytes. An array of 2 refs is 24 bytes. That
is 150% for EACH entries in the poor guy's map...

Answering every questions in this forum won't make you non-disputable...
Don't answer just because you feel like it. Answer because you got a
certitude to share.

My complaint was with his blanket statement that you should never use
arrays.

He seemed upset over the overhead of even of ONE of such array
objects.

I checked RAM prices on eBay just before I posted. I think that counts
as as "certitude to share".

I is not the whole answer the general question, but neither is your
post. Both together give a richer answer.

 

[Roedy Green]

I is not the whole answer the general question, but neither is your
post.

Try that again.

My post was not the whole answer to the general question, but neither
was yours either.

 

[Roedy Green]

No, like so many arguments in newsgroups it is an argument over
definitions of words. If the two sides keep using different
meanings for the same words and can't agree to abide by a common
definition then continuing the discussion is pointless

I am a great believer in being extremely clear and consistent with
definitions and declarations in programming. I even created the
Abundance computer language where you do most of your coding in the
declarations. I spend most of my life trying to document and clarify
definitions with my Java glossary and other glossaries. You can't get
there with out hashing it out. What I do is a lightning rod for
criticism.

On the other paw, I think what often happens is a form of gamesmanship
-- to try to make the other fellow wrong by concocting some new
screwball definition for a word, and trying to insist that was the
definition he intended.

It is one thing to argue over the definition of a word, and quite
another to insist you know better what another intended to say.

In a newsgroup, naturally a consensus form on what certain words mean
in particular. When someone new insists on violating those
conventions, he gets others annoyed. It both sows confusion, and shows
disrespect for the those who participated in the tedious process of
coming to a consensus.

 

[Dale King]

Hello, Roedy Green !

All
common uses of the "mutable" classification -- for example, reasoning
about thread-safety, or reasoning about security managers -- are
entirely possible on the guarantee that the array is only referenced by
private members of String, and that String has no code to

modify it.

Mutable means changeable. The char[] inside a String is not
changeable, either to a new reference or to have the individual chars
of the array change. Therefore it is in the ordinary English sense
immutable.

mutable and immutable are not java keywords, so I think ordinary
English prevails. The ordinary English meaning is what matters from a
practical point of view as well.


It would be correct to say that arrays are usually mutable, but the
char[] value array inside a String is not.


This thread sounds like a philosophy or religious discussion of
argument for the sake of argument, more of a game than serious
misunderstanding. I am rapidly losing enthusiasm for it.

No, like so many arguments in newsgroups it is an argument over
definitions of words. If the two sides keep using different
meanings for the same words and can't agree to abide by a common
definition then continuing the discussion is pointless