Remember to use GRPC to troubleshoot errors

　　The project has always used grpc as the service interaction program, and the java module I am responsible for refers to the framework for the first time; when the framework is built, the client code is built, and an error is reported:

Runable Error:
java.lang.IllegalAccessError: tried to access field XXXXXXXXXXXXXXXXXXXXXX
    at com.scut.fan.infrastructure.ftree.NewRequest$getMemoriedcount(.java:142)

　　First, let's look at the information about the exception:

package java.lang;

/**
 * Thrown if an application attempts to access or modify a field, or
 * to call a method that it does not have access to.
 * <p>
 * Normally, this error is caught by the compiler; this error can
 * only occur at run time if the definition of a class has
 * incompatibly changed.
 *
 * @author  unascribed
 * @since   1.0
 */
public class IllegalAccessError extends IncompatibleClassChangeError {
    private static final long serialVersionUID = -8988904074992417891L;

    /**
     * Constructs an <code>IllegalAccessError</code> with no detail message.
     */
    public IllegalAccessError() {
        super();
    }

    /**
     * Constructs an <code>IllegalAccessError</code> with the specified
     * detail message.
     *
     * @param   s   the detail message.
     */
    public IllegalAccessError(String s) {
        super(s);
    }
}

　　Usually the best way for us to locate the problem is to first understand the javadoc of the exception. The name of the exception can best reflect the general direction. According to the document, we can know that when you do not have permission to access a field or method, this exception is usually reported. What is Without permission? The first is the modifier problem. If it is protected, it cannot be referenced outside the subclass; if it is modified by default, it cannot be referenced outside the package. Usually, this type of error can be found at compile time. If it is run time, it is usually the class that occurs. If there are incompatible changes, have I fixed the bug smoothly?

　　Later, I went to check the class A of the GetMemoriedcount method, and found that the memoriedcount member variable accessed was the wrong place, that is, the illegalAcessError caused by accessing the member, which is a member of the grpc framework-level parent class inherited by A , I entered the parent class and continued to check, and found that the member is Protected, yes, there should be no problem with subclass access, even if there is a problem, the compiler will report an error, and I immediately began to worry;

Possibility 1 - Package conflict:

　　I have seen many methods on the Internet, and they all say that it is a problem of package conflict, wrong version, etc. In fact, it goes deep into the essence. Package conflict is also an access modifier error, because the version of some packages makes you very crashed. Let’s take an example: ehcache- The two packages 1.1.jar and ehcache-1.2.3.jar have the problem of breaking different access modifiers for the same word of a certain class;

Possibility 2 - inner class class loading:

　　That is, two class files, the first A and the second A$a; will lead to the problem of incomplete value. When I use grpc in generalcode, it is also packaged into a single problem, and there are most internal classes, so I re-produce it once The code, this time I did not use the inner class, and generated dozens of files, but the problem was still not solved in the end, and the proto file configuration of the additional grpc does not use the inner class:

syntax = "proto3";

option java_multiple_files = true ; //here decides whether to use internal classes to compile into a single source file
option java_package = "io.grpc.examples.helloworld";
option java_outer_classname = "HelloWorldProto";
option objc_class_prefix = "HLW";

Possibility 3 - Classloader:

　　Different class loaders cannot be linked together, I haven't done the experiment yet; but I print the ClassLoader of both, they are the same;

breakthrough:

　　Because I use Maven to manage dependencies, I suddenly remembered that this would lead to a very serious problem, that is, when compiling, the package you depend on can be compiled and passed, but after Maven management, the same package, that is, the package conflicts. Maven will only use one package, so if there is a package conflict and Maven discards the package you depend on to compile, it may report an error, and then I immediately build a new project, relying only on the required package, instead of using it in the POM file of the old project, and found that it went well After RPC, it took me a long time to find a GRPC package under a hidden WebLibrary, remove it, and solve the problem;

　　This is the second time I've been killed by Maven, but I can't control Maven's class resolution mechanism. It's my fault that there are many seniors in the project I maintain. This dependency is too messy.