问题描述:
昨天我接到一个需求,需要给别人一个接口,接口提供的方式需要我给他提供一个jar包调用,我完成任务,写完单元测试,我就编译了一下,把jar包上传到Maven私服上,顺利给那个同学包的版本号~ 以为一切大功告成,美滋滋的喝着白开水~ 可没过2分钟,那位同学告诉我他的项目是用的jdk1.6,我给他的包是jak1.8编译的~ 瞬间爆炸~ 我找了该包的之前的以前的版本,看jar版本也是1.8的,其他同学也是1.6调用的,没有报版本过高的问题呀~我在jar中的MANIFEST.MF查看的一些jar包版本,均为1.8截图如下

同样的build-jdk,为啥有不同的运营结果呢,百思不得其解~
解决过程:
查看报错日志找到不兼容的相关类,最后我把jar包解压,对比了一下两个jar中相同名称的class的问题,终于发现问题所在,虽然是jar的版本是1.8的,但是编译出来的class文件竟然不一样~


所圈的表示编译jdk版本~ 一个是1.5编译的,因为16进制的31对应的十进制是49也就是对象1.5,同理,34对应52对应的1.8。所以不要因为jar的build-jdk迷惑真正的真正的编译的版本,看编译版本一定要看class的文件。
网友评论