很抱歉,如果问题标题不清楚,但我需要更多字符才能完全解释自己。
在人们开始得出结论之前,是的,我知道isInstance和instanceof但是先听到我的声音。
让我们说我生成一个java" .class"来自UML模型的接口文件(称为MyInterface)。然后,假设某个目录中包含两个" .class"文件,其中一个表示与生成的接口相同的接口(相同的完全限定名称,均使用默认包),另一个表示实现MyInterface的具体类。
在一个单独的程序中,我使用单独的类加载器(URLClassLoader)加载生成的接口和具体类。当我尝试检查具体类是否实现生成的接口版本时,isInstance()返回False。我怀疑这是因为当加载具体类时,非生成的接口会被它拉入,因为它实现了它。如果我在具体类上使用Class.getInterfaces()并将其与使用equals生成的接口进行比较,则也会失败。
由于isInstance()不起作用,有没有人知道一种方法来验证一个类是否实现了一个具有相同完全限定名称的接口,而不一定是编译它的那个?
答案 0 :(得分:2)
假设我从UML模型生成一个接口(称为MyInterface)的java“.class”文件。然后,假设有一个目录,其中包含两个“.class”文件,其中一个表示与生成的文件相同的接口(相同的完全限定名称,均使用默认包),另一个表示具体类实现MyInterface。
为什么呢?这是不好的做法。不要这样做。
在一个单独的程序中,我使用单独的类加载器(URLClassLoader)加载生成的接口和具体类。当我尝试检查具体类是否实现生成的接口版本时,isInstance()返回False。我怀疑这是因为当加载具体类时,非生成的接口会被引入,因为它实现了它。
没有。这是因为你使用了两个类加载器。由不同的类加载器加载的类是不同的。
如果我在具体类上使用Class.getInterfaces()并使用equals将其与生成的接口进行比较,则也会失败。
出于同样的原因。
由于isInstance()不起作用,有没有人知道一种方法来验证一个类是否实现了一个具有相同完全限定名的接口,而不一定是用它编译的接口?
你做不到。类和接口可以在同一个JVM中共存的唯一方法是通过不同的类加载器,这消除了它们之间的实现关系。
解决方案就是首先不要这样做。
答案 1 :(得分:1)
由于您似乎并不太担心这是否是一种好的做法,您可以简单地与Class.getInterfaces()进行比较,但需要与自定义比较(基于名称,或者如果您想要更多参与确保操作也很好。)
只需扫描界面并查找匹配的界面,但不要问默认的"等于"因为你用类加载器作弊的方式为你工作。
顺便说一下,我绝对会把代码完全捕获到NoSuchMethod,它必然会在某些时候发生,整个设置似乎都很脆弱。