本文主要介绍Java AbstractMethodError案例的详细说明。本文通过一个简单的案例来说明对这项技术的理解和使用。以下是详细内容,有需要的朋友可以参考一下。
背景
AbstractMethodError异常对我来说还是比较少见的。最近有幸遇到了,也有幸解决了。这里,我来分析一下这个场景,进入正题。下面是AbstractMethodError在Java的异常机制中的位置:
现在,AbstractMethodError的特征被阐明:
1.它是错误的一个子类。Error类及其子类被归类为非检查异常,这意味着这些异常不能在编译时被检查出来,只能在运行时被触发。
2.通过API文档中的解释,大致得出结论:A依赖于B,但是在执行过程中B类的定义发生了变化。这个改动是针对编译时的改动,也就是把A类从java文件编译成。类文件,但是在执行过程中,JVM发现实际使用的B的类文件和编译时使用的不一样。所以这个异常被抛弃了。
至此,AbstractMethodError发生的底层原因就差不多明白了。再进一步,就是java的编译机制,java代码的执行检查,更接近虚拟机。那些我没怎么研究过,暂时不展示了。
深层原因是明白的。下面继续说我们平时遇到的比较直观的场景:
ClassA -AbstractClassB ClassA依赖于AbstractClassB。通常A是我们自己开发的类,B是引用的第三方jar包中的抽象类。我们项目中AbstractClassB有几个实现版本,比如1.0,1.2,2.0等。通常情况下,如果更改了主版本号,一般是不兼容的。
a级
A级
b dependency=new BIM pl();
公共void testMethod(){
dependency . changedmethodindiversion(arg 1,arg 2);
}
}
AbstractClassB的1.0版本:
抽象B类{
//1.0版
公共抽象void changedmethodindiversion(int arg 1);
}
BImpl类扩展B{
public void changedmethodindiversion(int arg 1){
system . out . prinln(‘我是abstract classb 1.0版本的实现。' A班编的时候我没参加,A班办的时候我参加了。');
}
}
AbstractClassB的2.0版本:
抽象B类{
//v2.0
公共抽象void changedmethodindiversion(int arg 1,String arg 2);
}
BImpl类扩展B{
public void changedmethodindiversion(int arg 1,String arg2){
System.out.prinln('我是abstract classb 2.0版本的实现,编译时参与了编译');
}
}
如果编译时使用2.0版的BImpl和2.0版的AbstractClassB,而执行时使用1.0版的BImpl,那么会抛出AbstractMethodError。在这个异常被抛出后,在运行时实际找到的方法将被签名和打印,并且异常信息将被输入:
异常thread xxxxx Java . lang . abstractmehoderpackage . class。在运行时实际找到的方法
此时,在您的类路径中查找这个类,并剔除不需要的版本。
如果编译时使用BImpl 2.0版和abstract class b 2.0版,但执行时使用BImpl 1.0版和abstract class b 1.0版,则会向NoSuchMethodError报告。
以上就是本文对Java AbstractMethodError产生原因的详细解释。有关Java AbstractMethodError的更多信息,请搜索我们以前的文章或继续浏览下面的相关文章。希望大家以后能多多支持我们!
郑重声明:本文由网友发布,不代表盛行IT的观点,版权归原作者所有,仅为传播更多信息之目的,如有侵权请联系,我们将第一时间修改或删除,多谢。