关于JAVA内如何优雅的修改 依赖框架源码

在JAVA内往往经常会遇到 框架内方法实现高度封装 并且私有不对外公开,无法通过调用底层API 实现自己的复杂,或者框架的内部实现逻辑对于现有需求不能有很好

的扩展需要修改源码的时候, 首先 java jvm虚拟机运行时是通过加载 编译后的class文件运行相应字节码指令的,如果我们通过最底层的 拿到源代码进行反编译修改后

在重新编译覆盖到classpath中替换原先的class文件 这样的方式当然是可以的。但是这样操作过于繁琐,并且不好调试 下面举例maven项目中 如何做到优雅的修改框架源码

作者是从spark 1.6 集成kafka的时候开始接触这方面的,知道老版本kafka的小伙伴一定知道 老版本的kafka-spark streaming 默认是只有reciver 的方式

并没有开放redirect直连方式去拉取message 所以当时很多大佬就直接重写kafaka cluster 源码 开放私有方法 调用底层api 使用redirect 拉取消息。后续kafka官方也意识到

了redirect的必要性 并且增加了相关直连api, 方法如下: 首先在java maven项目中 项目编译会先将maven的第三方依赖加入 然后编译自己的java源文件 所以只要我们在自己项目

中写入相同包名 相同类名 源java文件 这样进行二次编译的时候就会将我们的java文件编译成class 替换原本的第三方依赖。 下面举一个实际中的应用实例

图中 com.* 下面是自己代码 org下面为需要修改的源码 在实际业务中遇到了 再将数据插入es中的时候 需要将地理位置 类型 经纬度 geopoint 插入到es中 因为框架

对es 进行了二次封装,但是现有的业务逻辑还依赖框架 不能通过自己的方式实现, 在实际场景中 首先通过打断点的不断调试找到需要修改的片段(这个断点调试不断用 就很好上手)

这里假如我们找到了 我们需要修改的源码部分 首先在src下建立一个相同包名路径下的java 类 文件 用maven下载源文件 源码 将源文件源码全部copy到 自己的java 文件中

然后就可以尽情修改了 建议再修改代码部分时打上 自己的change部分 跟源码区分出来

下面是 实际业务中 操作修改的部分

之前在修改源码时遇到了 字节码修改安全认证的策略 但是时间有点久 忘记了当时的情况 从而没有复现出 当时的情况 后续如果找到相关的复现情况会进行补充,

但是修改源码也有很多不好的地方 虽然增强了扩展性但是 随着依赖版本的更新 自己代码与更换版本的整合问题也是比较头疼的问题 ,所以建议在实际业务中除非没有别的解决办法不建议

修改依赖源代码。