是否应默认采用javac暴力方式让CodeQL分析所有Java仓库？

假设要对大量包含Java代码的代码仓库运行CodeQL分析，存在两种场景：

• 部分仓库已正确配置mvn/ant/gradle构建工具，CodeQL分析结果可靠，可与现有构建步骤配合使用；
• 另有部分仓库仅含30+个pom.xml文件，无法构建、无构建工具，仅存在零散.java文件，且CodeQL无法自动构建、团队无法提供构建步骤。

针对这类无文件被分析的情况，有人提出以下暴力解决方案：

1. 完成Java/CodeQL的所有常规配置；
2. 不执行实际构建，执行命令：find . -name "*.java" -print | xargs javac（忽略编译错误）；
3. 运行CodeQL分析步骤。

该方案能解决无文件被分析的问题，所有Java文件都会被纳入分析范围，分析结果也能正常在仓库Security标签页及SARIF文件中显示。现在的核心问题是：是否存在理由阻止默认对所有Java仓库采用该方案？（注：此方法在Kotlin/.NET的类似场景中同样有效，但每次执行javac都会报错）

当然有不少理由阻止将这个方案设为所有Java仓库的默认分析方式，具体如下：

• 分析精度严重打折：CodeQL的核心是基于代码的完整语义信息做分析，而完整语义依赖正常构建产生的字节码和构建上下文。直接批量编译忽略错误时，大量类依赖缺失、语法错误会导致生成的字节码残缺，CodeQL无法准确识别类继承、接口实现、方法调用链等关键逻辑，会漏过很多真实漏洞，同时产生大量无意义的误报，让分析结果失去参考价值。
• 浪费CI/CD资源：对于已经有成熟构建流程的仓库，额外执行一次全量javac编译是完全重复的操作，大型仓库的话会大幅拉长分析流水线的运行时间，占用更多计算资源，降低CI/CD的整体效率。
• 掩盖仓库本身的问题：正常构建流程能暴露代码的依赖缺失、配置错误等问题，而暴力编译忽略错误的方式会把这些问题掩盖过去，导致团队无法及时发现并修复仓库的构建故障，长期来看不利于代码库的健康维护。
• 高级语言特性无法被正确分析：Java的注解处理器、模块化（JPMS）、动态代理等高级特性，需要在特定的构建环节才能被正确处理。直接批量编译不会触发这些环节，CodeQL也就无法分析依赖这些特性的代码逻辑，漏掉相关的漏洞风险。
• 违背CodeQL设计初衷：CodeQL官方明确推荐基于真实构建流程进行分析，因为只有完整的构建才能提供最准确的代码语义信息。暴力编译的方式本质是用“覆盖所有文件”的表象，换取“分析精度”的损失，不符合工具的设计逻辑和最佳实践。

内容的提问来源于stack exchange，提问作者Dan Bradbury