本帖最后由 洞穴夜莺 于 2021-7-16 09:17 编辑
某Mod在ecj下编译不通过，其原因如下
java.util.Map定义了java.util.Map.Entry
it.unimi.dsi.fastutil.longs.Long2ObjectMap继承了java.util.Map并定义了it.unimi.dsi.fastutil.longs.Long2ObjectMap.Entry
it.unimi.dsi.fastutil.longs.Long2ObjectLinkedOpenHashMap继承了it.unimi.dsi.fastutil.longs.Long2ObjectMap
该Mod定义一变量类型为it.unimi.dsi.fastutil.longs.Long2ObjectLinkedOpenHashMap.Entry，ecj认为是歧义引用而编译不通过，而javac则将其编译为it.unimi.dsi.fastutil.longs.Long2ObjectMap.Entry
请问在Java语言规范11版中，是否规定了此种引用应当如何处理？我应该给谁发issue？
版**：@dengyu @贺兰兰
某Mod在ecj下编译不通过，其原因如下
java.util.Map定义了java.util.Map.Entry
it.unimi.dsi.fastutil.longs.Long2ObjectMap继承了java.util.Map并定义了it.unimi.dsi.fastutil.longs.Long2ObjectMap.Entry
it.unimi.dsi.fastutil.longs.Long2ObjectLinkedOpenHashMap继承了it.unimi.dsi.fastutil.longs.Long2ObjectMap
该Mod定义一变量类型为it.unimi.dsi.fastutil.longs.Long2ObjectLinkedOpenHashMap.Entry，ecj认为是歧义引用而编译不通过，而javac则将其编译为it.unimi.dsi.fastutil.longs.Long2ObjectMap.Entry
请问在Java语言规范11版中，是否规定了此种引用应当如何处理？我应该给谁发issue？
版**：@dengyu @贺兰兰
emm刚刚我试了我用的fastutil包是7.2版本的，这个版本并没有it.unimi.dsi.fastutil.longs.Long2ObjectLinkedOpenHashMap.Entry这个接口，只有it.unimi.dsi.fastutil.longs.Long2ObjectMap.Entry
（这个问题让我有点迷糊）
（这个问题让我有点迷糊）
dengyu 发表于 2021-7-15 17:14
emm刚刚我试了我用的fastutil包是7.2版本的，这个版本并没有it.unimi.dsi.fastutil.longs.Long2ObjectLinke ...
本来就没有it.unimi.dsi.fastutil.longs.Long2ObjectLinkedOpenHashMap.Entry这个接口
但是it.unimi.dsi.fastutil.longs.Long2ObjectLinkedOpenHashMap继承it.unimi.dsi.fastutil.longs.Long2ObjectMap
他用it.unimi.dsi.fastutil.longs.Long2ObjectLinkedOpenHashMap.Entry指代it.unimi.dsi.fastutil.longs.Long2ObjectMap.Entry，而实现的另一个接口java.util.Map中也存在一个Entry，这是否存在歧义？
本帖最后由 dengyu 于 2021-7-15 18:19 编辑
（反编译仅用于研究使用）
it.unimi.dsi.fastutil.longs.Long2ObjectLinkedOpenHashMap并没有继承it.unimi.dsi.fastutil.longs.Long2ObjectMap，如果必要请发源代码分析。
另，对于歧义的问题，一般使用完整的包名来指定你要引用的类
（虽然还是有点蒙）
（对了，我这“main”函数只是随便写的图一乐的方法，不是入口main函数）
（反编译仅用于研究使用）
it.unimi.dsi.fastutil.longs.Long2ObjectLinkedOpenHashMap并没有继承it.unimi.dsi.fastutil.longs.Long2ObjectMap，如果必要请发源代码分析。
另，对于歧义的问题，一般使用完整的包名来指定你要引用的类
（虽然还是有点蒙）
（对了，我这“main”函数只是随便写的图一乐的方法，不是入口main函数）
dengyu 发表于 2021-7-15 18:13
（反编译仅用于研究使用）
it.unimi.dsi.fastutil.longs.Long2ObjectLinkedOpenHashMap并没有继承it.unimi ...
核心问题可以理解为
- import it.unimi.dsi.fastutil.longs.Long2ObjectLinkedOpenHashMap;
- ...
- Long2ObjectLinkedOpenHashMap.Entry entry;
- ...
至于你说的没有继承的问题，目前不在家，回头查查他用的什么版本的fastutil
本帖最后由 洞穴夜莺 于 2021-7-15 22:58 编辑
fastutil8.2.2
梳理了一下这个类的继承情况如下（仅标注在源码中显式声明的继承关系）
dengyu 发表于 2021-7-15 18:13
（反编译仅用于研究使用）
it.unimi.dsi.fastutil.longs.Long2ObjectLinkedOpenHashMap并没有继承it.unimi ...
fastutil8.2.2
梳理了一下这个类的继承情况如下（仅标注在源码中显式声明的继承关系）
所以说这个it.unimi.dsi.fastutil.longs.Long2ObjectLinkedOpenHashMap确实是从java.util.Map和it.unimi.dsi.fastutil.longs.Long2ObjectMap各继承来了一个Entry成员类
本帖最后由 dengyu 于 2021-7-15 23:36 编辑
以下测试使用的IntelliJ IDEA版本为2020.2.2 x64
eclipse版本为eclipse-java-luna-SR2-win32-x86_64
cache2k版本为cache2k-core-2.0.0.Final
fastutil版本为7.2.0
在测试那段代码时，发现在没有org.cache2k包的情况下，eclipse提示有歧义，提示需要“显式地导入包org.cache2k”，而该包并不是JRE系统库。
在网上下载cache2k包后，导入包，依然报错。
这说明eclipse不能分析准确类继承关系。
将代码使用IDEA编译后，发现IDEA能找到正确的Entry类（使用的是Long2ObjectMap.Entry类，正如你标记的那样）
那么结论也很显然了：eclipse并不能正常地分析出Entry类的继承关系，给出了错误的错误。
而你的另一个问题的答案也肯定是否定的，即没有歧义。我们使用的很明显就是最近一级的类。要使用祖先类，应该显示指明。
（话说所谓“歧义引用”的问题很少见，甚至网络上基本上没有相关资料，这次的问题是IDE本身的问题，与Java语言规范本身没有太大关系）
至于提issue，我建议给eclipse提，虽然我这里用的版本很老了，建议你看看最新版是否修复了bug，若没有就可以提了。
以下测试使用的IntelliJ IDEA版本为2020.2.2 x64
eclipse版本为eclipse-java-luna-SR2-win32-x86_64
cache2k版本为cache2k-core-2.0.0.Final
fastutil版本为7.2.0
在测试那段代码时，发现在没有org.cache2k包的情况下，eclipse提示有歧义，提示需要“显式地导入包org.cache2k”，而该包并不是JRE系统库。
在网上下载cache2k包后，导入包，依然报错。
这说明eclipse不能分析准确类继承关系。
将代码使用IDEA编译后，发现IDEA能找到正确的Entry类（使用的是Long2ObjectMap.Entry类，正如你标记的那样）
那么结论也很显然了：eclipse并不能正常地分析出Entry类的继承关系，给出了错误的错误。
而你的另一个问题的答案也肯定是否定的，即没有歧义。我们使用的很明显就是最近一级的类。要使用祖先类，应该显示指明。
（话说所谓“歧义引用”的问题很少见，甚至网络上基本上没有相关资料，这次的问题是IDE本身的问题，与Java语言规范本身没有太大关系）
至于提issue，我建议给eclipse提，虽然我这里用的版本很老了，建议你看看最新版是否修复了bug，若没有就可以提了。