Managing interface change in diamond hierarchies.
23 hours in the past
Java is an object-oriented language that helps single inheritance for lessons. A category can inherit from at most one single guardian class. Java additionally helps lessons implementing a number of interfaces. Interfaces could prolong a number of interfaces as properly.
The following class diagram illustrates the 2 sorts of inheritance fashions supported in Java.
Before Java 8, strategies on interfaces might solely be summary. It was the accountability of lessons to outline the habits of strategies outlined on interfaces.
Java 8 launched a particularly highly effective characteristic known as default strategies. A default methodology gives each the signature of a way, and a “default” implementation in a way physique that can be utilized by lessons that don’t override the habits. The default strategies characteristic might help make outdated interfaces new once more.
Change occurs. Unfortunately, change generally comes with a value. Open Source Java initiatives have to have the ability to perceive and reply rapidly to alter with the six month launch cadence of OpenJDK characteristic releases. Open Source Java initiatives have an excellent suggestions loop in the event that they take part within the OpenJDK Quality Outreach Program. This program notifies members of the provision of early entry releases of the OpenJDK that they will check their initiatives towards.
The availability of early entry releases of the OpenJDK has helped the Eclipse Collections open supply mission uncover, perceive, report, and tackle points earlier than new variations of the OpenJDK are launched. In this weblog, I’ll clarify 3 times we needed to make modifications in Eclipse Collections after default strategies have been added to current interfaces within the JDK.
Diamond Hierarchies
Inheriting from a number of interfaces can result in the creation of diamond hierarchies. A diamond hierarchy will get its identify from the form of the hierarchy. Consider the next diagram displaying 5 interfaces and a category in a diamond hierarchy relationship.
You might even see totally different interface inheritance shapes within the wild. The shapes might not be diamonds. Sometimes you could encounter the other way up timber. The diamond shapes themselves should not all that essential. The most essential attribute that may result in points is that there exists a toddler interface or class on the backside of a hierarchy that has a number of dad and mom. Having a number of guardian interfaces can result in methodology signature collisions which will break compilation and probably runtime habits.
Diamond Hierarchies earlier than Java 8
The main interface inheritance drawback earlier than Java 8 occurred if two or extra interfaces have the identical methodology signatures with totally different return sorts.
Consider the next diamond hierarchy diagram that defines all summary foo strategies which might be finally applied by ClassD.
The interfaces A, B, C on this diagram all outline foo strategies that return differing types which might be covariant overrides of the guardian interface Top. In order for ClassD to compile, it should override the foo methodology and return a sort that’s appropriate with the foo strategies from all three interfaces. The resolution right here is to override foo in ClassD and return ClassD. ClassD is a subtype of A, B, and C. ClassD is a covariant return sort. Covariance is a vital characteristic of Java return sorts that was added in Java 5.
Interfaces within the JDK have been extraordinarily secure earlier than Java 8. We by no means noticed any interface evolution points in our diamond hierarchies in Eclipse Collections that built-in with Java sorts like Iterable, Collection, Map, List and Set. That modified barely after Java 8.
Diamond Hierarchies after Java 8
Java 8 launched a brand new characteristic known as default strategies. A default methodology permits a developer so as to add habits to an current interface with out theoretically requiring any modifications to lessons that stretch that interface. The default methodology characteristic has allowed the JDK to evolve interfaces which might be a long time outdated. We use default strategies extensively in Eclipse Collections to scale back code duplication throughout summary class hierarchies. There are just a few gotchas to concentrate on when utilizing default strategies, particularly the place there are diamond hierarchies that rely on interfaces that evolve over time.
Every default methodology that’s added to decades-old interfaces like Iterable, Collection, Map, List, Set creates a chance for sudden methodology signature collisions to occur. Don’t be too alarmed in your functions. Most functions will in all probability by no means encounter the diamond hierarchy points that Eclipse Collections and different libraries that present Collection sorts that combine with Java sorts could run into.
The following diagram reveals the default strategies that have been added to the fundamental Collection interfaces in Java 8. Did any of those default strategies break your functions once they arrived in Java 8? My guess can be, in all probability not.
The Map interface had probably the most notable evolution in Java 8 primarily based on the variety of default strategies added. The strategies that have been added to Map have been a a lot wanted enchancment for the Java neighborhood. While Eclipse Collections MutableMap has some practical overlap with strategies within the Map interface, there have been, happily, no methodology signature collisions with the brand new default strategies that have been added. Awesome!
The different Java Collection Framework interfaces had extra modest additions, as a lot of the performance was offered by the brand new Stream API. The spliterator, stream and parallelStream strategies theoretically had the best chance of collisions within the wild as a result of the strategies had zero arguments. In apply, I by no means noticed or heard of any collisions that occurred with these three strategies. Awesome!
On the opposite hand, the forEach, take awayIf, and substituteAll strategies had methodology identify collisions in frameworks like Eclipse Collections. Since the one argument sorts the strategies required have been all new in Java 8 (Consumer, Predicate, UnaryOperator), any collisions have been merely thought-about overloads by the compiler. Awesome!
The methodology kind on List, which takes a decades-old interface named Comparator would lead to collisions that created scratches in some diamonds within the wild. This was unlucky, however generally the JDK wants to interrupt some eggs so as to evolve and enhance. List ought to have had a kind methodology from the start of its existence. Thankfully, it does now.
Every every so often, a change might be made in an interface that requires “sprucing” a diamond hierarchy. Interface modifications could also be out of your management in case you have a relationship with an interface that’s managed by one other library or the JDK itself. Your solely choice could also be to repair compilation failures as soon as they’re discovered and decide if there’s additionally a binary incompatibility which will require a brand new launch of your library or utility to ensure that your shoppers to make use of a brand new model of the JDK or one other library.
The following sections describe three totally different points that could be encountered with evolving interfaces in diamond hierarchies. These are actual examples that illustrate the place Eclipse Collections needed to tackle points attributable to the evolution of interfaces with default strategies after Java 8.
Method collisions with totally different return sorts
The worst gotcha you may encounter with a diamond hierarchy is with strategies signatures colliding with totally different return sorts. There is just one good resolution to this drawback. One of the strategies should be renamed, and all consumer calls to the renamed methodology should be renamed as properly.
When Java 8 was launched, a default methodology kind was added to the java.util.List interface that had a void return sort. Before we open sourced GS Collections, we had a kind methodology on the MutableList interface that returned MutableList. MutableList extends java.util.List, so our solely choice was to rename our methodology and alter all of our consumer code to name the brand new methodology. Thankfully, the entire consumer code was in a single firm, so this was manageable with some rationalization that compile errors would occur and there was a easy repair to alter calls to kind that required a return sort to kindThis.
This is what the kindThis methodology signatures appears like in the present day on MutableList. These two strategies have been added as default strategies on MutableList within the Eclipse Collections 10.0 launch to scale back some code duplication.
default MutableList<T> kindThis(Comparator<? tremendous T> comparator)
{
this.kind(comparator);
return this;
}default MutableList<T> kindThis()
{
return this.kindThis(null);
}
The methodology kindThis delegates to the strategy kind, which was added to the java.util.List interface as default methodology in Java 8. The kind methodology is then overridden in QuickList, which implements MutableList.
@Override
public void kind(Comparator<? tremendous T> comparator)
{
Arrays.kind(this.gadgets, 0, this.measurement, comparator);
}If it isn’t apparent, the explanation kindThis returns this, is in order that it may be used fluently and immediately as a return lead to a way. This is a tremendous comfort that always reduces traces of code when utilizing kindThis.
The List change in Java 8 was described on this latest weblog by Stuart Marks:
Following the recommendation on this weblog, I’m writing all of those experiences down for different maintainers to study from. Thank you, Stuart!
Default methodology collisions may end up in ambiguity
Another gotcha occurs when two guardian interfaces outline default strategies with the identical precise signature. When this occurs then a toddler interface should additionally override that default methodology as properly to take away the paradox that arises. The compiler and runtime won’t be able to find out which default methodology ought to be chosen because the implementation. This ends in an ambiguity at compile time and runtime.
Eclipse Collections encountered this specific drawback with JDK 15. Stuart Marks wrote an excellent weblog describing the problem as properly.
The solely factor this weblog is lacking is a diagram to assist visualize the problem. The following image reveals the colliding default strategies within the hierarchy for CharAdapter.
The resolution to this drawback was so as to add an override of isEmpty within the CharAdapter class.
This hierarchy doesn’t have a full diamond form. It does have the colliding methodology challenge with isEmpty attributable to extending a number of interfaces with the identical methodology signatures for default strategies.
Abstract and Default methodology collisions
In JDK 21, a brand new interface known as SequencedCollection was added in between Collection and List that has strategies like getFirst and getLast. These default strategies collided with summary strategies with the identical signature that have been outlined in WealthyIterable, OrderedIterable, and ListIterable in Eclipse Collections.
The following diagram reveals the diamond hierarchy in Eclipse Collections and the place the strategies finally collide within the little one interface MutableList.
Compilation Only Error
The collision between summary getFirst strategies within the Eclipse Collections sorts on the left and the default getFirst methodology in SequencedCollection on the proper resulted in a compilation error in our JDK 21 EA builds for Eclipse Collections. All earlier JDK variations compiled high quality. What was unclear was whether or not this was solely a compilation error, or if this could require a launch of a brand new model of Eclipse Collections to ensure that the library to work with JDK 21 when it’s launched.
I checked to see if getFirst or getLast was utilized in both of the 2 OSS repos that I’m a committer for which have an Eclipse Collections dependency and have a JDK 21 EA construct. Both repos had checks that use getFirst. The code ran on JDK 21 EA utilizing Eclipse Collections 11.1 with out challenge. The two repos are the Eclipse Collections Kata and BNY Mellon CodeKatas.
This ought to confirm that the problem is compilation solely. I discovered the part within the JLS that I imagine covers this case with colliding summary and default strategies in interface hierarchies.
This is a brand new type of challenge we hadn’t seen earlier than that we are able to now be looking out for with future releases of the JDK.
Polishing this challenge away
I’m going to incorporate code examples right here which present how the issue present itself at compile time and the 2 potential options.
The following is a compilation error and the instance code that creates the compilation challenge with a diamond hierarchy.
java: sorts Diamond.SequencedCollection<E> and Diamond.ListIterable<T> are incompatible; interface Diamond.MutableList<T> inherits summary and default for getFirst() from sorts Diamond.SequencedCollection and Diamond.ListIterable
public class Diamond
{
interface Iterable<E>
{}
interface OrderedIterable<T> extends Iterable<T>
{
T getFirst();
}
interface ListIterable<T> extends OrderedIterable<T>
{
T getFirst();
}
interface Collection<E> extends Iterable<E>
{
}
interface SequencedCollection<E> extends Collection<E>
{
default E getFirst()
{
return null;
}
}
interface List<E> extends SequencedCollection<E>
{
}
interface MutableCollection<T> extends Collection<T>
{
}
interface MutableList<T> extends MutableCollection<T>, ListIterable<T>, List<T>
{
// This code would not compile and fails with error under:
// java: sorts Diamond.SequencedCollection<E> and
// Diamond.ListIterable<T> are incompatible;
// interface Diamond.MutableList<T> inherits summary and default
// for getFirst() from sorts
// Diamond.SequencedCollection and Diamond.ListIterable
}
static class MyList<T> implements MutableList<T>, List<T>
{
public T getFirst()
{
return null;
}
}
public static void most important(String[] args)
{
OrderedIterable<String> a = new MyList<>();
ListIterable<String> b = new MyList<>();
SequencedCollection<String> c = new MyList<>();
List<String> d = new MyList<>();
MutableList<String> e = new MyList<>();
MyList<String> f = new MyList<>();
System.out.println(a.getFirst());
System.out.println(b.getFirst());
System.out.println(c.getFirst());
System.out.println(d.getFirst());
System.out.println(e.getFirst());
}
}
There are two doable options to fixing this compilation challenge. One resolution is so as to add an summary getFirst methodology in MutableList . The different resolution is so as to add a default implementation for getFirst in MutableList.
The precise resolution I used to unravel the compilation challenge in Eclipse Collections was so as to add default strategies to MutableList for getFirst and getLast.
@Override
default T getFirst()
{
return this.isEmpty() ? null : this.get(0);
}@Override
default T getLast()
{
return this.isEmpty() ? null : this.get(this.measurement() - 1);
}
This getLast default methodology implementation can be suboptimal for LinkedList, however these two strategies have already got acceptable overrides in summary and concrete lessons. This resolution’s main aim was to make the compiler glad.
When diamond hierarchies or any a number of interface inheritance exist in a code base, care must be taken to repairs them when interface evolution occurs. Change does and can occur. I hope this weblog demonstrates some helpful actual world instance the place guidelines within the Java Language Specification collide with actual world libraries which might be built-in with JDK interfaces.
I’m fairly glad as an Eclipse Collections maintainer how the ecosystem has developed with Early Access variations of the JDK being supplied with simple automation that we are able to leverage to make use of them. Getting a heads up months prematurely on an upcoming change within the JDK is a large enchancment. Early warning functionality for JDK and library builders is absolutely superb.
In case you need to study extra about the advantages of taking part within the OpenJDK Quality Outreach Program, I’ll shamelessly plug my latest weblog on the subject under.
Thank you for studying this weblog! I hope you discovered the knowledge and examples right here helpful. Enjoy!
I’m the creator of and committer for the Eclipse Collections OSS mission, which is managed on the Eclipse Foundation. Eclipse Collections is open for contributions.
