Welcome to the Java Programming Forums


The professional, friendly Java community. 21,500 members and growing!


The Java Programming Forums are a community of Java programmers from all around the World. Our members have a wide range of skills and they all have one thing in common: A passion to learn and code Java. We invite beginner Java programmers right through to Java professionals to post here and share your knowledge. Become a part of the community, help others, expand your knowledge of Java and enjoy talking with like minded people. Registration is quick and best of all free. We look forward to meeting you.


>> REGISTER NOW TO START POSTING


Members have full access to the forums. Advertisements are removed for registered users.

Results 1 to 8 of 8

Thread: What is the rationale behind `immutableCollection` family of methods, and the advantages of the particular pattern?

  1. #1
    Junior Member
    Join Date
    Apr 2013
    Posts
    4
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Cool What is the rationale behind `immutableCollection` family of methods, and the advantages of the particular pattern?

    Hi all,

    I have recently designed and implemented a group of my own reduced set and collections interfaces and classes. It was part of school assignment, but I used the opportunity to test some experimental strategies. I know well about Java Collections, but went a bit other way with immutability - the way I understand, the immutability of Java Collections is enforced AT RUNTIME - attempting to modify a set through an "immutable view" fails with a runtime exception, but there is nothing distinguishing a modifiable collection from an unmodifiable collection at compile (application design) time. The Java Collections way is all and well but there may be disadvantages to this, or at least I think they are - for instance, the code can still include 'add' and 'remove' calls to collections one knows to be immutable by design. As it has been more or less asserted (by research) that it is of benefit to be able to discover errors as early as possible, including being able to spot an attempt to modify an immutable collection, this pushed me to approach immutability differently.

    And so I went another way with my collection framework - I have for instance an ImmutableCollection and ImmutableSet interfaces, which simply do not include any methods that modify the collection. In my project it all worked out fine, and so I wonder - what may be benefits and drawbacks of my design and the way Java designers did it?

    Mind you, I do not advocate any particular strategy here, nor imply that I am a Java expert or anything - I just want an educated opinion on the matter, I could not really find any good material on the Internet.

    I would like to be able to see patterns of application where my design is insufficient and lacking, so I can reason about my approach better.


  2. #2
    Crazy Cat Lady KevinWorkman's Avatar
    Join Date
    Oct 2010
    Location
    Washington, DC
    Posts
    5,441
    My Mood
    Hungover
    Thanks
    144
    Thanked 636 Times in 544 Posts

    Default Re: What is the rationale behind `immutableCollection` family of methods, and the advantages of the particular pattern?

    One benefit of the way Java does it is that it allows you to create unmodifiable views of your data structures, which is the whole point of the methods in the first place. If it returned some other UnmodifiableDataStructure, it would have to first copy over the Objects from the original data structure into the new one. This defeats the purpose of creating a view in the first place, as things like modifying the original data structure no longer change the view, which is how it's supposed to work.

    I do see your point, but the way Java works makes sense if you think about it. Plus, if you don't like it, you're always free to come up with your own solution involving UnmodifiableDataStructures if you want.
    Useful links: How to Ask Questions the Smart Way | Use Code Tags | Java Tutorials
    Static Void Games - Play indie games, learn from game tutorials and source code, upload your own games!

  3. #3
    Super Moderator pbrockway2's Avatar
    Join Date
    Jan 2012
    Posts
    939
    Thanks
    6
    Thanked 202 Times in 178 Posts

    Default Re: What is the rationale behind `immutableCollection` family of methods, and the advantages of the particular pattern?

    I'm not sure I follow that Kevin.

    Suppose I have a MyCollection type and an unrelated UnmodifiableMyCollection type with the same behaviour (except for anything that would modify the collection). There is nothing to stop MyCollection having some inner type that does all the UnmodifiableMyCollection stuff using the actual (modifiable) data of the MyCollection instance. MyCollection could then have a getView() method that returns an instance of the UnmodifiableMyCollection with no copying needed. The compiler would not permit any changes via the view, because the view didn't declare any mutating methods.

    ---

    @OP: Suppose I had some code that worked with sets. Ie a method that took a reference to a set as an argument. Here's the thing: suppose my method did nothing that modified the set in any way. How should I declare the method? I could declare it as taking your Set argument - because, after all it works on sets, but then I couldn't pass a reference to your UnmodifiableSet. I could declare it as taking an UnmodifiableSet, but then I couldn't pass a Set.

    I guess I'm after some way of telling the compiler "a set: modifiable or not, I don't care". Suppose I had a Set type that had no mutating methods, and a subtype ModifiableSet that did. Then I could write my method the way I want.

    ---

    I haven't really thought about this a lot. And I'm a heretic who has some doubts about strong typing anyway...

  4. #4
    Junior Member
    Join Date
    Apr 2013
    Posts
    4
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default Re: What is the rationale behind `immutableCollection` family of methods, and the advantages of the particular pattern?

    Quote Originally Posted by KevinWorkman View Post
    One benefit of the way Java does it is that it allows you to create unmodifiable views of your data structures, which is the whole point of the methods in the first place. If it returned some other UnmodifiableDataStructure, it would have to first copy over the Objects from the original data structure into the new one. This defeats the purpose of creating a view in the first place, as things like modifying the original data structure no longer change the view, which is how it's supposed to work.

    I do see your point, but the way Java works makes sense if you think about it. Plus, if you don't like it, you're always free to come up with your own solution involving UnmodifiableDataStructures if you want.
    I have views too, the difference is just that my views are unmodifiable by interface signature, while with Java Collections they are typed as Set or Collection or some other collection subclass type.

  5. #5
    Crazy Cat Lady KevinWorkman's Avatar
    Join Date
    Oct 2010
    Location
    Washington, DC
    Posts
    5,441
    My Mood
    Hungover
    Thanks
    144
    Thanked 636 Times in 544 Posts

    Default Re: What is the rationale behind `immutableCollection` family of methods, and the advantages of the particular pattern?

    Good point about the views guys, I hadn't really thought it through.

    I guess the "answer" is that the UnmodifiableDataStructure has to at least implement the Collection interface to be useful, so it can be passed into the same methods that take other Collections, as pbrockway2 mentioned already. And since the Collection interface defines the add() and remove() and other modifying functions, UnmodifiableDataStructure has to define them as well.

    Could they have designed it a different way? Absolutely, an infinite number of different ways.
    Useful links: How to Ask Questions the Smart Way | Use Code Tags | Java Tutorials
    Static Void Games - Play indie games, learn from game tutorials and source code, upload your own games!

  6. #6
    Junior Member
    Join Date
    Apr 2013
    Posts
    4
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default Re: What is the rationale behind `immutableCollection` family of methods, and the advantages of the particular pattern?

    If by Collection interface you mean a sort of collection java defines - a MODIFIABLE collection, then no - an unmodifiable data structure cannot implement a writeable data structure. It is the other way around. It's a classical problem of read-write access - you have read-only and you have read-write. The latter implies the former, but the former does NOT imply the latter.

  7. #7
    Crazy Cat Lady KevinWorkman's Avatar
    Join Date
    Oct 2010
    Location
    Washington, DC
    Posts
    5,441
    My Mood
    Hungover
    Thanks
    144
    Thanked 636 Times in 544 Posts

    Default Re: What is the rationale behind `immutableCollection` family of methods, and the advantages of the particular pattern?

    Quote Originally Posted by amn View Post
    If by Collection interface you mean a sort of collection java defines - a MODIFIABLE collection, then no - an unmodifiable data structure cannot implement a writeable data structure. It is the other way around. It's a classical problem of read-write access - you have read-only and you have read-write. The latter implies the former, but the former does NOT imply the latter.
    That might be how you think it should work, but that's not how it works in reality: the unmodifiableXYZ() functions give you either a SortedSet (which implements Collection), a SortedMap (which implements Map, which defines modifying functions), a Set (which implements Collection), a Map (again, which defines modifying functions), a List (which implements Collection), or a general Collection.

    This is so these UnmodifiableXYZ data structures can be passed into the same functions that take modifiable Collections or Maps. The writers of the language could have reorganized the Object hierarchy to include something more like what you're talking about, but the simple fact is they didn't. I understand your points, but that's simply not how it works.

    I'm not very familiar with other languages- I wonder how they handle unmodifiable data structures? Maybe there's a tradition that Java is simply sticking with rather than a conscious decision?
    Useful links: How to Ask Questions the Smart Way | Use Code Tags | Java Tutorials
    Static Void Games - Play indie games, learn from game tutorials and source code, upload your own games!

  8. #8
    Super Moderator pbrockway2's Avatar
    Join Date
    Jan 2012
    Posts
    939
    Thanks
    6
    Thanked 202 Times in 178 Posts

    Default Re: What is the rationale behind `immutableCollection` family of methods, and the advantages of the particular pattern?

    My Set interface extends UnmodifiableSet. This makes it possible for you to declare a method taking in an UnmodifiableSet, and it will accept a Set just fine.
    Yes. I think that's what I was trying to get at with a Set supertype and ModifiableSet subtype. Just with a change of names: I wouldn't call the supertype "unmodifiable" if it allows subtypes to declare mutating methods. My instinct is to call it Set ... but it's just a matter of names.

    Whatever you call them the important thing is that the supertype not declare mutating methods.

    I really don't know why the rationale behind the Java way of doing things.

Similar Threads

  1. Hibernate Advantages over JDBC
    By noorul11 in forum What's Wrong With My Code?
    Replies: 1
    Last Post: February 21st, 2013, 11:25 PM
  2. Advantages of method Overloading and Overriding
    By tcstcs in forum Java Theory & Questions
    Replies: 2
    Last Post: January 19th, 2012, 03:55 AM
  3. Regular Expression pattern - complex pattern syntax
    By SmartAndy in forum Algorithms & Recursion
    Replies: 3
    Last Post: June 7th, 2011, 04:40 AM

Tags for this Thread