Why doesn't Integer have a setValue(int i), and is there a way of changing its value.

[natG]

The assumption is incorrect. b now points to a new object, but the TreeMap
still points to the object originally used to created the Map entry.
Remember, a *copy* of the reference contained by b was passed to the
tm.put() method (pass by value). The reference contained in b cannnot be
changed by the called method and the reference used by the called method
cannot be changed by altering b. And, since Integer is immutable, you cannot
alter the object that both these references reference either. The sort order
is maintained.

- Virgil

I stand corrected. Thank you.
By the way, on the link posted by Roedy Green, re immutables and maps, they say
that if you want to set a mutuable object within a Map, you need to first remove
it from the map, change it, and put it back. Otherwise the Map will lose it.

-nat

 

[Harald Hein]

Yes..But if you change a immutable Integer in a Map, via = new
Integer(int)... same argument.

No, to replace (you can't change) an immutable Integer in a Map, you
would have to go via the Map API, and the Map will therefore know about
the new Integer.

If you have a mutable MyInteger you can change the value without
informing the Map. All you need is to keep a reference to that mutable
MyInteger outside of the Map. So you change the value, and depending on
the implementation, also the hash of the mutable MyInteger behind the
back of the Map. Happy debugging.

 

[Harald Hein]

Now at a later time, the altered MyInteger is to be changed, the
same process as above is performed, and since the new temporary
MyInteger object equals() the modified MyInteger object in the
Collection, I will find the MyInteger I altered previously.

This depends ENTIRELY on the internal implementation of the collection
class in use. E.g. if the collection does keep the keys as a sorted
list, sorted according to their hash, and if the collection e.g.
performs a binary search to find a key, then changing the hash of a key
in the collection behind the back might break the seach entirely.

Similar, if the collection uses the following classic implementation of
a hash table, things break.

To resolve hash collisions, each element in the hash table is not just
a key/value pair, but a list of key/value pairs, where each key in such
a list happens to have the same hash. To find a value in such a hash
the search method first looks up the correct list by using the hash,
and then searching the found list (comparing the keys, not the hashes)
to find the desired value.

If you now change the key and hash of such an entry behind the back of
the collection, the entry is suddenly in the wrong list. If you look up
such a value, the first step will give you another list. Since the
changed entry hasn't been magically moved to this other list, you will
not find your data.

Since you really don't know how your collection is implemented, and
implementations can change between versions and might be different
between VMs, I would never take such a risk in programming.

 

[Michael Borgwardt]

Another important safety feature of immutable objects is that there are no problems
with multiple threads accessing them simultaneously.

 

[Michael Borgwardt]

By the way, on the link posted by Roedy Green, re immutables and maps, they say
that if you want to set a mutuable object within a Map, you need to first remove
it from the map, change it, and put it back. Otherwise the Map will lose it.

"lose" is the wrong word. It will **** up the map's internal structure. It will still
be in there but not accessible, and it may cause other entries in the Map to be
inaccessible as well.

This of course only applies to keys. The values are unproblematic in that regard.

 

[Brian Palmer]

Yes, top-posting is bad "netiquette".

So is quoting too much without trimming. (Picking an example, oh,
entirely at random, I removed 51 lines from your post to respond to
the one original line you had inserted).

 

[natG]

"lose" is the wrong word. It will **** up the map's internal structure. It will

still

be in there but not accessible, and it may cause other entries in the Map to be
inaccessible as well.

This of course only applies to keys. The values are unproblematic in that

regard.

Good point to remember.
-nat

 

[natG]

So is quoting too much without trimming. (Picking an example, oh,
entirely at random, I removed 51 lines from your post to respond to
the one original line you had inserted).

When trimming, does netiquette protocol require informing that the quoted material
was trimmed?
Thanks.

 

[Joseph Dionne]

:




This depends ENTIRELY on the internal implementation of the collection
class in use. E.g. if the collection does keep the keys as a sorted
list, sorted according to their hash, and if the collection e.g.
performs a binary search to find a key, then changing the hash of a key
in the collection behind the back might break the seach entirely.

Agreed, managing a sorted Collection of Integers will require additional
handling. However, the OP was speaking specifically of Integer, which
uses the value as the key and value, i.e. the hashCode is the value.
Since we want to change one Integer value, one would need to brute force
find it in a HashSet, my example, which is uses the hashCode() of each
object for comparison.

If the OP needs a sorted Collections, a custom Collection needs to be
created as well as MyInteger. But, that's why we get the big bucks!

[ snip ]

 

[Doug Pardee]

I do not understand however, the paragraph you
wrote regarding aliasable and mutuable.

I probably should have used the less technical term 'sharable' instead
of 'aliasable'. I shall do that here.

If an object is both mutable and sharable, then it must be understood
by all of the code that uses the object that the object's value is
unstable; it might be affected by other code elsewhere. If the object
is shared between threads, the object's value might change even in the
middle of a statement that is using it, such that "i.equals(i)" cannot
even be guaranteed to be true.

When we work with values, we expect them to hold still. There are two
ways of guaranteeing this. Either we make value objects unsharable, or
we make them unchangeable.

It is okay to change unshared objects; for instance, there is no way
that changing the value of an int variable can possibly affect the
value of any other int variable, because ints are always copied and
never shared.

So, if we have:
int j = 2;
someScaryObject.someScaryMethod(j);
if (j == 2)
[do something]
we can be assured that the 'if' will ALWAYS be true because we only
share *copies* of the value of j. The variable itself is never shared.
The only way that the value of j will change is if we change it
ourselves.

Similarly, it is okay to share immutable objects; there is no way that
changing a String variable can possibly affect the value of any other
String variable, because you can't change the String variable in the
first place.

So, if we have:
String s = "Hello world";
someScaryObject.someScaryMethod(s);
if (s.equals("Hello world"))
[do something]
we can be assured that the 'if' will ALWAYS be true no matter who we
share the object referenced by s with, because there is no way that
anyone can mess with the value of the String object that s references.
The only way that the value of s will change is if we change it
ourselves.

Let's see if I can make a passable example as to why this is
important...

Consider a bank Account, which has a balance of type Money:
public class Account {
public Money balance;
}

[in some method somewhere]
Account acct = [get Account object from somewhere]
Money oldBalance = acct.balance;
doSomething(acct);
if (acct.balance.equals(oldBalance)
[do some interesting stuff]

When we get to the 'if' statement, we assume that the variable 'acct'
still points to the same Account object, and that it contains the
LATEST account balance. On the other hand, we assume that 'oldBalance'
contains the ORIGINAL account balance. We are assuming that if the
balance is updated, the Account object is changed but the Money object
is not.

Money is a value type; Account is not. The rules (semantics) for them
are fundamentally different.

 

[Dale King]

Agreed. I put it this way. Java does NOT restrict a class which implements
Comparable from using setters to change its key, neither is there a rule by
convention. If so, why are the wrappers different? But there are other
answers/reasons pointed out elsewhere in this thread, and am satisfied with
those. Very much so.

The wrappers are different because if you want a mutable version it is
trivial to roll your own (and if you are even too lazy for that there are
mutable wrappers in the CORBA stuff). A mutable version of Integer is
simply:

class MutableInteger
{
public int value;
}

 

[Brian Palmer]

When trimming, does netiquette protocol require informing that the
quoted material was trimmed?

Only if it's not clear from context, I'd say. The quoted material
isn't serving the function of a quotation in a newspaper article; it's
serving to indicate to people what the parent post was about, and to
serve as a jumping off point for the current article.

 

[Roedy Green]

When trimming, does netiquette protocol require informing that the quoted material
was trimmed?

I think it is silly to do so. You are supposed to trim anything
irrelevant to your commentary. 99% of the time you should be trimming
something. People APOLOGISE for trimming irrelevancy. Gurgle!

I run into people who complain when I trim anything from their posts
no matter how irrelevant it is to my comment, calling it "censorship",
but not here in comp.lang.java.*.

 

[bagbourne]

Question: Suppose:
Integer a = new Integer(10);
Integer b = new Integer(20);
Integer c = new Integer(30);
TreeMap tm = new TreeMap();
tm.put(a);
tm.put(b);
tm.put(c);
And then:
b = new Integer(60);
Now, I assume that the second Integer added to the Map, will return an int value
of 60.
If so, what happens to the sort at that point?

You have a fundamental misunderstanding. I'm surprised nobody picked up
on this. You sent a reference to an Integer object (stored in varable
named "b") to TreeMap.put(). It stored that reference.

Then you create a *totally new instance* of an Integer with 60 in it,
and put a reference to that object into variable b.

That has nothing to do with the reference that you previously put into
the TreeMap.

If it helps, think of object variables as smart pointers that cannot be
corrupted to point to anything else other than what they were declared as.

When you assign using "=", you just change the variable to *reference*
that new object.

 

[Joona I Palaste]

On Fri, 19 Dec 2003 15:19:22 GMT, "natG"
I run into people who complain when I trim anything from their posts
no matter how irrelevant it is to my comment, calling it "censorship",
but not here in comp.lang.java.*.

It's not censorship, because you are not altering the contents of
*THEIR* message, you're altering the contents of *YOUR* message, which
includes part of theirs. Their original message is still plainly visible
preceding yours.
If you were an administrator of your own news server, and hacked its
article database to alter others' articles, *THEN* it would be
censorship. Merely not quoting something someone else said isn't.
(Otherwise I would be one heck of a censor - I can think of at least a
couple of thousand Usenet posters I've not quoted...)

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"'So called' means: 'There is a long explanation for this, but I have no
time to explain it here.'"
- JIPsoft

 

[Harald Hein]

If you were an administrator of your own news server, and hacked its
article database to alter others' articles, *THEN* it would be
censorship.

Not even then. It would be unethical, an immoral, it would maybe
(IANAL) violate a bunch of laws (interference with telecomunication,
copyright, altering of electronic data), but it would not be
censorship. Censorship is by definition

- the act of a government(!) or someone acting on behalve of
a government(!)

- of checking publications, theatre plays, movies, music, and
other works of art

- if they or parts of them violate some moral, political, religious
or other defined or implied standards or codes, and

- and the government prohibit publication, performance,
distribution of parts of the work or the work in total.

Non of this applies to newsgroup postings.

Ironically, usually the ones who cry "frea speach" and censorship first
are also the ones who simply don't understand the definition. Watch
this thread for a bunch of "frea speach" apologist who will try to
explain to you that even trying to prevent someone from farting in your
living room is censorship.

 

[Thomas Schodt]

... "frea speach" ...

Freedom to spell anyway we want, "phreeky" ^_^

 

[Joona I Palaste]

Not even then. It would be unethical, an immoral, it would maybe
(IANAL) violate a bunch of laws (interference with telecomunication,
copyright, altering of electronic data), but it would not be
censorship. Censorship is by definition

(snip) (not censored, though)

Non of this applies to newsgroup postings.

Ironically, usually the ones who cry "frea speach" and censorship first
are also the ones who simply don't understand the definition. Watch
this thread for a bunch of "frea speach" apologist who will try to
explain to you that even trying to prevent someone from farting in your
living room is censorship.

I've found that some people understand "free speech" as "free speech for
me but not for you". They think it means "I have the right to express
my opinion, but you don't have the right to express your opinion about
my opinion". These people are usually the most vocal advocates for free
speech. And some of them cite U.S. law, blissfully ignoring the
existence of Usenet readers outside the U.S.

 

[natG]

You have a fundamental misunderstanding. I'm surprised nobody picked up
on this. You sent a reference to an Integer object (stored in varable
named "b") to TreeMap.put(). It stored that reference.

Then you create a *totally new instance* of an Integer with 60 in it,
and put a reference to that object into variable b.

That has nothing to do with the reference that you previously put into
the TreeMap.

If it helps, think of object variables as smart pointers that cannot be
corrupted to point to anything else other than what they were declared as.

When you assign using "=", you just change the variable to *reference*
that new object.

I am surprised at myself as well. It seems like that in hurry to pick an example
of changing keys in HashMap, I blinded myself.
-nat

 

[natG]

I think it is silly to do so. You are supposed to trim anything
irrelevant to your commentary. 99% of the time you should be trimming
something. People APOLOGISE for trimming irrelevancy. Gurgle!

I run into people who complain when I trim anything from their posts
no matter how irrelevant it is to my comment, calling it "censorship",
but not here in comp.lang.java.*.

In today's day and age, where [almost] every one has NewsReader software that
maintains the thread anyhow, I would do away with quoting altogether.
-nat