我正在尝试PropertyChangeSupport，它具有有用的firePropertyChange方法。如果担心安全性，使用反射来触发方法实际上是否安全，如下面的行中所示，或者仅仅硬编码对方法名称的调用是否更可取？如果反思是一个潜在的问题，那么如何防止呢？
method.invoke(instance, newValue);
答案 0 :(得分：5)
如果担心安全问题，使用反射来触发方法实际上是否安全？或者简单地硬编码对方法名称的调用是否更可取？
一般来说，最好不要使用反射。如果您使用普通（非反射）调用，您的应用程序将更快，更简单（例如更少的代码行）并且更不易碎（例如，不太可能抛出未经检查的异常）。当更简单的方法不起作用时，最好只使用反射。
反思的安全性也是一个潜在的问题。
如果您的JVM运行不受信任或未知的代码可能会尝试做坏事，那么反射API通常会提供很多做坏事的机会。例如，它允许坏代码调用Java编译器可以阻止的方法和访问字段。 （它甚至允许代码执行诸如更改final属性的值以及通常被认为是不可变的其他内容之类的恶意内容。）
即使您的JVM运行完全受信任的代码，设计缺陷或系统级安全问题仍有可能允许黑客注入类或方法名称。然后，反射API将尽职地尝试调用意外的方法。
如果反思是一个潜在的问题，那会怎样阻止呢？
这很容易。应用程序需要各种权限才能成功调用反射API中的相关安全敏感方法。默认情况下，这些权限授予受信任的应用程序，而不授予沙盒应用程序。你可以自由调整它们。
简单的解决方案：如果您正在运行可信代码，或者您担心包含安全性的设计缺陷的可能性，请在防止使用反射API的安全沙箱中运行所有相关代码。 （缺点是一些第三方库的设计假设它们可以使用反射......并且会在沙箱中中断。）
（显然，没有权限检查实际的Method.invoke(...)调用。当应用程序代码从Method获取Class对象时，检查会更早。）
答案 1 :(得分：1)
取决于你所说的“安全”。对于使用受信任库的不受信任代码的上下文，通常会出现一些漏洞。否则，只是糟糕的代码似乎与引入漏洞一样多，就像任何其他糟糕的代码一样。
答案 2 :(得分：0)
硬编码方法名称对于性能是优选的，因为通过反射调用方法会产生额外的开销。
Securitywise，你可以disable access checks on reflected objects这样你可以调用其他类的私有和受保护的方法，只要它不被SecurityManager阻止。