java - 为什么 Eclipse 空指针分析无法识别断言实用程序？

Question

我更多地是从编译器理论的角度来问这个问题。为什么空指针分析没有考虑Assert.notNull()的影响？

Assert方法来自Spring，其实现为:

public static void notNull(Object object, String message) {
    if (object == null) {
        throw new IllegalArgumentException(message);
    }
}

public static void notNull(Object object) {
    notNull(object, "[Assertion failed] - this argument is required; it must not be null");
}

(这变得非常烦人，因为如果我使用这种断言实用程序，断言后第一次访问该变量会导致警告，这会阻止我实现无警告代码。)

如果我完全内联断言例程，对 a 的访问将不会被标记为空指针访问(在这种微不足道的情况下，它将成为死代码)。但是，静态方法不能被重写(除非没有字节码摆弄)，那么编译器设计者的 POV 不进入方法调用内部进行空指针分析的理由是什么？

这只是性能问题还是有什么因素阻碍了这一点的实现？或者使其与其他编译器检查一致(死代码分析也没有考虑该方法)？

Answer 1

Why Eclipse null pointer analysis failed to recognize assertion utilities?

因为 Eclipse 空指针分析仅考虑正在分析的方法的语句...而不考虑所调用方法的语义。 (我当然不会期望/希望 Eclipse 编译器的分析代码将 Spring 断言方法视为特殊情况。)

This becomes quite annoying ...

那就关闭空分析吧!! (应该有一个 Eclipse 编译器首选项来执行此操作。)

或者更改您的代码，使该值不总是null。或者删除取消引用 null 引用的(动态)无法访问的语句。

说实话，你的例子是如此做作，我无法想象有人会在真实的代码中做这样的事情。没有任何“修复”不会改变代码的含义。我想您的真实代码并非如此......

<小时/>

仔细想想，这里的问题大致相当于Java中检测未初始化变量和不可达语句的问题。 Eclipse 采用与 Java/JLS 相同的解决方案。

<小时/>

至于 Eclipse 应该 使用最先进的非本地分析代码的想法......我不同意。它会使 Eclipse 的交互式编译慢得像糖浆一样。

不实现此操作还有其他原因，包括:

• 该问题在一般情况下无法解决(停止问题)，
• 事实上，在理论上可以解决的情况下，这是一个技术上难以解决的问题，
• 需要维护额外的代码，并且
• 该功能实用性有限这一事实。 (我的意思是认真的，你真的认为值得花费很多人月来解决一小部分用户的小问题，而这些用户可以在几秒钟内自行解决......通过调整编译器首选项？)

但是如果您对此有强烈的感觉，您可以自由地开发和测试分析代码并将其贡献给 Eclipse 项目。