Hi Dennis, thank you for the questions.

This is an experiment looking at how a new ImmutableCollection hierarchy could be designed from scratch using the Sealed Types preview feature in the JDK. Yes, this would restrict all implementations of ImmutableCollection and prevent any user definable implementations.

That said, I doubt this could ever be an evolutionary path for ImmutableCollection in Eclipse Collections, for several reasons.

1. We will be compiling with Java 8 for quite a while, and the next upgrade for EC when it happens will likely be to Java 11.

2. Eclipse Collections separates its API and Impl in different packages and separate jar files. This feature requires interfaces to know about implementations, so I can't see how that could ever work for Eclipse Collections.

3. Eclipse Collections has been around for nine years with the ImmutableCollection hierarchy as public interfaces. It's safe to assume, someone somewhere who uses the library has already implemented these interfaces.

This ship has sailed for Eclipse Collections. We made our design decisions for ImmutableCollection a long long time ago. We wanted to provide contractually and structurally immutable collections, and did not want to prevent others from defining their own. This is a trust based model.

I still believe Java needs a Collections 2.0, so experimenting with the latest features in the JDK, which would be naturally available to a library included in the JDK, is helpful on a few fronts.

Hope this answers your questions.