Eclipse Collections comes with it’s personal Listing, Set, and Map implementations. These implementations lengthen the JDK Listing, Set, and Map implementations for simple interoperability. In Eclipse Collections 10.three.zero, I launched a brand new API
MapIterable.getOrDefault(). In Java eight,
Map.getOrDefault() was launched, so what makes it a brand new API for Eclipse Collections 10.three.zero? Technically, it’s new however not so new API! Take into account the code snippets beneath, previous to Eclipse Collections 10.three.zero:
As you may see within the code,
getOrDefault() accessible, nonetheless
ImmutableMap doesn’t have it. However there is no such thing as a purpose why
ImmutableMap mustn’t have this read-only API. I discovered that
MapIterable already had
getIfAbsentValue() which has the identical conduct. Then why did I nonetheless add
MapIterable.getOrDefault() primarily for simple interoperability. Firstly, most Java builders will pay attention to the
getOrDefault() technique, solely Eclipse Collections customers would pay attention to
getIfAbsentValue(). By offering the API similar because the JDK it reduces the need to study a brand new API. Secondly, although
getOrDefault() is offered on
MutableMap, it’s not accessible on the very best
Map interface of Eclipse Collections. Thirdly, I obtained to study a Java compiler test which I had not skilled earlier than. I’ll elaborate this test a bit extra intimately as a result of I discover it attention-grabbing.
After I added
Map interfaces in Eclipse Collections began giving compiler errors with messages like:
org.eclipse.collections.api.map.MutableMapIterable inherits unrelated defaults for getOrDefault(Object, V) from sorts org.eclipse.collections.api.map.MapIterable and java.util.Map. This I assumed was cool, as a result of at compile time, the Java compiler is guaranteeing that if there’s an API with default implementation in a couple of interface in a multi-interface situation, then Java is not going to resolve which implementation to choose however reasonably throw compiler errors. Therefore, Java ensures at compile time that there is no such thing as a ambiguity concerning which implementation might be used at runtime. How superior is that?!? With the intention to repair the compile time errors, I had so as to add a default implementations on the interfaces which gave the errors. I at all times consider in Compiler Errors are higher than Runtime Exceptions.
Put up Eclipse Collections 10.three.zero the beneath code samples will work:
Eclipse Collections 10.three.zero was launched on 08/08/2020 and is one in every of our most function packed releases. The discharge constitutes quite a few contributions from the Java neighborhood.
Present your help star us on GitHub.