• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Immutable and unmodifiable difference

 
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I hope this is not a silly question, but what is the difference between immutable object and unmodifiable object. I know that immutable object state is fixed after construction. final key word can perform this function. What do you mean by unmodifiable object? I have seen in the Collections API for this.

Collections.unmodifiableCollection(Collection c)/

Please help
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The English words mean exactly the same thing. The method in Collections could be called "immutableList", I suppose.

I suspect that they used a different word to suggest a slightly different meaning: the list returned by unmodifiableList() can't be modified by any of its public methods, but it's just a wrapper around another list which could be modified; i.e.,

List first = new ArrayList();
List second = Collections.unmodifiableList(first);

No method calls on "second" can modify the list "first", but if you call set() or add() on "first", then "get()" and "size()" on "second" will return different values. So while second is "unmodifiable" using the methods of "second", it's not truly unmodifiable in an absolute sense; it's not "immutable".

Make sense?
 
Marshal
Posts: 79151
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
From reading the Collections class API, it appears that:
  • An unmodifiable List contains the same object references as were in the original List at the time of creation.
  • You can't add any more objects to the unmodifiable List, but you can add new objects to the old List.
  • You can't remove any objects from the unmodifiable List, but you can remove objects from the original List.
  • You can of course manipulate the objects themselves and change their state if they are mutable.
  • The idea is you can give access to a number of objects in a List at a particular time and users can have access to the same number of objects throughout the lifetime of the unmodifiable List.
     
    Sheriff
    Posts: 22781
    131
    Eclipse IDE Spring VI Editor Chrome Java Windows
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Basically there is no difference. Both mean that the object cannot have its state changed at all. It's just that Sun opted for unmodifiable for their utility methods instead of immutable.
     
    Ranch Hand
    Posts: 457
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    final will NOT guarantee immutability,

    all object variables are references to objects,
    final (mostly) guarantees that the reference will never point to a different object,

    when used with strings, it is certainly the intent and the case that the object does not change "ever"


    unmodifiable collection cannot guarantee the objects they contain will not change, though it is generally a bad idea to knowingly do so,
     
    Campbell Ritchie
    Marshal
    Posts: 79151
    377
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Actually I seem to have been mistaken. It returns a copy of the original List in read-only form; any changes to the original List are reflected in the copy. I wrote a little test program; if I change the size of the original by adding or removing Strings, the size of the copy changes accordingly.So it is a List whose add and remove and clear methods have all been inactivated.
     
    Ernest Friedman-Hill
    author and iconoclast
    Posts: 24207
    46
    Mac OS X Eclipse IDE Chrome
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Campbell Ritchie:
    Actually I seem to have been mistaken. It returns a copy of the original List in read-only form; any changes to the original List are reflected in the copy.



    Yep, that's what I said.
     
    Greenhorn
    Posts: 27
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi,
    How about an unmodifiable collection which allows only to add new objects but not to remove existing? :-) Or the collections allows to remove existing but not to add new objects ....
    I'm one of the developers of happy-collections framework (Apache License 2.0) and we implemented such collection, where you can change the modification strategy at run-time :-)
    The example looks like that:

    We implemented UnmodifiableCollection, -Set, -List, -Map ....
    Here you can read the article happy-collections

    :-)
    Andrej
     
    Rob Spoor
    Sheriff
    Posts: 22781
    131
    Eclipse IDE Spring VI Editor Chrome Java Windows
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Andreas Hollmann wrote:How about an unmodifiable collection which allows only to add new objects but not to remove existing? :-) Or the collections allows to remove existing but not to add new objects ....


    That's not unmodifiable, is it? That's only partly-modifiable.

    I also agree with Campbell about your posts being very close to spam. Please be careful about that.
     
    Andreas Hollmann
    Greenhorn
    Posts: 27
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Yes it is partly unmodifiable and it is very important!
    Imagine you provide an Plugin-API where developers can add new features to the features-set (Extension point). If the feature-set is protected partly with unmodifiable decorator, then the developers can only add new features to the feature-set but not remove already existing features. In that way any plugin would be protected from any unwished modification by another developer.
    This is only one example how the unmodifiable decorator of happy-collections can be used. In my opinion the partly unmodifiable collections allows a lot cleaner software-design.

    :-)
    Andrej
     
    Rob Spoor
    Sheriff
    Posts: 22781
    131
    Eclipse IDE Spring VI Editor Chrome Java Windows
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I never said it couldn't be useful. I just have problems with using the term "unmodifiable" for such classes, as they clearly aren't.
     
    Andreas Hollmann
    Greenhorn
    Posts: 27
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    maybe I should call such type of collections with another name ....
    Any suggestions?

    :-)
    Andrej
     
    Campbell Ritchie
    Marshal
    Posts: 79151
    377
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    What you are doing is not preventing mutability and modification, but restricting them. How about "partially modifiable"?
     
    Andreas Hollmann
    Greenhorn
    Posts: 27
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Campbell Ritchie wrote:...but restricting them....


    "partially modifiable" sounds good!
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic