,,Java AbstractMethodError原因案例详解

,,Java AbstractMethodError原因案例详解

本文主要介绍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的观点,版权归原作者所有,仅为传播更多信息之目的,如有侵权请联系,我们将第一时间修改或删除,多谢。

留言与评论(共有 条评论)
   
验证码: