Solve the error of java.lang.NoSuchMethodError: com.google.common.util.concurrent.MoreExecutors.sameThreadExecutor

1. Reproducing the error

When connecting to hivethe database today, the following error was reported:

Right nowException in thread "main" java.lang.NoSuchMethodError: com.google.common.util.concurrent.MoreExecutors.sameThreadExecutor()Lcom/google/common/util/concurrent/ListeningExecutorService;

2. Analysis errors

The error message means: Method com.google.common.util.concurrent.MoreExecutorsnot found in class .sameThreadExecutor

Don't worry, let's look at at org.apache.curator.framework.listen.ListenerContainer.addListener(ListenerContainer.java:40)this sentence again. It says that the error message is in ListenerContainerthe first line of the class 40.

We click on the console and enter the ListenerContainerrow of the class 40, as shown in the figure below:

As can be seen from the picture above, the color here sameThreadExecutoris red, indicating that MoreExecutorsthere is indeed no sameThreadExecutormethod in the class, so what should we do?

We click into the MoreExecutorsl category to view the comments on the first line, as shown below:

As can be seen from the above figure, MoreExecutorsthe class is in Guava, so pom.xmlthe file is checked, as shown in the figure below:

As can be seen from the above picture, there are indeed no guavadependent packages.

[Remarks]: The visual interface in the above picture is ideathe Maven Helper plug-in. For more idea plug-ins, please visit the link: More than a dozen commonly used and easy-to-use plug-ins of idea.

Since there is no dependent package, why are the classes in the package guavaintroduced ? guavaWe enter it in the text box above guava, as shown below:

All the packages you will see hadoop-common，hive-exec，hive-jdbchave imported guavapackages, and the versions of the imported guavapackages are different.

Therefore, we cannot use packages hadoop-common，hive-exec，hive-jdbcintroduced in packages guava, but use our own guavapackages.

3. Fix errors

Therefore, we pom.xmlintroduce the following packages in:

<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>19.0</version>
</dependency>

Of course, you can eliminate the packages hadoop-common，hive-exec，hive-jdbcintroduced in the package guava, or you can keep them.

For example, I want to eliminate the packages hadoop-commonintroduced in the package guava, as shown in the following code:

<dependency>
    <groupId>org.apache.hadoop</groupId>
    <artifactId>hadoop-common</artifactId>
    <version>2.7.3</version>
    <exclusions>
        <exclusion>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
        </exclusion>
    </exclusions>
</dependency>

After modification, restart, and this error does not appear:

At this time, we enter the position ListenerContainerof the first line of the class 40and find that the error is no longer reported, as shown in the following figure:

4. Important additions

Why are packages pom.xmlintroduced in , and at the same time, packages in packages that are not removed can still run successfully?guavahadoop-common，hive-exec，hive-jdbcguava

We need to consider: dependencies mavenon the same package priority order loading version.pomjar

4.1 POM in maven depends on the same jar package priority order to load versions

jarWhen relying on multiple versions of a package, which version should be used first? The principles are as follows:

1. This level has priority over the superior level, and the superior level has priority over the subordinate level

2. The dependency version at this level takes precedence over the management version

3. The version loaded later in the same package overwrites the version loaded first

4. The upper-level management version and the current-level management version will overwrite the lower-level dependent versions.

5. Different lower-level jars depend on different versions. Prioritize loading the version in the lower-level jar first.

6. It has nothing to do with the size of the version number

7. This level cannot use lower-level management versions

4.2 Glossary of terms

1. Dependency version: refers to dependenciesthe direct dependency

2. Management version: refers dependencyManagementto the version managed

3. This level: refers to the current project

4. Superior: refers to parentdependentjar

5. Subordinate: refers to those referenced by this leveljar