@xuanyu66 #20
你这个例子我懂啦，其实你只是想强调 内部类有没有外部类对象的引用，这个意思嘛。
而 MyEnum$1 是没有持有的。

@xuanyu66 #21
这个我说一下吧，匿名内部类要分情况的：
你 20 楼的说这个例子，就是 new Thread(){}，因为它处于 non-static cnotext 这样的上下文里（ countDown 是个成员方法嘛，所以就是非静态的上下文），所以这时匿名内部类持有了外部类的引用。

然后你最开始给我说的例子：
public enum MyEnum {
```
A {
void doSomething() { }
},


B {
void doSomethingElse() { }
};
```
其实我认为它在实现上相当于：
```
public static final MyEnum A = new MyEnum{
void doSomething() { }
}
```
但偏偏这个匿名内部类赋值给了一个静态变量，那么它便是 static cnotext 的了。所以此时，匿名内部类不能持有外部类的引用。

@xuanyu66
就是我以为 MyEnum$1 是作为 MyEnum 的匿名内部类存在的（因为它的名字长得就像）

你却说 MyEnum$1 是作为 MyEnum 的静态内部类存在的

@xuanyu66
懂啦，给新类新加了个静态方法，里面再去调用了父类的静态方法。

@xuanyu66
谢谢回答啦，那我理解成匿名内部类（还是静态内部类）是不是理解错了=-=

虽说，static context 下的匿名内部类和静态内部类是一样的。

有大佬能解释一下第一个疑问吗，反正就是解释成：编译器帮我加了这两个方便的方法呗？

@wleexi
视频教程呗，哎，想看的资源都太多，都眼花缭乱了。现在只看 java 编程思想，今年能搞完这本就不错了。

@xuanyu66
可能是因为 MyEnum$1 是匿名内部类，所以我没法看到 MyEnum$1 的类定义吧

@xuanyu66
大概懂了，只是有点气，不管怎么看，都看不到内部类 A 继承了 MyEnum，这是 javap -c 后看见的：
```asm
static {};
Code:
0: new #16 // class MyEnum$1
3: dup
4: ldc #17 // String A
6: iconst_0
7: invokespecial #18 // Method MyEnum$1."<init>":(Ljava/lang/String;I)V
10: putstatic #9 // Field A:LMyEnum;
13: new #19 // class MyEnum$2
16: dup
17: ldc #20 // String B
19: iconst_1
20: invokespecial #21 // Method MyEnum$2."<init>":(Ljava/lang/String;I)V
23: putstatic #22 // Field B:LMyEnum;
```
只能勉强看到静态代码块里面，分别初始化了 MyEnum$1 和 MyEnum$2 给自己的静态变量。但就是看不到内部类 A 继承了 MyEnum==

@xuanyu66
这位大哥，我好像懂你意思， 你第二个例子，运行结果居然是：
class MyEnum
class MyEnum$1
class MyEnum
class MyEnum$SS
class java.lang.Object

合着第二个例子里面的 A 和 B 都是内部类了呗，所以 MyEnum.A.getClass()打印出来是 class MyEnum$1 内部类的样子。

而 MyEnum.A.getDeclaringClass()这里我好像还有点懵，我再看下哈==

@tigerfyj
静态方法可以继承这么说可能有点不恰当，毕竟它是类相关的，而且可以被隐藏。

enum 就算实现了别的新的接口，`Class<?> zuper = clazz.getSuperclass();`getSuperclass 应该也是返回直接继承的类 Enum 啊，而不可能是接口吧==

@chendy
@Raymon111111
对哈，从这个角度就好理解多了。不管是 List<Integer>，还是 List<String>，实际上编译生成的 Class 文件，永远只有一份。

@guyeu
@cigarzh
@gIrl1990
找到原因了，因为我之前在当前工程里面新建了很多 java 文件（都是 java 编程思想的例子），有一个例子里面的接口刚好是也叫 Generator （但这个接口我给放到默认包下了），导致 fill 静态函数的那个形参的类型是默认包的 Generator，而不是 net.mindview.util 包的 Generator。

然后我单独再加一句 import net.mindview.util.Generator;就好了。。。

若若问一句，我都 import net.mindview.util.*;了，为啥编译器还是认为是默认包的 Generator，而不是 net.mindview.util 包的 Generator 呢？难道优先默认包的吗？

@gIrl1990
有点奇怪了，那我导入作者的 jar 包就会出错。

@cigarzh
难道编译器真的会蒙蔽吗，我看 import 语句是 import net.mindview.util.*; 看图片，那个类 net.mindview.util.RandomGenerator.String，那么 import net.mindview.util.RandomGenerator.String 去掉导入的 net.mindview.util.*，这个名字应该是 RandomGenerator.String 啊，不会歧义啊==

@secondwtq
话说大佬可以帮忙解释一下 exact2 函数为什么会有编译错误吗？
仅仅是因为，两个形参都要求确切的类型，所以两个实参里不能有一个带通配符的吗？

@secondwtq
谢谢层主，刚看还有点没看大东，多看了几遍大概懂了。话说你是从哪里知道这些知识，感觉我又学到了很多。

首先我才意识到 bottom type 是 null，以前一直以为 java 有上限，没下限。

可能你的分析过程我理解得比较浅显：首先编译器总会找到最合适的推断类型出来，使得泛型方法可调用。且<?>的范围代表了所有类型。

1. wildSubtype 中，由于一个形参推断出来为 Long，一个形参推断出来为？，所以 T 可以被推断为 Long/Number/Object。但为了形参<? extends T>的范围大于等于实参<?>的范围，T 必须被推断为 Object，才可以。

2.wildSupertype 中，同样，由于一个形参推断出来为 Long，一个形参推断出来为？，所以 T 可以被推断为 Long/Number/Object。但形参是<? super T>，无论 T 被推断哪个，其形参的范围都无法大于等于实参<?>的范围。（说得形象点，此函数中，形参的范围是从 Long 到 top，而实参的范围是从 bottom 到 top ）

@Mistwave
谢谢，你说这两点就是<? extends T> 及 <? super T>这两种引用的合法操作和限制操作了吧（一种合法的是“读操作”，另一个是“写操作”）。

你这篇文章也不错，话说你们都喜欢看英文文档啊，我要是能看看 java 官网文档就不错了。。。

主要还是不懂在于，泛型方法上，涉及了通配符（可能是形参涉及了、也可能是实参涉及了）的类型推断，编译器为啥会报这个错==

@oneisall8955
哈哈哈，上次你就给推荐过啦。看了，介绍了<? extends T> 及 <? super T>这两种引用的合法操作和限制操作，不错。但我这里，主要不懂在于，泛型方法上，涉及了通配符的类型推断，编译器为啥会报这个错==
（悄悄地说，等会写博客准备把你那个 copy 的 jdk 例子写进去，哈哈哈）

@aguesuka
怎么个有问题法呀