Java AbstractMethodError案例分析详解

背景

AbstractMethodError异常对于我来说还是比较不常遇见的，最近有幸遇到，并侥幸的解决了，在这里把此种场景剖析一番，进入正题，下面是AbstractMethodError在Java的异常机制中所处的位置：

现在明确了AbstractMethodError所具有的特性：

1.它是Error的子类，Error类及其子类都是被划分在非检查异常之列的，就是说这些异常不能在编译阶段被检查出来，只能在运行时才会触发。

2.通过API文档里面的解释大致得出的结论就是说A依赖于B，但是执行的时候发现类B的定义发生了改变，这个改变是针对编译的时候发生了改变，也就是说将类A由java文件编译成.class文件的时候用到了类B的class文件，但是在执行的时候JVM发现真正用到的B的class文件和编译的时候用的不是一个了。于是这个异常就被抛了出来。

至此，AbstractMethodError发生的底层原因也了解的差不多了，再往深层的话就是java的编译机制，以及java代码的执行检查这些更靠近虚拟机的东东，那些我也没什么研究，暂且不表。

底层原因了解了，我们继续谈下平常遇到的更直观的场景:

ClassA ->AbstractClassB  ClassA 依赖于AbstractClassB，通常A是我们自己开发的类，而B则是引用的第三方jar包里面的抽象类。我们的项目中又存在AbstractClassB的多个实现版本，比如：1.0，1.2，2.0等版本，通常主版本号发生了改变的话，一般都是不兼容的。

类A

class A {
	B dependency = new BImpl();
	
	public void testMethod(){
		dependency.changedMethodInDifVersion(arg1, arg2);
	}
}

1.0版本的AbstractClassB：

abstract class B {
    // v1.0
    public abstract void changedMethodInDifVersion(int arg1);
}
 
class BImpl extends B{
    public void changedMethodInDifVersion(int arg1){
        System.out.prinln("我是AbstractClassB 的 1.0 版本实现,Class A编译的时候我没参与，但是Class A运行的时候我却参与了。");        
    }
}

2.0版本的AbstractClassB：

abstract class B {
    //v2.0
    public abstract void changedMethodInDifVersion(int arg1, String arg2);
}
 
class BImpl extends B{
    public void changedMethodInDifVersion(int arg1, String arg2){
        System.out.prinln("我是AbstractClassB 的 2.0 版本实现,编译的时候是我参与了编译");        
    }
}

如果在编译的时候使用的2.0版本中的BImpl和2.0版本的AbstractClassB，然而执行的时候使用的又是1.0版本的BImpl，那么就会抛出AbstractMethodError，这个异常抛出以后会把运行时真正找到的那个方法签名给打印出来的，异常信息会入下：

Exception in Thread XXXXX java.lang.AbstractMehodError  package.Class.运行时实际找到的方法

这个时候在你的classpath中寻找这个类,剔除掉不需要的版本就可以了。

如果在编译的时候使用的2.0版本中的BImpl和2.0版本的AbstractClassB，然而执行的时候使用的又是1.0版本的BImpl 和 1.0版本的AbstractClassB，就会报NoSuchMethodError。

到此这篇关于Java AbstractMethodError案例分析详解的文章就介绍到这了,更多相关Java AbstractMethodError详解内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论