Java 9或更高版本中预计的泛型专门化，vs List<int>：将如何实现。移除（）工作？

Question

泛型专门化和值类型是未来JVM的一个突出特征；链接到Valhalla项目页面here

据我所知，现在可以宣布：

final List<int> myList = new ArrayList<>(); // for instance

但是List除了Collection接口中定义的.remove()方法之外，还定义了另一个.remove()方法，该方法将int作为参数，该参数是列表中要删除的索引；这就是为什么当前list的内容在下面的示例中：

final List<Integer> list = new ArrayList<>();
list.add(1);
list.add(2);
list.add(3);
list.remove(2);

将是[1, 2]而不是[1, 3]（选择最具体的重载）

但是，如果将来我们能够声明一个List<int>，我们就有一个问题：将选择remove方法的哪个重载

Answer 1

这个答案基于Brian Goetz 2014年12月的this paper。关于这个问题，我能找到的最新消息是；但是请注意，这篇论文是一篇“非正式的素描”，所以关于你的问题还没有确定的答案

首先，a List<int>不是List<Integer>（Subtyping）的子类型：

Initially, it might also seem sensible that Box<int> could be a subtype of raw Box. But, given our translation strategy, the Box class cannot be a superclass of whatever class represents Box<int>, as then Box<int> would have a field t of type Object, whereas t should be of type int. So Box<int> cannot be a subtype of raw Box. (And for the same reason, Box<int> cannot be a subtype of Box<Integer>.)

...

Since generics are invariant, it is not surprising that List<int> is not a subtype of List<Integer>. The slightly surprising thing here is that a specialized type cannot interoperate with its raw counterpart. However, this is not an unreasonable restriction; not only are raw types discouraged (having been introduced solely for the purpose of supporting the gradual migration from non-generic code to generic code), but it is still possible to write fully generic code using generic methods see "Generic Methods".

本文还列出了“移民挑战”，其中reference-primitive overloadings（问题是你的问题）是：

Some overloadings that are valid today would become problematic under specialization. For example, these methods would have a problem if specialized with T=int:

public void remove(int position);
public void remove(T element);

Such overloads would be problematic both on the specialization side (what methods to generate) and on the overload selection side (which method to invoke.)

建议的解决方案称为the "peeling" technique：

Consider the overload pair in a List-like class:

interface ListLike<T> {
    public void remove(int position);
    public void remove(T element);
}

Existing uses of ListLike will all involve reference instantiations, since those are the only instantiations currently allowed in a pre-specialization world. Note that while compatibility requires that reference instantiations have both of these methods, it requires nothing of non-reference instantiations (since none currently exist.)

The intuition behind peeling is to observe that, while we're used to thinking of the existing ListLike as the generic type, that it might really be the union of a type that is generic across all instantiations, and a type that is generic across only reference instantations.

If we were writing this class from scratch in a post-specialization world, we might have written it as:

interface ListLike<any T> {
    void removeByIndex(int position);
    void removeByValue(T element);
}

But, such a change now would not be either source-compatible or binary-compatible. However, peeling allows us to add these methods to the generic layer, and implement them in a reference-specific layer, without requiring them in the specializations, restoring compatibility:

interface ListLike<any T> {
    // New methods added to the generic layer
    void removeByValue(T element);
    void removeByIndex(int pos);

    layer<ref T> {
        // Abstract methods that exist only in the ref layer
        void remove(int pos);
        void remove(T element);

        // Default implementations of the new generic methods
        default void removeByIndex(int pos) { remove(pos); }
        default void removeByValue(T t) { remove(t); }
    }
}

Now, reference instantiations have remove(T), and remove(int) (as well as the new methods removeByIndex and removeByValue), ensuring compatibility, and specializations have the nonproblematic overloads of removeByValue(T) and removeByIndex(int). Existing implementations of ListLike would continue to compile since the new methods have a default implementation for reference specializations (which simply bridges to the existing remove methods). For value instantiations, removeByIndex and removeByValue are seen as abstract and must be provided, but remove does not exist at all.

This technique also enables the "implementation by parts" technique; it is possible to declare a method abstract in the generic layer and provide concrete implementations in both the value and reference layers. If we allowed layers for T=int, it would also enable the "specializing the specializations" technique.

使用这种技术，将保持向后兼容性，并使用新方法removeByValue和removeByIndex