Mixing
Surprising “inferred type does not conform to upper bound” error
When i try to compile this cut-down example with a compiler from JDK 9, 10, or 11:
public class UpperBounder {
public static void main(String args) {
print(Stream.of("a", "z", "b").collect(Collectors.toCollection(TreeSet::new)));
}
static void print(Set<?> set) {
System.out.println(set);
}
}
I get this error:
error: incompatible types: inferred type does not conform to upper bound(s)
print(Stream.of("a", "z", "b").collect(Collectors.toCollection(TreeSet::new)));
^
inferred: INT#1
upper bound(s): Collection<String>,Set<?>,Object
where INT#1 is an intersection type:
INT#1 extends Object,Set<?>,Collection<String>
When i try to compile it with JDK 1.8.0_121, i get a different error. But when i or a colleague try to compile it with JDK 1.8.0_05, 1.8.0_20, 1.8.0_40, or 1.8.0_45, it compiles fine!
Replacing TreeSet::new with () -> new TreeSet<>() makes this compile without errors on all versions.
I think this program is clearly sound: the argument to print will be a TreeSet<String>, which conforms to Set<?>. Moreover, the error message makes no sense to me: an intersection type which is Object, Set<?>, and Collection<String> should conform to upper bounds which are Collection<String>, Set<?>, and Object!
What is going on? Is this a bug? Or is this how type inference is supposed to work? Why did it work before? How can i make it work again (without using a lambda instead of a method reference)?
java generics compiler-errors type-inference compiler-bug
asked Nov 22 '18 at 12:15
Tom AndersonTom Anderson
37.4k1174110
add a comment |
When i try to compile this cut-down example with a compiler from JDK 9, 10, or 11:
public class UpperBounder {
public static void main(String args) {
print(Stream.of("a", "z", "b").collect(Collectors.toCollection(TreeSet::new)));
}
static void print(Set<?> set) {
System.out.println(set);
}
}
I get this error:
error: incompatible types: inferred type does not conform to upper bound(s)
print(Stream.of("a", "z", "b").collect(Collectors.toCollection(TreeSet::new)));
^
inferred: INT#1
upper bound(s): Collection<String>,Set<?>,Object
where INT#1 is an intersection type:
INT#1 extends Object,Set<?>,Collection<String>
When i try to compile it with JDK 1.8.0_121, i get a different error. But when i or a colleague try to compile it with JDK 1.8.0_05, 1.8.0_20, 1.8.0_40, or 1.8.0_45, it compiles fine!
Replacing TreeSet::new with () -> new TreeSet<>() makes this compile without errors on all versions.
I think this program is clearly sound: the argument to print will be a TreeSet<String>, which conforms to Set<?>. Moreover, the error message makes no sense to me: an intersection type which is Object, Set<?>, and Collection<String> should conform to upper bounds which are Collection<String>, Set<?>, and Object!
What is going on? Is this a bug? Or is this how type inference is supposed to work? Why did it work before? How can i make it work again (without using a lambda instead of a method reference)?
java generics compiler-errors type-inference compiler-bug
asked Nov 22 '18 at 12:15
Tom AndersonTom Anderson
37.4k1174110
1
It probably is a bug. In the java bug database, there's a whole bunch of type inference ones (there's a couple about intersecting types which may or may not apply here), many of which are still open, some fixed in JDK9, and a small portion backported to 8. For what it's worth, I can reproduce yours injavac 10.0.2, but not Eclipse's compilerecj 3.14.0.v20180528
– NPras
Nov 23 '18 at 1:38
add a comment |
When i try to compile this cut-down example with a compiler from JDK 9, 10, or 11:
public class UpperBounder {
public static void main(String args) {
print(Stream.of("a", "z", "b").collect(Collectors.toCollection(TreeSet::new)));
}
static void print(Set<?> set) {
System.out.println(set);
}
}
I get this error:
error: incompatible types: inferred type does not conform to upper bound(s)
print(Stream.of("a", "z", "b").collect(Collectors.toCollection(TreeSet::new)));
^
inferred: INT#1
upper bound(s): Collection<String>,Set<?>,Object
where INT#1 is an intersection type:
INT#1 extends Object,Set<?>,Collection<String>
When i try to compile it with JDK 1.8.0_121, i get a different error. But when i or a colleague try to compile it with JDK 1.8.0_05, 1.8.0_20, 1.8.0_40, or 1.8.0_45, it compiles fine!
Replacing TreeSet::new with () -> new TreeSet<>() makes this compile without errors on all versions.
I think this program is clearly sound: the argument to print will be a TreeSet<String>, which conforms to Set<?>. Moreover, the error message makes no sense to me: an intersection type which is Object, Set<?>, and Collection<String> should conform to upper bounds which are Collection<String>, Set<?>, and Object!
What is going on? Is this a bug? Or is this how type inference is supposed to work? Why did it work before? How can i make it work again (without using a lambda instead of a method reference)?
java generics compiler-errors type-inference compiler-bug
asked Nov 22 '18 at 12:15
Tom AndersonTom Anderson
37.4k1174110
When i try to compile this cut-down example with a compiler from JDK 9, 10, or 11:
public class UpperBounder {
public static void main(String args) {
print(Stream.of("a", "z", "b").collect(Collectors.toCollection(TreeSet::new)));
}
static void print(Set<?> set) {
System.out.println(set);
}
}
I get this error:
error: incompatible types: inferred type does not conform to upper bound(s)
print(Stream.of("a", "z", "b").collect(Collectors.toCollection(TreeSet::new)));
^
inferred: INT#1
upper bound(s): Collection<String>,Set<?>,Object
where INT#1 is an intersection type:
INT#1 extends Object,Set<?>,Collection<String>
When i try to compile it with JDK 1.8.0_121, i get a different error. But when i or a colleague try to compile it with JDK 1.8.0_05, 1.8.0_20, 1.8.0_40, or 1.8.0_45, it compiles fine!
Replacing TreeSet::new with () -> new TreeSet<>() makes this compile without errors on all versions.
I think this program is clearly sound: the argument to print will be a TreeSet<String>, which conforms to Set<?>. Moreover, the error message makes no sense to me: an intersection type which is Object, Set<?>, and Collection<String> should conform to upper bounds which are Collection<String>, Set<?>, and Object!
What is going on? Is this a bug? Or is this how type inference is supposed to work? Why did it work before? How can i make it work again (without using a lambda instead of a method reference)?
java generics compiler-errors type-inference compiler-bug
java generics compiler-errors type-inference compiler-bug
asked Nov 22 '18 at 12:15
Tom AndersonTom Anderson
37.4k1174110
asked Nov 22 '18 at 12:15
Tom AndersonTom Anderson
37.4k1174110
edited Nov 22 '18 at 13:50
Tom Anderson
asked Nov 22 '18 at 12:15
Tom AndersonTom Anderson
37.4k1174110
asked Nov 22 '18 at 12:15
Tom AndersonTom Anderson
37.4k1174110
asked Nov 22 '18 at 12:15
Tom AndersonTom Anderson
37.4k1174110
37.4k1174110
1
It probably is a bug. In the java bug database, there's a whole bunch of type inference ones (there's a couple about intersecting types which may or may not apply here), many of which are still open, some fixed in JDK9, and a small portion backported to 8. For what it's worth, I can reproduce yours injavac 10.0.2, but not Eclipse's compilerecj 3.14.0.v20180528
– NPras
Nov 23 '18 at 1:38
add a comment |
1
It probably is a bug. In the java bug database, there's a whole bunch of type inference ones (there's a couple about intersecting types which may or may not apply here), many of which are still open, some fixed in JDK9, and a small portion backported to 8. For what it's worth, I can reproduce yours injavac 10.0.2, but not Eclipse's compilerecj 3.14.0.v20180528
– NPras
Nov 23 '18 at 1:38
1
1
It probably is a bug. In the java bug database, there's a whole bunch of type inference ones (there's a couple about intersecting types which may or may not apply here), many of which are still open, some fixed in JDK9, and a small portion backported to 8. For what it's worth, I can reproduce yours in
javac 10.0.2, but not Eclipse's compiler ecj 3.14.0.v20180528– NPras
Nov 23 '18 at 1:38
It probably is a bug. In the java bug database, there's a whole bunch of type inference ones (there's a couple about intersecting types which may or may not apply here), many of which are still open, some fixed in JDK9, and a small portion backported to 8. For what it's worth, I can reproduce yours in
javac 10.0.2, but not Eclipse's compiler ecj 3.14.0.v20180528– NPras
Nov 23 '18 at 1:38
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53430812%2fsurprising-inferred-type-does-not-conform-to-upper-bound-error%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53430812%2fsurprising-inferred-type-does-not-conform-to-upper-bound-error%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
It probably is a bug. In the java bug database, there's a whole bunch of type inference ones (there's a couple about intersecting types which may or may not apply here), many of which are still open, some fixed in JDK9, and a small portion backported to 8. For what it's worth, I can reproduce yours in
javac 10.0.2, but not Eclipse's compilerecj 3.14.0.v20180528– NPras
Nov 23 '18 at 1:38