primitive data type manipulation in wrapper classes
Practice only makes habit, only perfect practice makes perfect.
Practice mindfully by doing the right things and doing things right.— Junilu
[How to Ask Questions] [How to Answer Questions]
Originally posted by Arvind Varma:
why did the wrapper classes had to be immutable? I didn't figure out what is it going to buy us...
and right back atcha: What would it buy us if they were mutable?
Regardless of other and perhaps more practical concerns, to me the immutability of the primitive wrapper classes makes perfect OO sense. If you were to make an object represent the number 1, wouldn't it make sense to be able to count on it to always remain a representation of 1?
From "Effective Java" by Joshua Bloch:
Immutable classes are easier to design, implement, and use than mutable classes. They are less prone to error and are more secure.
...
Immutable objects are simple... are inherently thread-safe; they require no synchronization... can be shared freely... make great building blocks for other objects.
Practice only makes habit, only perfect practice makes perfect.
Practice mindfully by doing the right things and doing things right.— Junilu
[How to Ask Questions] [How to Answer Questions]
In this example, we store pairs of integers and Objects in a container. The container can hold only Objects, not primitive values. So we wrap the integer in an Integer. The key is unique. The key must not change. We want the key to be immutable.
�The second purpose of wrappers is to create objects to hold values of a primitive type for generically written classes that know only how to handle Object references.�
The Java Programming Language 11.1, Arnold, Gosling, Holmes
[ March 29, 2003: Message edited by: Marlene Miller ]
�Java containers can store any value that is ultimately derived from class Object. Unfortunately, ... the primitive values, such as integers and floating point numbers, are not objects in the technical sense. Thus, primitive values cannot be stored directly in a container...�
�the solution is to provide a series of auxiliary classes that do little more than to act as a box that can hold a single primitive value. In Java these are called wrapper classes...�
An Introduction to Object-Oriented Programming 19.2.2, Timothy Budd
If an object cannot change state then it can never encounter conflicts or inconsitencies whem multiple activities attemp to change its state in incompatible ways....existing objects are never changed, but instead new ones are continously created during the course of any computation.
Immutable objects can serve as instances of simple abstract data types representing values: Integer, awt.Color , String etc. These classes serve to encapsulate values, so the identity of their instances do not matter: for instance two instance s of Color representing the same value are typically intended to be treated as equivalent. this is the reason why ADT-style classes should normally override equals and hashCode to reflect equality of abstract value.
An immutable object can also serve to represent an object in a new state by copying the fields of the old object to those in the new object that do not chage, and then adjust the fields that did changed. If the need for objects in the new state is rare or cheap copying can outweight the drawbacks of proper synchronization.
Many objects can refer to the same immutable object because they are thread-safe. We are saving space because only one object is needed.
SCJP2. Please Indent your code using UBB Code
2.1 first two sentences
2.1.1.1 first paragraph, first and third sentences
2.1.1.1 second paragraph, first, second and third sentences
Are you quoting from the second edition? Your quotes are not exactly the same as the book?
