Quarkus构建内部共享Java库的AOT编译相关问题咨询

核心问题结论 #

引用内部共享Java库获取AOT编译收益，并非必须开发完整Quarkus扩展，具体方案根据共享库的复杂度和复用规模选择即可：

• 若共享库是纯静态工具类、通用DTO这类无反射、无动态代理、无动态资源加载、无特殊字节码要求的简单代码，直接作为普通Jar包引入即可，Quarkus原生编译流程会自动扫描处理标准字节码，不需要额外适配就能拿到AOT性能收益。
• 若共享库用到了反射、动态代理、SPI加载、类路径资源动态读取等GraalVM原生镜像无法自动识别的动态特性，也不强制要求做Quarkus扩展：你可以把GraalVM要求的原生配置文件（reflect-config.json、resource-config.json、proxy-config.json等）放在共享Jar包的META-INF/native-image/${groupId}/${artifactId}/路径下随包发布，业务项目引入后GraalVM会自动读取这些配置完成AOT适配，缺点是这种方式无法利用Quarkus的构建时增强能力，能实现的适配逻辑比较有限。
• 如果共享库逻辑复杂、被3个以上Quarkus项目复用，或者需要用到构建时配置校验、字节码增强、运行时Bean自动注册等高级能力，封装为标准Quarkus扩展是最优方案，适配逻辑随扩展自动分发，业务侧引入依赖后不需要做任何额外原生配置就能拿到完整AOT收益，长期维护成本最低。

内部共享库开发实操指引 #

普通Jar共享方案（适合简单工具类库） #

• 按普通Java项目的方式开发通用逻辑，编写时尽量避免不必要的动态特性，优先使用静态编译友好的写法
• 如果需要补充GraalVM原生配置，直接在项目的src/main/resources/META-INF/native-image/你的库groupId/你的库artifactId/路径下放置对应配置文件，打包后配置会随Jar一起发布
• 将Jar上传到内部Maven仓库，业务项目直接按常规依赖方式引入即可，原生编译时配置会被自动识别。

Quarkus扩展封装方案（适合复杂通用库、多项目复用场景） #

• 用Quarkus官方提供的扩展Maven原型生成扩展项目骨架，生成的项目会自动拆分两个核心模块：
  • runtime模块：存放共享库的实际运行逻辑、配置项定义、运行时相关的CDI Bean定义，这部分代码会被打包进最终的应用运行产物
  • deployment模块：存放构建时逻辑，包括AOT元数据注册、字节码增强、构建时校验、条件装配逻辑，这部分代码仅在应用构建、原生编译阶段执行，不会进入运行时产物
• 在deployment模块通过Quarkus提供的@BuildStep注解编写构建逻辑，直接通过Quarkus提供的构建项API注册反射类、资源路径、代理类，不需要手写GraalVM的json配置文件，还可以实现配置项自动校验、根据业务依赖自动装配功能等高级逻辑
• 扩展打包发布到内部Maven仓库后，业务项目仅需要引入扩展的runtime依赖，Quarkus构建时会自动识别扩展并执行对应适配逻辑，直接完成AOT适配。

内容的提问来源于stack exchange，提问作者Keith Link