18.5.2 "the resulting instantiations are not considered part of B1."

Dan Smith daniel.smith at oracle.com
Thu Nov 21 15:55:51 PST 2013

On Nov 21, 2013, at 8:38 AM, Stephan Herrmann <stephan.herrmann at berlin.de> wrote:

> I'm looking at this example:
>    public static <T> void myMethod(final List<? extends File> fileList) {
>        Collections.sort(fileList, new Comparator<File>(){
>            public int compare(File f1, File f2) { return 0; }
>        });
>    }
> Check for applicability creates these type bounds
> (where T#0 stands for an inference variable for T):
>    T#0 = capture#1-of ? extends File
>    T#0 <: File
>    T#0 <: java.lang.Object
> We have a solution, so we proceed to inferring the invocation type.
> Now 18.5.2 says I should use the above bounds (B1) but "the resulting
> instantiations are not considered part of B1."

Lets try this instead:

"(While, as a final step in 18.5.1, it was necessary to demonstrate that the inference variables in B1 could be resolved in order to establish applicability, an instantiation produced by this resolution step is not considered part of B1.)"

The instantiation for T#0 sticks around because we already knew it when B1 was defined, before the resolution step.

Put another way, the resolution step described as the final step of 18.5.1 is tentative, and its results are immediately discarded.


More information about the lambda-spec-experts mailing list