immutability

I can't see the reason why the Boolean wrapper classes were made Immutable. Why the Boolean Wrapper was not implemented like MutableBoolean in Commons lang which actually can be reset. Does anyone have any idea/understanding about this ? Thanks. Because 2 is 2. It won't be 3 tomorrow. Immutable is always preferred as the default, especially in multithreaded situations, and it makes for easier to read and more maintainable code. Case in point: the Java Date API, which is riddled with design flaws. If Date were immutable the API would be very streamlined. I would know Date operations would

I've been using Python for some time already and today while reading the following code snippet: >>> a = (1,2) >>> a += (3,4) >>> a (1, 2, 3, 4) I asked myself a question: how come python tuples are immutable and I can use an += operator on them (or, more generally, why can I modify a tuple)? And I couldn't answer myself. I get the idea of immutability, and, although they're not as popular as lists, tuples are useful in python. But being immutable and being able to modify length seems contradictory to me... 5 is immutable, too. When you have an immutable data structure, a += b is equivalent to

I have a project where I need to construct a fair amount of configuration data before I can execute a process. During the configuration stage, it's very convenient to have the data as mutable. However, once configuration has been completed, I'd like to pass an immutable view of that data to the functional process, as that process will rely on configuration immutability for many of its computations (for instance, the ability to pre-compute things based on initial configuration.) I've come up with a possible solution using interfaces to expose a read-only view, but I'd like to know if anybody

I have been using guava for some time now and truly trusted it, until I stumbled of an example yesterday, which got me thinking. Long story short, here it is: public static void testGuavaImmutability(){ StringBuilder stringBuilder = new StringBuilder("partOne"); ImmutableList<StringBuilder> myList = ImmutableList.of(stringBuilder); System.out.println(myList.get(0)); stringBuilder.append("appended"); System.out.println(myList.get(0)); } After running this you can see that the value of an entry inside an ImmutableList has changed. If two threads were involved here, one could happen to not see

Strings are immutable, meaning, once they have been created they cannot be changed. So, does this mean that it would take more memory if you append things with += than if you created a StringBuffer and appended text to that? If you use +=, you would create a new 'object' each time that has to be saved in the memory, wouldn't you? Yes, you will create a new object each time with +=. That doesn't mean it's always the wrong thing to do, however. It depends whether you want that value as a string, or whether you're just going to use it to build the string up further. If you actually want the

Is there an easy way to make an instance immutable? Let's do an example, I have a class holding a lots of data fields (only data, no behavior): class MyObject { // lots of fields painful to initialize all at once // so we make fields mutable : public String Title { get; set; } public String Author { get; set; } // ... } Example of creation: MyObject CreationExample(String someParameters) { var obj = new MyObject { Title = "foo" // lots of fields initialization }; // even more fields initialization obj.Author = "bar"; return obj; } But now that I have fully created my object, I don't want the