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 9 of 9

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
    5
    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,828
    My Mood
    Hungover
    Thanks
    147
    Thanked 699 Times in 595 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.
    How to Ask Questions the Smart Way
    Static Void Games - GameDev tutorials, free Java and JavaScript hosting!
    Static Void Games forum - Come say hello!

  3. #3
    Moderators pbrockway2's Avatar
    Join Date
    Jan 2012
    Posts
    1,541
    Thanks
    10
    Thanked 284 Times in 256 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
    5
    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 think you missed the fact that my collection framework also has views, I don't copy objects from one collection onto another just to give the caller some unmodifiable interface - i give them an unmodifiable view onto the desired collection, just like Java Collection Framework (JCF) does.

    The difference between my approach and JCF is that JCF returns a view which is typed as the same interface as a writable collection - i.e. the unmodifiableCollection method returns a Collection with the read-only property of the view being enforced at runtime by having inappropriate access methods throw runtime exceptions. I, on the other hand, return a view typed as UnmodifiableCollection which has only a subset of methods that Collection would have. I then do NOT need to enforce readonly-ness at runtime with throwing an exception - the compiler takes care of that because there are no add or remove or other methods that modify the collection in UnmodifiableCollection interface.

    --- Update ---

    Quote Originally Posted by pbrockway2 View Post
    @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.
    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. You couldn't go the other way - declaring a method parameter as Set and pass the method an UnmodifiableSet - and that's part of the point - an unmodifiable set should not be modified, which a method that takes a Set (in other words, a ModifiableSet), intends to do.

    Methods that do not intend to modify the collections they function on, should declare the parameter as UnmodifiableCollection, is all. If these methods are later changed to modify the collection (a very rare situation, wouldn't you agree?), and this would involve changing signatures all over the place, one can attempt a runtime cast the parameter to a Set, if indeed a Set was passed for an UnmodifiableSet.

    It doesn't matter whether you mean a modifiable set by Set and unmodifiable set by UnmodifiableSet, or modifiable set by ModifiableSet and unmodifiable set by Set - you still have to establish functioning and reasonable relationships between these interfaces. I, just as with JCF, imply a modifiable set with the Set interface, and unmodifiable set with ImmutableSet as I named it, and the former extends the latter because well, the name should really be ReadSet and ReadWriteSet, and a ReadWriteSet extends a ReadSet wouldn't it?

  5. #5
    Junior Member
    Join Date
    Apr 2013
    Posts
    5
    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.

  6. #6
    Crazy Cat Lady KevinWorkman's Avatar
    Join Date
    Oct 2010
    Location
    Washington, DC
    Posts
    5,828
    My Mood
    Hungover
    Thanks
    147
    Thanked 699 Times in 595 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.
    How to Ask Questions the Smart Way
    Static Void Games - GameDev tutorials, free Java and JavaScript hosting!
    Static Void Games forum - Come say hello!

  7. #7
    Junior Member
    Join Date
    Apr 2013
    Posts
    5
    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.

  8. #8
    Crazy Cat Lady KevinWorkman's Avatar
    Join Date
    Oct 2010
    Location
    Washington, DC
    Posts
    5,828
    My Mood
    Hungover
    Thanks
    147
    Thanked 699 Times in 595 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?
    How to Ask Questions the Smart Way
    Static Void Games - GameDev tutorials, free Java and JavaScript hosting!
    Static Void Games forum - Come say hello!

  9. #9
    Moderators pbrockway2's Avatar
    Join Date
    Jan 2012
    Posts
    1,541
    Thanks
    10
    Thanked 284 Times in 256 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 22nd, 2013, 12:25 AM
  2. Advantages of method Overloading and Overriding
    By tcstcs in forum Java Theory & Questions
    Replies: 2
    Last Post: January 19th, 2012, 04:55 AM
  3. Regular Expression pattern - complex pattern syntax
    By SmartAndy in forum Algorithms & Recursion
    Replies: 3
    Last Post: June 7th, 2011, 05:40 AM

Tags for this Thread