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.