Hi Josh,
I’m a big fan of “Effective Java.” In it, you make a number of recommendations regarding the collections API. I use immutable objects to make my programs easier to reason about and thread safe. The difficulty I run into is that the collections API exposes lots of optional mutating operations. I can use the unmodifiable wrappers to prevent an internal collection from being mutated by clients of my classes, but the client still sees the optional mutating operations and can’t tell from just the interface whether a particular implementation allows mutation or will throw an exception. Does this violate the Liskov Substitution Principle? Also, I find myself making defensive copies if I want to retain a collection as a field in an object which incurs copying overhead.
Do you think Java would benefit from having a standardized functional collections library? The functional collections would be both immutable and persistent. “Immutable” in the sense that they can not be modified after they are created. “Persistent” in the sense that a collection returns a new version of itself when the client attempts to change it, and retains the current version of itself unmodified. For example, if you attempt to add an element to a collection, the return value of the “add” method is another collection containing the additional element. To avoid excessive copying overhead, structural sharing is used between the old version and the new version of the collection. The old version is garbage collected when it is no longer referenced.
Chris Okasaki has done a lot of work in this area, and his work has formed the basis of various functional collection libraries. However, the libraries are not part of the Java standard. They need to interoperate with the current collection API. Is it time to create a JEP to add a standardized functional collection library to Java?
Best Regards,
Bruce
