Shulou(Shulou.com)06/01 Report--

This article mainly explains "will the default method of Java8 destroy the user's code". The content of the explanation in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "will the default method of Java8 destroy the user's code?"

At first, it seems that the default method brings many new features to the instruction set of the Java virtual machine. Eventually, the people who develop the library will be able to upgrade the API without causing compatibility problems with the client code. Using the default method, any class that implements the library interface automatically adapts to the default method introduced by the interface. Once the user updates his implemented class, he can easily override the original default method with a more meaningful method. Better yet, the user can call the default implementation of the interface while adding business logic when overriding the method.

So far, everything has been fine. However, adding the default method when creating an interface may make the Java code incompatible. This can be easily understood from the following example. Let's assume that a library needs one of its interfaces as input:

Interface SimpleInput {void foo (); void bar ();} abstract class SimpleInputAdapter implements SimpleInput {@ Override public void bar () {/ / some default behavior...}}

Prior to Java 8, similar to the way above using an interface and an adapter class, it was a very common design pattern in the Java programming language. This adapter is usually provided by the library provider and is used to save some operations of the library's consumers. However, if provided in the form of an interface, it is similar to allowing multiple inheritance.

Let's further assume that a user uses the following adapter:

Class MyInput extends SimpleInputAdapter {@ Override public void foo () {/ / do something...} @ Override public void bar () {super.bar (); / / do something additionally...}}

In this way, we can finally interact with the library. Notice how we override the bar method and add additional functionality to the default implementation.

What happens if you migrate the library to Java 8? First, it is highly likely that the library will discard the adapter class and provide this functionality using the default method. Finally, the interface looks like this:

Interface SimpleInput {void foo (); default void bar () {/ / some default behavior}}

With this new interface, the user can update his code and replace the original adapter class with the default method. The result of using an interface instead of an adapter class is that the class can extend other classes rather than specific adapters. Now let's practice porting the MyInput class to use the default method. Because we can now inherit other classes, we inherit a third-party base class. We don't need to care about the role of this basic class here, we can assume that it makes sense for our function.

Class MyInput extends ThirdPartyBaseClass implements SimpleInput {@ Override public void foo () {/ / do something...} @ Override public void bar () {SimpleInput.super.bar (); / / do something additionally...}}

To achieve similar functionality to the original class, we use the new syntax of Java 8 to call the default method of the specified interface. At the same time, move some of the logic in our method to the base class. At this point, you may pat me on the shoulder and say, this is a very good refactoring!

We used the library quite successfully. However, the maintainer needs to add another interface to provide more functionality. This interface is replaced by the ComplexInput interface, which inherits from the SimpleInput interface and adds new methods. Because the default method is generally safe to add, the maintainer overrides SimpleInput's default method, providing a better default method. After all, this is common to adopt an adapter class approach.

Interface ComplexInput extends SimpleInput {void qux (); @ Override default void bar () {SimpleInput.super.bar (); / / so complex, we need to do more...}}

The new features worked so well that the maintainers of ThirdPartyBaseClass decided to rely on the library. To do this, it implements the ComplexInput interface in ThirdPartyLibrary.

But what does this mean for the MyInput class? In order to implicitly implement the ComplexInput interface, you can inherit the ThirdPartyBaseClass class, but calling the default method of SimpleInput suddenly becomes illegal. As a result, the user's code cannot be compiled. This call is now prohibited because Java considers it illegal to call the parent class of the parent class in an indirect subclass. You can only call the default method in ComplexInput, but this requires you to implement the interface in MyInput as shown. For users of the library, this change is not expected!

What's even weirder is that the Java runtime does not impose this restriction. JVM's validator allows a compiled class to call the SimpleInput::foo method, even if the class inherits the updated ThirdPartyBaseClass, implicitly implementing ComplexClass. This limitation exists only in the compiler.

Thank you for reading, the above is the "Java8 default method will destroy the user's code" content, after the study of this article, I believe that the default method of Java8 will destroy the user's code this problem has a deeper understanding, the specific use of the need for you to practice verification. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.