总的来说，Java编程思想是一本好书；但是因为译者可能不懂计算机，很多地方都有严重错误。
之前和朋友抱怨过，朋友提议抱怨无用不如干点实事。遂决定边看边将自己找到的翻译错误贴出来，希望能给别人一些帮助。如果有错误之处，欢迎指正。
第15章 泛型
1.P352第二段：原文“但是，考虑到除了final类不能扩展，其他任何类都可以被扩展，所以这种灵活性大多数时候也会有一些性能损耗”，改为“除了final类不能扩展，其他任何类都可以被扩展，所以这种灵活性大多数时候是自然具备的”。
15.1 与C++的比较
无
15.2 简单泛型
无
15.2.1 一个元组类库
无
15.2.2 一个堆栈类
1.P356最后一段：原文“而Stack可以通过两个泛型的类Stack<T>和LinkedList<T>的组合来创建”，改为“而Stack是用LinkedList<T>实现的一个泛型类Stack<T>来创建的”
15.2.3 RandomList
无
15.3 泛型接口
无
15.4 泛型方法
无
15.4.1 杠杆利用类型参数推断
题目改为“利用类型参数推断”
15.4.2 可变参数与泛型方法
代码中F之后的字母应该是G，书中仍为F
15.4.3 用于Generator的泛型方法
无
15.4.4 一个通用的Generator
无
15.4.5 简化元组的使用
无
15.4.6 一个Set实用工具
无
15.5 匿名内部类
无
15.6 构建复杂模型
无
15.7 擦除的神秘之处
无
15.7.1 C++的方式
无
15.7.2 迁移兼容性
1.P375倒数第三段：原文“为了减少潜在的关于擦除的混淆”，改为“为了减少潜在的关于擦除的误解”。
2.P375倒数第二段：原文“因此你就能够在类型参数上执行基于类型的语言操作和反射操作”，改为“因此你就能够在类型参数上执行基于类型语言的相关操作和反射操作”。
3.P376第二段：原文“擦除的核心动机是它使得泛化的客户端可以用非泛化的类库来使用”，改为“擦除的核心动机是它使得泛化的客户端可以和非泛化的类库共存”；原文“在理想情况下，当所有的事物都可以同时被泛化时，我们就可以专注于此。在现实中”，改为“在理想世界里，我们可以在一天内将所有代码立刻泛化，但在现实中”；原文“或者可能刚刚开始接触泛型”，改为“或者需要时间泛化他们的代码”。
4.P376第三段：原文“使得类库按照它们自己的步调变为泛型的”，改为“使得类库按照它们自己的速度变为泛型的”；原文“在决定这就是目标之后”，改为“在确定这个目标之后”。
5.P376第四段：原文“假设某个应用程序具有两个类库X和Y”，改为“假设某个应用程序使用两个类库X和Y”。
15.7.3 擦除的问题
1.P376倒数第三段：原文“泛型不能用于显示地引用运行时类型的操作之中”，改为“泛型类型不能用于显示涉及运行时类型的操作之中”。
2.P376最后一段：原文“尽管你可能希望这样”，改为“尽管你可能希望所有非泛型代码向泛型迁移”。
3.P377倒数第二段：原文“这些语言通常都会比Java更得心应手”，改为“这些语言都会比Java更好用”。
15.7.4 边界处的动作
1.P378最后一段：原文“所以在运行时的问题就是边界：即对象进入和离开方法的地点”，改为“所以在运行时的关键就是边界处：即对象进入和离开方法的点”；原文“这些正是编译器在编译期执行类型检查并插入转型代码的地点”，改为“这些正是编译器在编译期执行类型检查并插入转型代码的位置”。
2.P380第一段：原文“因此你写入（和读取）的代码的噪声将更小”，改为“因此你写入（和读取）的代码将更清晰”。
15.8 擦除的补偿
15.8.1 创建类型实例
1.P381最后一段：原文“最便利的工厂对象就是Class对象”，改为“一个便利的工厂对象就是Class对象”。
2.P382最后一段：原文“get()是模板方法”，改为“create()是模板方法”。
3.P383练习24：原文“使得工厂对象是由一个Map而不是Class<?>持有的”，改为“使得Map中持有的是工厂对象而不是Class<?>”。
15.8.2 泛型数组
1.P383第一段：原文“不能创建泛型数组”，改为“不能创建泛型参数类型数组”；原文“想要创建泛型数组的地方”，改为“想要创建泛型参数类型数组的地方”。
2.P383最后一段：原文“编译器将接受这个程序”，改为“编译器将接受这种写法”；原文“永远都不能创建这个”，改为“永远无法创建这个”；原文“每个数组槽位的尺寸”，改为“每个数组位置的大小”；原文“产生ClassCaseException”，改为“产生ClassCastException”。
3.P385倒数第二段：原文“尽管大多数也可能是所有这类缺陷”，改为“尽管几乎所有这类缺陷”。
4.P386第一段：原文“必须用@SuppressWarnings压制住”，改为“必须用@SuppressWarnings去除”。
15.9 边界
1.P386最后一段-P387第一段：原文“所以，可以用无界泛型参数调用的方法只是那些可以用Object调用的方法”，改为“无界泛型参数可以调用的方法只是那些Object的方法”；原文“那么你就可以用这些类型子集来调用方法”，改为“那么你就可以调用这些类型子集的共有方法”；原文“和在普通情况下所具有的意义是完全不同的”，改为“和在普通情况下所具有的意义是有很大不同的”。
15.10 通配符
1.P389文字最后一行：原文“可以向导出类型的数组赋予”，改后“可以将导出类型的数组赋予”
2.P390第三段整段：改后“实际上，这里并不是向上转型，而是将一个数组赋值给另一个数组。数组的行为是它可以持有其他对象，这里只是因为向上转型，数组对象包含对象类型的规则才没有被打破。这就好像数组了解它们持有的对象，因此在编译期检查和运行时检查之间，你不能混淆他们。”
3.P390第四段：原文“对数组的这种赋值并不是那么可怕”，改后“对数组的这种赋值还不是那么糟糕”
4.P390最后一段：原文“别忘了，泛型不仅和容器相关正确的说法是”，改后“但别忘了泛型不仅是容器。真正正确的说法是”
5.P390最后一段：整段的向上转型都需要加引号，正如书中所说“实际上这根本不是向上转型”。
6.P391第三段：原文“具有任何从Fruit继承的的类型的列表”，改后“任何Fruit子类型的列表”。原文“这实际上并不意味着这个List将持有任何类型的Fruit”，改后“这实际上并不意味着这个List可以持有Fruit的所有子类对象”。原文“某种flist引用没有指定的具体类型”，改后“某种flist引用没有指定的特定类型”。原文“这个类型是什么并没有人关心”，改后“这个类型是什么并未告知”。
7.P391第四段第一句：改后“如果唯一的限制是这个List要持有某种特定的Fruit或Fruit的子类，但是具体类型并未告知，那么你……”。
15.10.1 编译器有多聪明
无
15.10.2 逆变
1.P393第三段：原文“参数Apple”，改后“参数apples”。
2.P393程序GenericWriting.java中，在static void f1()函数定义中，第二句writeExact(fruit, new Apple());在JDK8中编译并未报错，与书中介绍不符。事实上，这里匹配时如果T识别为Fruit，是没有问题的。如果T识别为Apple，则会发生错误。可用显式泛型方法调用验证：GenericWriting.<Fruit>(fruit, new Apple());无错；GenericWriting.<Apple>(fruit, new Apple());则会报错。估计JDK8把T识别为Fruit，而JDK1.5识别为Apple。
3.P393最后一行：原文“因此这个List将持有从T导出的某种具体类型”，改为“因此这个List的参数类型是T的某个特定但未知的父类，从而该List可以持有从T导出的任意具体类型”。
4.P394倒数第三段最后一句：改后“因此，如果静态泛型方法可以奏效，那么当只是读取时，就不需要协变了”。
5.P395练习28：原文“编写一个泛型方法，它具有一个调用第一个泛型类的方法的逆变参数”，改后“编写一个泛型方法，它具有一个第一个泛型类的逆变参数，并调用了第一个泛型类的方法”。原文“编写第二个泛型方法，它具有一个调用第二个泛型类的方法的协变参数”，改为“编写第二个泛型方法，它具有一个第二个泛型类的协变参数，并调用了第二个泛型类的方法”。
15.10.3 无界通配符
1.P396第一段：原文“另外，UnboundedWildcards.java展示了”，改后“另外，UnboundedWildcards1.java展示了”。
2.P396第二段：原文“除非这些语句都不为真”，改后“尽管这些说法都不完全准确”。
3.P398第四段第一句：改后“在Holder类型上的限制被放松为任何扩展自T的对象”。
4.P398倒数第三段最后一句：改后“但是，尝试着调用get()不是很有帮助，因为……”。
5.P398倒数第二段：原文“这个示例还展示了对于在unbounded()中使用无界通配符能够做什么不能做什么所做出的限制”，改后“这个示例还展示了对于在unboundedArg()中使用无界通配符能够做什么不能做什么：不能get()或set()一个T对象，因为T未知”。
6.P398倒数第二段：原文“对于迁移兼容性，rawArgs()将接受所有Holder的不同变体”，此处在英文版中另起一段，而且第一句话完全没有翻译。改后（另起一段）“在main()中，你可以看到哪些方法可以没有错误和警告地接受哪些参数。为了迁移兼容性，rawArgs()将接受Holder的所有变体”
7.P399第一段：原文“就不会有任何可以确定返回类型的类型信息”，改后“就没有办法确定返回类型”。
8.P399第二段：原文“正由于此，它将产生错误和警告，除非提供确切的参数”，改后“正由于此，如果不提供确切的参数，它将产生错误和警告”。
9.P399第二段最后一句：原文“这样做很好”，改后“这样做没问题”。原文“这取决于是否想要从泛型参数中返回类型确定的返回值”，改后“这取决于是否想要从泛型参数中获得某一族的返回值”。原文“或者是否想要向泛型参数传递类型确定的参数”，改为“或者是否想要向泛型参数传递某一族的参数”。
10.P399第三段：原文“但是使用通配符使得你必须接受范围更宽的参数化类型作为参数”，改为“但是使用通配符使得你可以接受范围更宽的一族参数化类型作为参数”。
15.10.4 捕获转换
1.P399第四段：原文“使得这个方法可以回转并调用另一个……”，改后“使得这个方法可以反过来调用另一个……”。
15.11 问题
15.11.1 任何基本类型都不能作为类型参数
1.P400第五段：原文“有一些转换碰巧在发生的同时会对你屏蔽掉。但是，如果性能成为了一个问题，就需要使用专门适配基本类型的容器版本。Org.apache.commons.collections.primitives就是一种开源的这类版本”，改后“有一些转换自动发生而你无从察觉。但是，如果性能是一个问题，则可以使用专门适配基本类型的容器版本。org.apache.commons.collections.primitives就是这类开源版本的一种”。
2.P400第六段：原文“它可以创建持有Byte的Set”，改为“创建了持有Byte的Set”。
3.P400第七段：原文“它指定next()方法返回一个具有其参数类型的对象”，改为“它指定next()方法返回一个参数类型的对象”；原文“它通过使用生成器在数组中填充对象（这使得类泛型在本例中无法工作……”，改为“它使用生成器在数组中填充对象（类泛型在本例中无法奏效……”；原文“并且在main()中，可以看到FArray.fill()使用它在数组中填充对象”，改为“并且在main()中可以看到使用FArray.fill()在数组中填充对象”。
4.P401程序PrimitiveGenericTest.java最后一句改为“// FArray.fill(new int[7], new RandomGenerator.Integer());”。
15.11.2 实现参数化接口
无
15.11.3 转型和警告
1.P402第三段：原文“使用带有泛型类型参数的转型或instanceof不会有任何效果”，改为“将泛型类型参数用于转型或instanceof不会产生任何效果”
2.P402第五段：原文“有时，泛型没有消除对转型的需要，这就会由编译器产生警告，而这个警告是不恰当的”，改为“有时泛型仍旧需要转型，这就会导致编译器产生不恰当的警告”。
3.P403第一段下方编译结果最后一行，“List<Shape> shapes = ……”改为“List<Widget> shapes = ……”。
4.P403第二段：原文“你会被强制要求转型”，改为“你被要求强制转型”。
5.P403练习32：原文“验证在GenericCast.java中的FixedSizeStack将产生异常，如果试图超出其边界的话”，改为“验证在GenericCast.java中如果试图超出边界的话，FixedSizeStack将产生异常”。
15.11.4 重载
1.P403最后一段：原文“与此不同的是，当被擦除的参数不能产生唯一的参数列表时，必须提供明显有区别的方法名”，改为“因此，当擦除后的参数导致产生相同的参数列表时，必须提供不同的方法名”。
15.11.5 基类劫持了接口
1.P404第三段：原文“对可以与ComparablePet的子类比较的类型进行窄化是有意义的，例如，一个Cat对象就只能与”，改为“对与ComparablePet的子类进行比较的类型进行限制是有意义的，例如，一个Cat对象应该只能与”。
2.P404第五段：原文“这只是与覆盖基类中的方法相同”，改为“这只是覆盖基类中的方法”。
15.12 自限定的类型
1.P404第六段：原文“有一个好像是经常性出现的惯用法”，改为“有一个经常出现的惯用法”。
2.P404第七段：原文“SelfBounded类接受泛型参数T……这个边界就是拥有T作为其参数的SelfBounded”，改为“SelfBounded类接受类型参数T……这个边界就是拥有T作为类型参数的SelfBounded”。
3.P404第八段：原文“很难去解析它，它强调的是当extends关键字用于边界与用来创建子类明显是不同的”，改为“很难去解析它。它展示了extends关键字用于边界时的用法与用于创建子类时是明显不同的”。
15.12.1 古怪的循环泛型
1.P404最后一段：原文“不能直接继承一个泛型参数，但是，可以继承在其自己的定义中使用这个泛型参数的类”，改为“不能直接继承一个类型参数。但是，可以继承一个在自己的定义中使用这个类型参数的泛型类”。
2.P405第二段：原文“这个泛型类型接受我的类的名字作为其参数”，改为“这个泛型类型接受我的类的名字作为其参数类型”；原文“当给出导出类的名字时”，改为“当以导出类作为泛型参数类型时”；去掉“好吧，”；原文“甚至那些将被擦除为Object的类型”，改为“尽管它们将被擦除为Object类型”。
3.P405第三段：原文“还有一个方法将在其存储的域上执行操作（尽管只是在这个域上执行Object操作）”，改为“还有一个方法将操作其存储域（尽管只是在这个域上调用Object的方法）”。
4.P405倒数第二段：原文“而不仅是基类BasicHolder类型”，改为“而不仅是基类BasicHolder的参数类型”；原文“这意味着泛型基类变成了一种其所有导出类的公共功能的模板，但是这些功能对于其所有参数和返回值，将使用到处类型”，改为“这意味着泛型基类变成了其所有导出类的公共功能的模板，而这些功能将使用导出类型作为其参数和返回值”；原文“在所产生的类中将使用确切类型而不是基类型”，改为“在所产生的类中将使用确切类型而不是基泛型的参数类型”。
15.12.2 自限定
1.P406倒数第二段：原文“因此自限定惯用法不是可强制执行的”，改为“因此自限定惯用法不是强制执行的”。
2.P407第一段：原文“自限定限制只能强制作用于继承关系”，改为“自限定限制只用来约束继承关系”；原文“就应该了解这个类所用的类型参数将与使用这个参数的类具有相同的基类型”，改为“这个泛型类所用的类型参数将与使用这个参数的类相同”。
3.P407第三段：原文“除上述形式的自限定参数之外的任何事物上”，改为“除上述形式的自限定参数之外的任何类型上”。
15.12.3 参数协变
1.P407最后一段：原文“尽管自限定类型还可以产生于子类类型相同的返回类型，但是这并不十分重要，因为协变返回类型是在Java SE5中引入的”，改为“尽管自限定类型也可以产生与子类类型相同的返回类型，但是这并不十分重要，因为协变返回类型已在Java SE5中引入”。
2.P408倒数第二段：原文“因此可以证明它被重载过”，改为“并证明它被重载过”。
15.13 动态类型安全
1.P409最后一段：原文“可以解决在这种强况下的”，改为“可以解决在这种情况下的”。
2.P410第一段：原文“在后一种情况中，你知道存在问题，但是不知道罪魁祸首在哪里，”，改为“此时，你知道存在问题，但是不知道罪魁祸首在哪里；”。
15.14 异常
1.P410倒数第二段：原文“这将进一步阻止你去定义”，改为“这又一次阻止你去定义”。
2.P410最后一段：原文“类型参数可能会在一个方法的throws子句中用到”，改为“类型参数可以用在一个方法声明的throws子句中”。
15.15 混型
1.P412第四段：原文“但是其最基本的概念是混合多个类的能力”，改为“但是其最基本的概念是在功能上混合多个类”；原文“这往往是你最后的手段”，改为“这往往是你紧要关头的选择”。
15.15.1 C++中的混型
1.P412第七段：原文“一个使得你可以每个对象中混入拥有一个时间戳这样的属性，而另一个可以混入一个序列号”，改为“一个使得你可以为每个对象实例混入时间戳属性，而另一个可以混入序列号属性”。
2.P413第一段：原文“可以将混型看作是一种功能，它可以将现有类映射到新的子类上”，改为“可以将混型看作是一个函数，它将现有类映射到新的子类上”。
15.15.2 与接口混合
无
15.15.3 使用装饰器模式
1.P414第四段：原文“装饰器模式使用分层对象来动态透明地向单个对象中添加责任”，改为“装饰器模式使用分层对象来动态透明地向单个对象中添加职责”；原文“可以通过将其他类包装在这个可装饰对象的四周，来将功能分层”，改为“而你通过将其他类包装在这个可装饰对象上，来添加分层功能”；原文“但是正如你所见，这将是受限的”，改为“但是正如你将看到的，这是受限的”。
2.P414第六段：原文“前面的示例可以被改写为使用装饰器”，改为“前面的示例可以使用装饰器改写”。
3.P415第一段：原文“产生自泛型的类包含所有感兴趣的方法，但是由使用装饰器所产生的对象类型是最后被装饰的类型”，改为“产生的混型类包含所有感兴趣的方法，但是由装饰器产生的对象类型是最后一层装饰器的类型”；原文“而混型的类型是所有被混合到一起的类型”，改为“而混型的类型是所有被混合到一起的类型之和”；原文“其明显的缺陷是它只能有效地工作于装饰中的一层（最后一层），而混型方法显然会更自然一些”，改为“其明显的缺陷是它只能有效地使用装饰中的一层（最后一层），而混型方法可以说更自然一些”。
15.15.4 与动态代理混合
1.P415第三段：原文“所产生的类的动态类型将会是已经混入的组合类型”，改为“所产生类的动态类型是已经混入的组合类型”。
2.P416第一段：原文“因为只有动态类型而不是非静态类型才包含所有的混入类型，因此这仍旧不如C++的方式好，因为可以在具有这些类型的对象上调用方法之前，你被强制要求必须先将这些对象向下转型到恰当的类型”，改为“因为只有动态类型（而不是静态类型）才包含所有的混入类型，所以这仍旧不如C++的方法好——因为在调用方法之前，你被强制要求必须先将对象向下转型到恰当的类型”。
3.P416第二段：原文“人们已经做了大量的工作朝着这个方向努力，包括创建了”，改为“人们已经做了大量的工作，甚至包括创建了”。
15.16 潜在类型机制
1.P416倒数第二段：原文“即要编写能够尽可能广泛地应用的代码”，改为“即要编写尽可能通用的代码”；原文“我们需要各种途径来放松对我们的代码将要作用的类型所作的限制，同时不丢失静态类型检查的好处”，改为“我们需要尽量放松对我们的代码使用的类型的限制，同时又不能丢失静态类型检查的好处”；原文“然后，我们就可以编写出无需修改就可以应用于更多情况的代码”，改为“这样，我们就可以编写出无需修改即可应用于更多场合的代码”。
2.P416倒数第一段：原文“当你在编写或使用只是持有对象的泛型时，这些代码将可以工作于任何类型”，改为“当你在编写或使用只是简单持有对象的泛型时，这些代码将可以用于任何类型”；原文“如果代码不关心它将要作用的类型”，改为“如果代码不关心它用于何种类型”；原文“并因此而相当’泛化‘”，改为“并因此而变得相当’泛化‘”。
3.P417第一段：原文“还是正如你所见到的，当要在泛型类型上执行操作（即调用Object方法之前的操作）时，就会产生问题，因为擦出要求指定可能会用到的泛型类型的边界，以安全地调用代码中的泛型对象上的具体方法”，改为“同样如你所见，当要在泛型类型上执行操作（而不是仅仅调用Object类的方法）时，就会产生问题，因为擦出要求指定可能的泛型类型的边界，以在代码中安全地调用泛型对象上的指定方法”。
4.P417第三段：原文“泛型代码典型地将在泛型类型上调用少量方法”，改为“典型的泛型代码只在泛型类型上调用少量方法”；原文“（并且可以产生更加泛化的代码）”，改为“（于是产生了更加泛化的代码）”。
5.P417第四段：原文“有了它编写出的代码相对于没有它编写出的代码，能够更容易地复用”，改为“用它编写出的代码段相对于不用它的代码段，更容易被复用”；原文“因为我并未被要求去命名我的代码要操作于其上的确切接口，所以，有了潜在类型机制”，改为“因为我并不需要命名代码操作的确切接口，所以利用潜在类型机制”。
6.P417第五段：原文“因此潜在类型机制不要求静态或动态类型检查”，改为“因此潜在类型机制对静态类型检查还是动态类型检查没有要求”
7.P418第一段：原文“而冒号将表示新的作用于的开始”，改为“而冒号表示新的作用域的开始”；原文“’#‘表示注释到行尾”，改为“‘#’表示到行尾为注释”；原文“按惯例成为self”，改为“按惯例称为self”；原文“构造器调用不要求任何类型的‘new’关键字，而且Python允许正则（非成员）函数，就像perform()所表明的那样”，改为“构造器调用不要求类似‘new’的关键字，而且Python允许普通（非类成员）函数，就像perform()那样”。
8.P418第二段：原文“没有任何针对anything的类型”，改为“没有anything的类型”；原文“但是你从来都不必显示地写出这个接口”，改为“但是你不必显示地写出这个接口”。
9.P418第四段：原文“Dog和Robot没有任何共同的东西”，改为“Dog和Robot没有任何共同点”。
10.P418第五段：原文“C++确保了它实际上可以发送的那些消息”，改为“C++确保了它实际上可以发送那些消息”；原文“这些错误消息从历史上看是相当可怕和冗长的，而主要原因是因为C++的模版名声欠佳”，改为“这些错误消息曾经是相当糟糕和冗长的，并且是导致C++模板名声欠佳的主要原因”。
11.P418最后一段：原文“因为泛型是在这场竞赛的后期才添加到Java中的，因此没有任何机会可以去实现任何类型的潜在类型机制，因此Java没有对这种特性的支持”，改为“因为泛型是在后期才添加到Java中的，没有机会去实现类似的潜在类型机制，所以Java没有对这种特性的支持”；原文“所以，初看起来，Java的泛型机制比支持潜在类型机制的语言更‘缺乏泛化性’”，改为“于是，初看起来Java的泛型机制不如支持潜在类型机制的语言‘泛化’”；原文“并在边界表达式中指定它”，改为“并指定它作为边界”。
12.P418批注一：原文“但是这是一种极端情况”，改为“但是这太极端了”；原文“我们可以比较安全地说C++是‘具有通气门的强类型’”，改为“我们可以更保险地说C++是‘具有通气孔的强类型’”。
13.P419第一段：原文“perform()不需要使用泛型来工作”，改为“perform()不是必须使用泛型才能工作”。
15.17 对缺乏潜在类型机制的补偿
15.17.1 反射
无
15.17.2 将一个方法应用于序列
1.P421第三段：原文“让我们看一个说明这个问题的示例”，改为“让我们看一个探索这个问题的示例”；原文“它能够将任何方法应用于某个序列中的所有对象”，改为“它能够适用于某个序列中的所有对象的任何方法”；原文“这是接口看起来并不适合的情况，因为你想要将任何方法应用与一个对象结合”，改为“看起来接口并不适合这种情况，因为你想要适用于一个对象集合的任何方法”。
2.P421第四段：原文“由于有了Java SE5的可变参数”，改为“由于Java SE5有了可变参数”。
3.P422第一段：原文“apply()方法可以接受任何实现了Iterable接口的事物”，改为“apply()方法可以接受任何实现了Iterable接口的类”；原文“但是它还可以接受其他任何事物，只要能够使这些事物是Iterable的”，改为“但是它还是可以接受其他任何类，只要它实现了Iterable接口”。
4.P422第二段：原文“因为没有多少方法可以”，改为“因为没有什么方法可以”。
5.P422第四段：原文“FilledList表示有点进退两难的情况”，改为“FilledList有点进退两难”；原文“而这样做的问题是在FilledList中使用的所有类”，改为“而这样做的问题在于FilledList中使用的所有类”；原文“因此也就没有实现这个接口”，改为“因此也就不会实现这个接口”。
6.P423第一段：原文“在操作注解的新API中得到了广泛的应用”，改为“在操作注解的新API中被广泛地使用”。
7.P423第二段：最后一段改为“另外，尽管Java解决方案……必须指导使用反射实现（尽管反射……已经被明显地改善了）可能比非反射实现要慢一些，因为有太多的操作都是……使用这种解决方案，至少可以……解决方案（以防止陷入过早的优化中），但毫无疑问这是两种方法之间……”
15.17.3 当你并未碰巧拥有正确的接口时
1.P423第五段：原文“可以在任何事物上调用add()”，改为“任何可以调用add()的类”；原文“可以在Collection的子类型上调用add()”，改为“Collection的子类型”；原文“因为它必须限制为只能工作于Collection实现”，改为“因为它必须限制为Collection实现”。
15.17.4 用适配器仿真潜在类型机制
题目改为“用适配器模仿潜在类型机制”
1.P424倒数第三段：原文“Java泛型并不没有潜在类型机制”，改为“所以Java泛型没有潜在类型机制”。
2.P424倒数第一段：原文“从我们拥有的接口中编写代码来产生我们需要的接口”，改为“编写代码从我们拥有的接口来产生我们需要的接口”；原文“我们可以使用适配器来适配已有的接口”，改为“我们可以写相对很少的代码，使用适配器来适配已有的类”。
3.P426第一段：原文“Fill2对Collection的要求与Fill不同”，改为“Fill2不像Fill需要一个Collection”；原文“它是我希望编译器帮我创建的潜在类型的一种体现”，改为“它是我希望编译器为我创建的潜在类型的表示”。
4.P426第五段：原文“这个第二个版本使用了一个泛化的辅助方法，你可以看到这个泛化方法是如何捕获类型并因此而不必显示地写出来的”，改为“它的第二个版本使用了一个辅助的泛型方法，你可以看到这个泛型方法是如何捕获类型并因此不必显示地写出来的”。
5.P426第七段：原文“使用像这样的适配器看起来”，改为“像这样使用适配器看起来”；原文“并且是类库的创建者和消费者都必须理解的事物”，改为“并且是类库的创建者和使用者都必须理解的”；原文“而缺乏经验的程序员可能还没有能够掌握这个概念”，改为“而缺乏经验的程序员可能无法轻易理解这个概念”。
15.18 将函数对象用作策略
1.P426倒数第三段：原文“后来这个示例使用功能型编程风格”，改为“后来这个示例使用函数式编程风格”。
2.P426倒数第二段：原文“如果只查看尝试添加对象的过程，就会看到这是在多个类中的公共操作，但是这个操作没有在任何我们可以指定的基类中表示”，改为“如果只查看尝试将对象相加的过程，就会看到这是在许多类中的常见操作，但是这个操作没有出现在任何指定的基类中”；原文“而其他时间可以使用某种add方法”，改为“有时可以使用某种add方法”；原文“即使你可以将这种情况窄化到Number的子类，这个超类也不包括任何有关’可添加性‘的东西”，改为“即使你将这种情况限定为Number的子类，Number也不包括任何有关‘可加性’的定义”。
3.P426倒数第一段：原文“可以创建对这个方法的调用”，改为“可以调用这个方法”；原文“它们可以传递出去”，改为“它们可以被传递”；原文“可以用类中的任何方法……可以传递出去的单个方法一样”，改为“可以用类中的方法来达到与此相似的目的，但是（如同任何设计模式）函数对象主要是由其意图来区分。这里的意图就是要创建某种事物，它的行为就像是一个可以传递的单个方法一样”。
4.P429第一段：原文“因为我为每个接口都开发了不同的方法，并发现了每个接口的需求”，改为“在我开发不同的方法的过程中，发现了对这些接口的需求”；原文“并且只是声明它们在某种程度上被结合在一起”，改为“并且只是声明它们以某种方式结合在一起”。
5.P430第一段：原文“这只能被称为是副作用（这不是“功能型”编程风格，但仍旧是有用的），或者我们可以让Collector维护内部状态”，改为“这被称为只是为了副作用（这不是”函数式“编程风格，但仍旧是有用的），或者Collector可以维护内部状态”。
6.P430第三段：原文“存储到一个List中”，改为“存储到一个List中，并最后返回这个List”。
7.P430第四段：原文“可以定义附加的泛型函数”，改为“还可以定义更多的泛型函数”；原文“C++ STL就具有很多这类函数”，改为“C++ STL就有很多这样的函数”。
8.P430第五段：原文“我们需要编写函数对象来将泛型方法适配为我们特定的需求”，改为“我们需要编写函数对象来适配泛型方法从而满足我们特定的需求”；原文“调用恰当的方法，从而解决了相同的问题，即添加两个对象”，改为“调用恰当的方法解决了相同的问题，即将两个对象相加”。
8.P430第六段：原文“还有大量的、可能会相当复杂的表达式”，改为“同时还有许多相当复杂的表达式”。
8.P430第七段：原文“这将通过选取li中大于4的所有元素而产生一个列表”，改为“这将选取li中大于4的所有元素产生一个列表”。
15.9 总结：转型真的如此之糟吗？
1.P430倒数第三段：原文“去思考这个论点到底在多少时间内是有效的”，改为“去思考这个论点是否每次都有效”；原文“我将要描述的问题到底有多少次可以穿越障碍得以解决”，改为“我将要描述的问题到底有多少次可以蒙混过关”。
2.P431第一段：原文“我曾经说过”，改为“我继续指出”。
3.P431第二段：原文“并且通过异常，你在程序的另一个独立的部分中发现有不良对象被放置到了容器中，那么必须发现这个不良插入到底是在何处发生的”，改为“而通过异常你只能在程序的另一个独立的部分中发现有错误对象被放置到了容器中，那么你必须找到这个错误插入到底是在何处发生的”。
4.P431第三段：原文“这会多么频繁地发生呢”，改为“它发生的频率高吗”；原文“它是一个包含String对象的被称为files的列表在这个示例中”，改为“它是一个包含String对象的名字为files的List——在这个示例中”；原文“它真正又能潜伏多久呢”，改为“它又能真正潜伏多久呢”；原文“就会非常快地看到异常”，改为“就会立刻看到异常”。
5.P431第四段：原文“狗在猫列表中”，改为“猫列表中的狗”；原文“或者是说明人们会非常频繁地产生这种错误”，改为“或者是说这种错误很常见”；原文“因此，对于泛型是添加到Java中的非常显著和相当复杂的特性这一点，‘狗在猫列表中’这个论据真的能够成为它的理由吗”，改为“因此，Java引入如此重要又相当复杂的泛型特性是因为‘猫列表中的狗’这个论据吗”。
6.P431第五段：原文“（并非必须是其在Java中的特定实现）的目的在于可表达性”，改为“（未必如Java这样独特的实现）的目的在于表达力”。
7.P431第六段：原文“因此，即便‘狗在猫列表中’这个论据经常被用来证明泛型是必要的，但是它仍旧是有问题的”，改为“因此，即使‘猫列表中的狗’这个论据经常被用来证明泛型的必要性，论据本身却是值得怀疑的”；原文“这些努力需要类创建者和消费者共同付出”，改为“这些努力需要类创建者和使用者共同付出”；原文“并可能会因此而使其在某些场合缺乏可应用性，而在这些场合中，他可能会带来附加的价值”，改为“并因此在某些场合降低其可用性，尽管事实上使用它会带来附加价值”。
8.P431倒数第二段：原文“所以某些容器无法达到他们应该具备的健壮性”，改为“所以某些容器无法达到它们本该具备的健壮性”；原文“get(Object key)中就包含这种情况”，改为“get(Object key)中就是这样”；原文“如果这些类是使用在它们之前就存在的泛型设计的，那么这些方法将会使用参数化类型而不是Object，因此也就可以提供这些泛型类型假设会提供的编译器检查”，改为“如果在设计这些类之前就有泛型，那么这些方法将会使用参数化类型而不是Object，因此也就可以提供这些泛型本该提供的编译器检查”。
9.P431倒数第一段：原文“并且是一项不付出艰辛就无法完成的任务”，改为“而且是一项不付出代价就无法完成的任务”；原文“也引发了阵痛”，改为“也付出了代价”；原文“有很多非模板版本在使用”，改为“早期非模板版本已投入使用”；
10.P432第一段：原文“只有时间将会说明Java的泛型方式对这种语言所造成的最终影响”，改为“只有时间会展示Java转向泛型的方式对这种语言所造成的最终影响”。
11.P432第二段：原文“与C++通过C来实现的方式相同”，改为“与C++对待C的方式相同”。
查字典图书网
