我目前正在制作一种基于 JVM 的编程语言。我没有使用运算符，而是选择允许符号作为方法名称，并为原始数据类型创建编译器引用类。这些使用所谓的@Intrinsic 注释进行注释，这些注释将字节码指令作为它们的参数。代替 INVOKE 指令，编译器使用这些指令在每次调用时生成字节码。

我现在想知道这个(公共)注解是否可以用来在 JVM 上做任何恶意的事情，以及它是否应该被编译器限制，例如通过静态分析。

(语言本身也支持字节码表达式)

JVM会在使用前验证字节码，字节码的历史与这个过程无关。最后，如果存在验证器无法识别的某种无效的、可能是恶意的字节码模式，其危险性并不取决于该字节码模式是使用您的编译器和注释创建的还是手动创建的。

这首先是验证概念的原因。 JVM 并不假定编译器总是没有错误的。

但是，让编译器执行合理性检查、静态分析甚至对创建的字节码执行自己的验证仍然是一个好主意。如前所述，这与安全性无关，如果 JVM 的安全性依赖于您的编译器正确执行所有操作，那么无论如何它都会被破坏。但它是关于可用性的，大多数用户喜欢立即对错误做出响应，而无需实际运行代码来了解它是无效的。

通常，如果您可以在 JVM 上执行您选择的代码，那么您已经可以做所有恶意的事情了。 JVM 很难正确沙箱化。

真正的问题是您的威胁模型是什么。通常，如果您在计算机上运行已编译的可执行文件，则假定它能够执行您作为当前用户可以执行的任何操作。甚至 JVM 在桌面上也遵循这个模型。 (还有一个 Java 浏览器插件，它试图在从 Web 加载的小程序上强制执行 Java 级别的沙箱，不幸的是收效甚微)