Why is Collection not simply treated as Collection
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
Consider the following API method taken from Shiro's org.apache.shiro.subject.PrincipalCollection
interface but probably present in other libraries as well:
Collection fromRealm(String realmName);
Yes even nowadays there are still libraries that are using raw-types, probably to preserve pre Java 1.5 compatibility?!
If I now want to use this method together with streams or optionals like this:
principals.fromRealm(realmName).stream().collect(Collectors.toSet());
I get a warning about unchecked conversion and using raw types and that I should prefer using parameterized types.
Eclipse:
Type safety: The method collect(Collector) belongs to the raw type Stream. References to generic type Stream<T> should be parameterized
javac:
Note: GenericsTest.java uses unchecked or unsafe operations.
As I can't change the API method's signature to get rid of this warning I can either annotate with @SuppressWarnings("unchecked")
or simply cast to Collection<?>
like this:
((Collection<?>) principals.fromRealm(realmName)).stream().collect(Collectors.toSet());
As this cast of course always works I'm wondering why the compilers are not simply treating Collection
as Collection<?>
but warn about this situation. Adding the annotation or the cast doesn't improve the code a single bit, but decreases readability or might even shadow actual valid warnings about usage of unparameterized types.
java generics
add a comment |
Consider the following API method taken from Shiro's org.apache.shiro.subject.PrincipalCollection
interface but probably present in other libraries as well:
Collection fromRealm(String realmName);
Yes even nowadays there are still libraries that are using raw-types, probably to preserve pre Java 1.5 compatibility?!
If I now want to use this method together with streams or optionals like this:
principals.fromRealm(realmName).stream().collect(Collectors.toSet());
I get a warning about unchecked conversion and using raw types and that I should prefer using parameterized types.
Eclipse:
Type safety: The method collect(Collector) belongs to the raw type Stream. References to generic type Stream<T> should be parameterized
javac:
Note: GenericsTest.java uses unchecked or unsafe operations.
As I can't change the API method's signature to get rid of this warning I can either annotate with @SuppressWarnings("unchecked")
or simply cast to Collection<?>
like this:
((Collection<?>) principals.fromRealm(realmName)).stream().collect(Collectors.toSet());
As this cast of course always works I'm wondering why the compilers are not simply treating Collection
as Collection<?>
but warn about this situation. Adding the annotation or the cast doesn't improve the code a single bit, but decreases readability or might even shadow actual valid warnings about usage of unparameterized types.
java generics
1
The question mark type is a bit tricky. It can be anything, e.g. Collection<?> x; Collection<?> y; doesn't mean x can be cast to y, because it could be different. e. g. x = new ArrayList<String>() ; y=new ArrayList<Integer>() ;
– Martin Strejc
14 hours ago
InsertingCollection<?>
in the place ofCollection
would be tantamount to saying "don't worry about raw types, I've got you covered", whereas developers should actively avoid raw types.
– ernest_k
14 hours ago
I checked their source code and the date when it was first released. They were actually using generic types at that time, but not for that method for some reasons..
– Murat Karagöz
14 hours ago
Collection
is not equivalent toCollection<?>
, it's closer toCollection<Object>
...
– Stobor
5 mins ago
add a comment |
Consider the following API method taken from Shiro's org.apache.shiro.subject.PrincipalCollection
interface but probably present in other libraries as well:
Collection fromRealm(String realmName);
Yes even nowadays there are still libraries that are using raw-types, probably to preserve pre Java 1.5 compatibility?!
If I now want to use this method together with streams or optionals like this:
principals.fromRealm(realmName).stream().collect(Collectors.toSet());
I get a warning about unchecked conversion and using raw types and that I should prefer using parameterized types.
Eclipse:
Type safety: The method collect(Collector) belongs to the raw type Stream. References to generic type Stream<T> should be parameterized
javac:
Note: GenericsTest.java uses unchecked or unsafe operations.
As I can't change the API method's signature to get rid of this warning I can either annotate with @SuppressWarnings("unchecked")
or simply cast to Collection<?>
like this:
((Collection<?>) principals.fromRealm(realmName)).stream().collect(Collectors.toSet());
As this cast of course always works I'm wondering why the compilers are not simply treating Collection
as Collection<?>
but warn about this situation. Adding the annotation or the cast doesn't improve the code a single bit, but decreases readability or might even shadow actual valid warnings about usage of unparameterized types.
java generics
Consider the following API method taken from Shiro's org.apache.shiro.subject.PrincipalCollection
interface but probably present in other libraries as well:
Collection fromRealm(String realmName);
Yes even nowadays there are still libraries that are using raw-types, probably to preserve pre Java 1.5 compatibility?!
If I now want to use this method together with streams or optionals like this:
principals.fromRealm(realmName).stream().collect(Collectors.toSet());
I get a warning about unchecked conversion and using raw types and that I should prefer using parameterized types.
Eclipse:
Type safety: The method collect(Collector) belongs to the raw type Stream. References to generic type Stream<T> should be parameterized
javac:
Note: GenericsTest.java uses unchecked or unsafe operations.
As I can't change the API method's signature to get rid of this warning I can either annotate with @SuppressWarnings("unchecked")
or simply cast to Collection<?>
like this:
((Collection<?>) principals.fromRealm(realmName)).stream().collect(Collectors.toSet());
As this cast of course always works I'm wondering why the compilers are not simply treating Collection
as Collection<?>
but warn about this situation. Adding the annotation or the cast doesn't improve the code a single bit, but decreases readability or might even shadow actual valid warnings about usage of unparameterized types.
java generics
java generics
edited 14 hours ago
dpr
asked 14 hours ago
dprdpr
4,93011647
4,93011647
1
The question mark type is a bit tricky. It can be anything, e.g. Collection<?> x; Collection<?> y; doesn't mean x can be cast to y, because it could be different. e. g. x = new ArrayList<String>() ; y=new ArrayList<Integer>() ;
– Martin Strejc
14 hours ago
InsertingCollection<?>
in the place ofCollection
would be tantamount to saying "don't worry about raw types, I've got you covered", whereas developers should actively avoid raw types.
– ernest_k
14 hours ago
I checked their source code and the date when it was first released. They were actually using generic types at that time, but not for that method for some reasons..
– Murat Karagöz
14 hours ago
Collection
is not equivalent toCollection<?>
, it's closer toCollection<Object>
...
– Stobor
5 mins ago
add a comment |
1
The question mark type is a bit tricky. It can be anything, e.g. Collection<?> x; Collection<?> y; doesn't mean x can be cast to y, because it could be different. e. g. x = new ArrayList<String>() ; y=new ArrayList<Integer>() ;
– Martin Strejc
14 hours ago
InsertingCollection<?>
in the place ofCollection
would be tantamount to saying "don't worry about raw types, I've got you covered", whereas developers should actively avoid raw types.
– ernest_k
14 hours ago
I checked their source code and the date when it was first released. They were actually using generic types at that time, but not for that method for some reasons..
– Murat Karagöz
14 hours ago
Collection
is not equivalent toCollection<?>
, it's closer toCollection<Object>
...
– Stobor
5 mins ago
1
1
The question mark type is a bit tricky. It can be anything, e.g. Collection<?> x; Collection<?> y; doesn't mean x can be cast to y, because it could be different. e. g. x = new ArrayList<String>() ; y=new ArrayList<Integer>() ;
– Martin Strejc
14 hours ago
The question mark type is a bit tricky. It can be anything, e.g. Collection<?> x; Collection<?> y; doesn't mean x can be cast to y, because it could be different. e. g. x = new ArrayList<String>() ; y=new ArrayList<Integer>() ;
– Martin Strejc
14 hours ago
Inserting
Collection<?>
in the place of Collection
would be tantamount to saying "don't worry about raw types, I've got you covered", whereas developers should actively avoid raw types.– ernest_k
14 hours ago
Inserting
Collection<?>
in the place of Collection
would be tantamount to saying "don't worry about raw types, I've got you covered", whereas developers should actively avoid raw types.– ernest_k
14 hours ago
I checked their source code and the date when it was first released. They were actually using generic types at that time, but not for that method for some reasons..
– Murat Karagöz
14 hours ago
I checked their source code and the date when it was first released. They were actually using generic types at that time, but not for that method for some reasons..
– Murat Karagöz
14 hours ago
Collection
is not equivalent to Collection<?>
, it's closer to Collection<Object>
...– Stobor
5 mins ago
Collection
is not equivalent to Collection<?>
, it's closer to Collection<Object>
...– Stobor
5 mins ago
add a comment |
4 Answers
4
active
oldest
votes
The reason is quite simple:
You may read Object
s from a Collection<?>
the same way as from Collection
. But you can't add Object
s to a Collection<?>
(The compiler forbids this) whereas to a Collection
you can.
If after the release of Java 5 the compiler had translated every Collection
to Collection<?>
, then previously written code would not compile anymore and thus would destroy the backward compatibility.
add a comment |
The major difference between raw type and unbounded wildcard <?>
is that the latter is type safe, that is, on a compile level, it checks whether the items in the collection are of the same type. Compiler won't allow you to add string and integer to the collection of wildcard type, but it will allow you to do this:
List raw = new ArrayList();
raw.add("");
raw.add(1);
Actually, in case of unbounded wildcard collections (List<?> wildcard = new ArrayList<String>()
), you can't add anything at all to the list but null
(from Oracle docs):
Since we don't know what the element type of c stands for, we cannot add objects to it. The add() method takes arguments of type E, the element type of the collection. When the actual type parameter is ?, it stands for some unknown type. Any parameter we pass to add would have to be a subtype of this unknown type. Since we don't know what type that is, we cannot pass anything in. The sole exception is null, which is a member of every type.
2
"the [unbounded wildcard <?>] is type safe, that is, on a compile level, it checks whether the items in the collection are of the same type." - Huh?! This is in contradiction to the rest of your answer. - Or maybe not quite; one could say that it is type safe in that it disallows any objects to be put into a collection of<?>
.
– JimmyB
10 hours ago
The compiler performs no checks at all on what is in a generic collection. Rather, it performs checks on the (declared) types of the arguments to its constructors and methods, and on the expectations of the types of its methods' return values.
– John Bollinger
3 hours ago
add a comment |
This may be a bit too opinion-based for SO, but I believe the point of the compiler giving you a warning rather than silently assuming Collection<?>
is that using raw types is something to avoid doing where possible. It's not an error because you can't always avoid it, but it's something that should be discouraged. A warning discourages using raw types, making you question whether a particular use was necessary. Silently treating it as Collection<?>
doesn't.
add a comment |
A use-case that I can think of as to why Collection
is not considered as Collection<?>
is let say we have a instance of ArrayList
Now if the instance is of type ArrayList<Integer>
or ArrayList<Double>
or ArrayList<String>
, you can add that type only(type checking). ArrayList<?>
is not equivalent to ArrayList<Object>
.
But with only ArrayList
, you can add object of any type. This may be one of the reason why compiler is not considering ArrayList
as ArrayList<?>
(type checking).
One more reason could be backward compatibility with Java version that didn't have generics.
add a comment |
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%2f55514277%2fwhy-is-collection-not-simply-treated-as-collection%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
The reason is quite simple:
You may read Object
s from a Collection<?>
the same way as from Collection
. But you can't add Object
s to a Collection<?>
(The compiler forbids this) whereas to a Collection
you can.
If after the release of Java 5 the compiler had translated every Collection
to Collection<?>
, then previously written code would not compile anymore and thus would destroy the backward compatibility.
add a comment |
The reason is quite simple:
You may read Object
s from a Collection<?>
the same way as from Collection
. But you can't add Object
s to a Collection<?>
(The compiler forbids this) whereas to a Collection
you can.
If after the release of Java 5 the compiler had translated every Collection
to Collection<?>
, then previously written code would not compile anymore and thus would destroy the backward compatibility.
add a comment |
The reason is quite simple:
You may read Object
s from a Collection<?>
the same way as from Collection
. But you can't add Object
s to a Collection<?>
(The compiler forbids this) whereas to a Collection
you can.
If after the release of Java 5 the compiler had translated every Collection
to Collection<?>
, then previously written code would not compile anymore and thus would destroy the backward compatibility.
The reason is quite simple:
You may read Object
s from a Collection<?>
the same way as from Collection
. But you can't add Object
s to a Collection<?>
(The compiler forbids this) whereas to a Collection
you can.
If after the release of Java 5 the compiler had translated every Collection
to Collection<?>
, then previously written code would not compile anymore and thus would destroy the backward compatibility.
edited 4 hours ago
Kilian Foth
11.9k32847
11.9k32847
answered 14 hours ago
LinoLino
11.1k22244
11.1k22244
add a comment |
add a comment |
The major difference between raw type and unbounded wildcard <?>
is that the latter is type safe, that is, on a compile level, it checks whether the items in the collection are of the same type. Compiler won't allow you to add string and integer to the collection of wildcard type, but it will allow you to do this:
List raw = new ArrayList();
raw.add("");
raw.add(1);
Actually, in case of unbounded wildcard collections (List<?> wildcard = new ArrayList<String>()
), you can't add anything at all to the list but null
(from Oracle docs):
Since we don't know what the element type of c stands for, we cannot add objects to it. The add() method takes arguments of type E, the element type of the collection. When the actual type parameter is ?, it stands for some unknown type. Any parameter we pass to add would have to be a subtype of this unknown type. Since we don't know what type that is, we cannot pass anything in. The sole exception is null, which is a member of every type.
2
"the [unbounded wildcard <?>] is type safe, that is, on a compile level, it checks whether the items in the collection are of the same type." - Huh?! This is in contradiction to the rest of your answer. - Or maybe not quite; one could say that it is type safe in that it disallows any objects to be put into a collection of<?>
.
– JimmyB
10 hours ago
The compiler performs no checks at all on what is in a generic collection. Rather, it performs checks on the (declared) types of the arguments to its constructors and methods, and on the expectations of the types of its methods' return values.
– John Bollinger
3 hours ago
add a comment |
The major difference between raw type and unbounded wildcard <?>
is that the latter is type safe, that is, on a compile level, it checks whether the items in the collection are of the same type. Compiler won't allow you to add string and integer to the collection of wildcard type, but it will allow you to do this:
List raw = new ArrayList();
raw.add("");
raw.add(1);
Actually, in case of unbounded wildcard collections (List<?> wildcard = new ArrayList<String>()
), you can't add anything at all to the list but null
(from Oracle docs):
Since we don't know what the element type of c stands for, we cannot add objects to it. The add() method takes arguments of type E, the element type of the collection. When the actual type parameter is ?, it stands for some unknown type. Any parameter we pass to add would have to be a subtype of this unknown type. Since we don't know what type that is, we cannot pass anything in. The sole exception is null, which is a member of every type.
2
"the [unbounded wildcard <?>] is type safe, that is, on a compile level, it checks whether the items in the collection are of the same type." - Huh?! This is in contradiction to the rest of your answer. - Or maybe not quite; one could say that it is type safe in that it disallows any objects to be put into a collection of<?>
.
– JimmyB
10 hours ago
The compiler performs no checks at all on what is in a generic collection. Rather, it performs checks on the (declared) types of the arguments to its constructors and methods, and on the expectations of the types of its methods' return values.
– John Bollinger
3 hours ago
add a comment |
The major difference between raw type and unbounded wildcard <?>
is that the latter is type safe, that is, on a compile level, it checks whether the items in the collection are of the same type. Compiler won't allow you to add string and integer to the collection of wildcard type, but it will allow you to do this:
List raw = new ArrayList();
raw.add("");
raw.add(1);
Actually, in case of unbounded wildcard collections (List<?> wildcard = new ArrayList<String>()
), you can't add anything at all to the list but null
(from Oracle docs):
Since we don't know what the element type of c stands for, we cannot add objects to it. The add() method takes arguments of type E, the element type of the collection. When the actual type parameter is ?, it stands for some unknown type. Any parameter we pass to add would have to be a subtype of this unknown type. Since we don't know what type that is, we cannot pass anything in. The sole exception is null, which is a member of every type.
The major difference between raw type and unbounded wildcard <?>
is that the latter is type safe, that is, on a compile level, it checks whether the items in the collection are of the same type. Compiler won't allow you to add string and integer to the collection of wildcard type, but it will allow you to do this:
List raw = new ArrayList();
raw.add("");
raw.add(1);
Actually, in case of unbounded wildcard collections (List<?> wildcard = new ArrayList<String>()
), you can't add anything at all to the list but null
(from Oracle docs):
Since we don't know what the element type of c stands for, we cannot add objects to it. The add() method takes arguments of type E, the element type of the collection. When the actual type parameter is ?, it stands for some unknown type. Any parameter we pass to add would have to be a subtype of this unknown type. Since we don't know what type that is, we cannot pass anything in. The sole exception is null, which is a member of every type.
edited 14 hours ago
answered 14 hours ago
Ondra K.Ondra K.
918726
918726
2
"the [unbounded wildcard <?>] is type safe, that is, on a compile level, it checks whether the items in the collection are of the same type." - Huh?! This is in contradiction to the rest of your answer. - Or maybe not quite; one could say that it is type safe in that it disallows any objects to be put into a collection of<?>
.
– JimmyB
10 hours ago
The compiler performs no checks at all on what is in a generic collection. Rather, it performs checks on the (declared) types of the arguments to its constructors and methods, and on the expectations of the types of its methods' return values.
– John Bollinger
3 hours ago
add a comment |
2
"the [unbounded wildcard <?>] is type safe, that is, on a compile level, it checks whether the items in the collection are of the same type." - Huh?! This is in contradiction to the rest of your answer. - Or maybe not quite; one could say that it is type safe in that it disallows any objects to be put into a collection of<?>
.
– JimmyB
10 hours ago
The compiler performs no checks at all on what is in a generic collection. Rather, it performs checks on the (declared) types of the arguments to its constructors and methods, and on the expectations of the types of its methods' return values.
– John Bollinger
3 hours ago
2
2
"the [unbounded wildcard <?>] is type safe, that is, on a compile level, it checks whether the items in the collection are of the same type." - Huh?! This is in contradiction to the rest of your answer. - Or maybe not quite; one could say that it is type safe in that it disallows any objects to be put into a collection of
<?>
.– JimmyB
10 hours ago
"the [unbounded wildcard <?>] is type safe, that is, on a compile level, it checks whether the items in the collection are of the same type." - Huh?! This is in contradiction to the rest of your answer. - Or maybe not quite; one could say that it is type safe in that it disallows any objects to be put into a collection of
<?>
.– JimmyB
10 hours ago
The compiler performs no checks at all on what is in a generic collection. Rather, it performs checks on the (declared) types of the arguments to its constructors and methods, and on the expectations of the types of its methods' return values.
– John Bollinger
3 hours ago
The compiler performs no checks at all on what is in a generic collection. Rather, it performs checks on the (declared) types of the arguments to its constructors and methods, and on the expectations of the types of its methods' return values.
– John Bollinger
3 hours ago
add a comment |
This may be a bit too opinion-based for SO, but I believe the point of the compiler giving you a warning rather than silently assuming Collection<?>
is that using raw types is something to avoid doing where possible. It's not an error because you can't always avoid it, but it's something that should be discouraged. A warning discourages using raw types, making you question whether a particular use was necessary. Silently treating it as Collection<?>
doesn't.
add a comment |
This may be a bit too opinion-based for SO, but I believe the point of the compiler giving you a warning rather than silently assuming Collection<?>
is that using raw types is something to avoid doing where possible. It's not an error because you can't always avoid it, but it's something that should be discouraged. A warning discourages using raw types, making you question whether a particular use was necessary. Silently treating it as Collection<?>
doesn't.
add a comment |
This may be a bit too opinion-based for SO, but I believe the point of the compiler giving you a warning rather than silently assuming Collection<?>
is that using raw types is something to avoid doing where possible. It's not an error because you can't always avoid it, but it's something that should be discouraged. A warning discourages using raw types, making you question whether a particular use was necessary. Silently treating it as Collection<?>
doesn't.
This may be a bit too opinion-based for SO, but I believe the point of the compiler giving you a warning rather than silently assuming Collection<?>
is that using raw types is something to avoid doing where possible. It's not an error because you can't always avoid it, but it's something that should be discouraged. A warning discourages using raw types, making you question whether a particular use was necessary. Silently treating it as Collection<?>
doesn't.
answered 14 hours ago
T.J. CrowderT.J. Crowder
698k12312411337
698k12312411337
add a comment |
add a comment |
A use-case that I can think of as to why Collection
is not considered as Collection<?>
is let say we have a instance of ArrayList
Now if the instance is of type ArrayList<Integer>
or ArrayList<Double>
or ArrayList<String>
, you can add that type only(type checking). ArrayList<?>
is not equivalent to ArrayList<Object>
.
But with only ArrayList
, you can add object of any type. This may be one of the reason why compiler is not considering ArrayList
as ArrayList<?>
(type checking).
One more reason could be backward compatibility with Java version that didn't have generics.
add a comment |
A use-case that I can think of as to why Collection
is not considered as Collection<?>
is let say we have a instance of ArrayList
Now if the instance is of type ArrayList<Integer>
or ArrayList<Double>
or ArrayList<String>
, you can add that type only(type checking). ArrayList<?>
is not equivalent to ArrayList<Object>
.
But with only ArrayList
, you can add object of any type. This may be one of the reason why compiler is not considering ArrayList
as ArrayList<?>
(type checking).
One more reason could be backward compatibility with Java version that didn't have generics.
add a comment |
A use-case that I can think of as to why Collection
is not considered as Collection<?>
is let say we have a instance of ArrayList
Now if the instance is of type ArrayList<Integer>
or ArrayList<Double>
or ArrayList<String>
, you can add that type only(type checking). ArrayList<?>
is not equivalent to ArrayList<Object>
.
But with only ArrayList
, you can add object of any type. This may be one of the reason why compiler is not considering ArrayList
as ArrayList<?>
(type checking).
One more reason could be backward compatibility with Java version that didn't have generics.
A use-case that I can think of as to why Collection
is not considered as Collection<?>
is let say we have a instance of ArrayList
Now if the instance is of type ArrayList<Integer>
or ArrayList<Double>
or ArrayList<String>
, you can add that type only(type checking). ArrayList<?>
is not equivalent to ArrayList<Object>
.
But with only ArrayList
, you can add object of any type. This may be one of the reason why compiler is not considering ArrayList
as ArrayList<?>
(type checking).
One more reason could be backward compatibility with Java version that didn't have generics.
edited 14 hours ago
T.J. Crowder
698k12312411337
698k12312411337
answered 14 hours ago
Ashishkumar SinghAshishkumar Singh
2,48411127
2,48411127
add a comment |
add a comment |
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%2f55514277%2fwhy-is-collection-not-simply-treated-as-collection%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
The question mark type is a bit tricky. It can be anything, e.g. Collection<?> x; Collection<?> y; doesn't mean x can be cast to y, because it could be different. e. g. x = new ArrayList<String>() ; y=new ArrayList<Integer>() ;
– Martin Strejc
14 hours ago
Inserting
Collection<?>
in the place ofCollection
would be tantamount to saying "don't worry about raw types, I've got you covered", whereas developers should actively avoid raw types.– ernest_k
14 hours ago
I checked their source code and the date when it was first released. They were actually using generic types at that time, but not for that method for some reasons..
– Murat Karagöz
14 hours ago
Collection
is not equivalent toCollection<?>
, it's closer toCollection<Object>
...– Stobor
5 mins ago