为什么'；Java编译器是否默认缩短名称？（用于性能和模糊处理）

我无法理解为什么Java编译器不通过用一些唯一的ID替换变量、参数和方法名来缩短它们的名称

例如，给定类

public class VeryVeryVeryVeryVeryLongClass {

    private int veryVeryVeryVeryVeryLongInt = 3;

    public void veryVeryVeryVeryVeryLongMethod(int veryVeryVeryVeryVeryLongParamName) {
        this.veryVeryVeryVeryVeryLongInt = veryVeryVeryVeryVeryLongParamName;
    }
}

编译后的文件包含所有这些很长的名称：

---

简单的唯一ID是否会加快解析速度，并提供第一次模糊处理？

您假设总是需要模糊处理，但事实并非如此：

• 反射会崩溃，JavaBeans和许多依赖于它的框架也会崩溃
• 堆栈跟踪将变得完全不可读
• 如果您试图针对已编译的JAR进行编码，那么最终会得到类似于

  String name=p.a1（）

  的代码，而不是

  String name=p.getName（）

---

当你交付完成的应用程序时，模糊处理通常是最后一步，即使如此，除非目标平台有严重的内存限制，否则它也不会被特别频繁地使用。

当你使用一个类时，你会按名称引用它的方法。因此，编译器需要保留这些名称

---

在任何情况下，我都不明白为什么编译器的目标应该是混淆任何东西。相反，它的目标应该正好相反：尽可能透明。

JVM确实在内部使用数字ID

类文件不能像这样混淆，因为Java是动态链接的：成员的名称必须是公开可读的，或者其他类不能使用您的代码

简单的唯一ID不会加快解析速度吗

不会。它会添加一个映射，这可能会减慢它的速度

并且还提供了第一个模糊处理

是的，但是谁想让编译器进行模糊处理呢？不是我

---

你的建议毫无价值。

即使是私人成员也可以通过反射获得。没错，我没有考虑反射，或者当涉及到集成某个第三方库时。我只是想它可能会稍微加快速度。至于混淆，你也是正确的，我会认为它是编译器可以选择的，如果需要的话，它可以加快一点，我的姿势，但有损失较少的技术，它工作得很好，大多数情况下（如JAR和PAC200压缩）。从模糊处理中得到的破坏性“压缩”成本很高，具体的工作方式可能因情况而异，因此我猜它不会给Java团队带来成本。它不能使用符号表吗？并在请求时检索它们（例如，在编译时、反射、堆栈跟踪）@NiklasR符号表仍然需要名称在某个地方，并且您需要额外的延迟加载逻辑（这会带来自己的成本；线程安全等）。有很多方法可以杀死一只猫，但是如果你甚至不确定你想让它死，为什么还要麻烦呢？实现这个特性——很少有人会从中受益，而且他们已经有了第三方工具——意味着你不得不推迟实现其他特性，Java非常需要很多东西（比如lambdas、VM优化，它们可以显著提高性能等等）。这就是为什么这不是一个建议，但这是一个问题。我相信Java是由非常聪明的人设计的，所以我很好奇为什么我觉得直观的东西不存在，我得到了答案。