是的，Java 类文件很容易进行逆向工程。格式非常规则，也非常受限制：VM 必须能够验证代码是否符合 Java 代码的强类型规则。这就像一个 C 编译器的输出，所有优化都被禁用：程序结构清晰可见。（在 Java 模型中，当 JIT 编译器运行时，优化发生在 VM 本身。）

不过，人们会尝试混淆；例如使用ProGuard（该市场上有很多工具；这个是免费和开源的）。例如，所有类和方法都用对人类没有意义的字符串重命名（但混淆也会产生一个开发人员自己保存的翻译文件，以便他可以在错误报告的情况下解释回栈跟踪）。

或者，您可以在Ahead-of-Time 编译器（如JET ）中处理您的 Java 代码。这有一些限制（特别是，结果不再是“可移植的”，因为它是本机代码），但它使反编译更加困难（接近逆向工程编译的 C 或 C++ 的复杂性）。

通常，逆向工程往往会奏效，对于 Java 来说更是如此，即使在混淆之后也是如此。您最好不要使用混淆作为安全的基础。

还值得注意的是，这与任何 .Net 语言（如 C#）中的代码阅读问题非常相似。从分布式文件生成 Java、VB.Net 或 C# 代码几乎同样微不足道，而试图使其更难阅读的混淆技术对于两者来说也是相似的。

有许多工具可以对 Java 程序进行反编译，而且它们使用起来相当简单。

例如，JD-GUI显示加载的 JAR 文件的图形视图，并使导航代码相当容易。

如果有人想修改他们有权访问的应用程序中的代码，这相对简单且有据可查，例如这篇McAfee论文介绍了反编译程序、修改 Java 类然后重新编译程序的过程。

正如@ThomasPornin 所说，依赖混淆对于这类问题来说是个坏主意。如果您让某人下载程序的副本，您需要假设攻击者能够访问程序中的任何信息，并且可以绕过仅在客户端进行的任何安全检查。

少量的类文件或 JAR 文件很容易进行逆向工程（参见@Thomas 的回答）。然而，使用数百个 JAR 文件并具有极其复杂的构建脚本的大型 Java 应用程序（例如 J2EE）可能仅因为代码的复杂性而难以进行逆向工程。

有开源和商业工具可以帮助您组织代码并理解这一切，包括一个有趣的 Eclise 插件，称为VERA。

如果您只是想了解代码的结构，那么可以使用自省工具——以及诸如 Rational Suite/Enterprise Architect 之类的建模工具，它们可以吸收 Java JAR 并为您提供 UML 模型。