Why is Collection not simply treated as CollectionThe intersection of Java generics and Scala is…not going wellWhat is reflection and why is it useful?What is a serialVersionUID and why should I use it?Java generics type erasure: when and what happens?How do I address unchecked cast warnings?Why is subtracting these two times (in 1927) giving a strange result?Why don't Java's +=, -=, *=, /= compound assignment operators require casting?Why is char[] preferred over String for passwords?Why is it faster to process a sorted array than an unsorted array?Why is printing “B” dramatically slower than printing “#”?Generic return type upper bound - interface vs. class - surprisingly valid code

DOS, create pipe for stdin/stdout of command.com(or 4dos.com) in C or Batch?

Is Social Media Science Fiction?

Draw simple lines in Inkscape

Why is "Reports" in sentence down without "The"

How is it possible for user's password to be changed after storage was encrypted? (on OS X, Android)

Why Is Death Allowed In the Matrix?

What defenses are there against being summoned by the Gate spell?

Can town administrative "code" overule state laws like those forbidding trespassing?

Is there a familial term for apples and pears?

Should I join an office cleaning event for free?

Are tax years 2016 & 2017 back taxes deductible for tax year 2018?

N.B. ligature in Latex

The use of multiple foreign keys on same column in SQL Server

How do I create uniquely male characters?

Are white and non-white police officers equally likely to kill black suspects?

How do we improve the relationship with a client software team that performs poorly and is becoming less collaborative?

How does one intimidate enemies without having the capacity for violence?

What do you call a Matrix-like slowdown and camera movement effect?

Is there a minimum number of transactions in a block?

Why do we use polarized capacitor?

How do you conduct xenoanthropology after first contact?

How is the claim "I am in New York only if I am in America" the same as "If I am in New York, then I am in America?

Shell script can be run only with sh command

Why is this code 6.5x slower with optimizations enabled?



Why is Collection not simply treated as Collection>


The intersection of Java generics and Scala is…not going wellWhat is reflection and why is it useful?What is a serialVersionUID and why should I use it?Java generics type erasure: when and what happens?How do I address unchecked cast warnings?Why is subtracting these two times (in 1927) giving a strange result?Why don't Java's +=, -=, *=, /= compound assignment operators require casting?Why is char[] preferred over String for passwords?Why is it faster to process a sorted array than an unsorted array?Why is printing “B” dramatically slower than printing “#”?Generic return type upper bound - interface vs. class - surprisingly valid code






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








24















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.










share|improve this question



















  • 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
    Apr 4 at 11:06












  • 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
    Apr 4 at 11:08











  • 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
    Apr 4 at 11:19






  • 4





    Collection is not equivalent to Collection<?>, it's closer to Collection<Object>...

    – Stobor
    Apr 5 at 1:36











  • You can't insert anything into a Collection<?> because you don't know what the correct type is.

    – immibis
    Apr 5 at 2:30

















24















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.










share|improve this question



















  • 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
    Apr 4 at 11:06












  • 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
    Apr 4 at 11:08











  • 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
    Apr 4 at 11:19






  • 4





    Collection is not equivalent to Collection<?>, it's closer to Collection<Object>...

    – Stobor
    Apr 5 at 1:36











  • You can't insert anything into a Collection<?> because you don't know what the correct type is.

    – immibis
    Apr 5 at 2:30













24












24








24








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.










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 4 at 11:23







dpr

















asked Apr 4 at 11:00









dprdpr

4,97311647




4,97311647







  • 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
    Apr 4 at 11:06












  • 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
    Apr 4 at 11:08











  • 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
    Apr 4 at 11:19






  • 4





    Collection is not equivalent to Collection<?>, it's closer to Collection<Object>...

    – Stobor
    Apr 5 at 1:36











  • You can't insert anything into a Collection<?> because you don't know what the correct type is.

    – immibis
    Apr 5 at 2:30












  • 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
    Apr 4 at 11:06












  • 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
    Apr 4 at 11:08











  • 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
    Apr 4 at 11:19






  • 4





    Collection is not equivalent to Collection<?>, it's closer to Collection<Object>...

    – Stobor
    Apr 5 at 1:36











  • You can't insert anything into a Collection<?> because you don't know what the correct type is.

    – immibis
    Apr 5 at 2:30







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
Apr 4 at 11:06






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
Apr 4 at 11:06














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
Apr 4 at 11:08





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
Apr 4 at 11:08













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
Apr 4 at 11:19





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
Apr 4 at 11:19




4




4





Collection is not equivalent to Collection<?>, it's closer to Collection<Object>...

– Stobor
Apr 5 at 1:36





Collection is not equivalent to Collection<?>, it's closer to Collection<Object>...

– Stobor
Apr 5 at 1:36













You can't insert anything into a Collection<?> because you don't know what the correct type is.

– immibis
Apr 5 at 2:30





You can't insert anything into a Collection<?> because you don't know what the correct type is.

– immibis
Apr 5 at 2:30












4 Answers
4






active

oldest

votes


















47














The reason is quite simple:



You may read Objects from a Collection<?> the same way as from Collection. But you can't add Objects 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.






share|improve this answer




















  • 2





    To add to this: Collection<?> is not "a Collection of any types." It's "a Collection of some type, but that type is unknown." That's why you can't add non-null objects to it: the compiler is trying to tell you that to add those objects, you'd have to know that the Collection's <T> is a superclass of those objects (whereas you don't actually know anything about T, since you typed the Collection to <?>).

    – yshavit
    2 days ago







  • 3





    Just to prevent the impression that Collection<?> was kind of immutable: you can add null to a Collection<?>, further, you can pass a Collection<?> to a generic method expecting a Collection<T>, which then may add elements of type T, i.e. duplicates of elements already in the collection. As a practical example, you can invoke Collections.swap(list, ix1, ix2) with a List<?>. And, of course, removing elements always works. But you can not add an arbitrary Object to it like with the raw typed Collection.

    – Holger
    2 days ago







  • 1





    FWIW: I think Scala's syntax for existential types may also help to understand the meaning of Collection<?>. Scala's equivalent of this is Collection[_]. And this is shorthand for Collection[T] forSome type T . The latter should be understood as This is a collection of instances of T. There is some specific type which is equal to T but which one is not known at this location in the code.

    – Feuermurmel
    2 days ago



















16














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.







share|improve this answer




















  • 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
    Apr 4 at 15:29












  • 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
    Apr 4 at 21:53



















4














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.






share|improve this answer























  • OP mentioned leaving the error in, and I agree with (both of) you.

    – jpaugh
    2 days ago











  • Well, if Collection was always treated like Collection<?>, in other words, raw types did not exist, there was no reason to discourage them. Then, insisting on <?> would be nonsense. Just like insisting on repeating types in constructor invocations like new ArrayList<VeryLongType>(). Since Java 7, you can use <> instead, but if this constructor type inference existed right from the start, even writing <> would be unnecessary.

    – Holger
    2 days ago



















3














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.






share|improve this answer

























    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
    );



    );













    draft saved

    draft discarded


















    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









    47














    The reason is quite simple:



    You may read Objects from a Collection<?> the same way as from Collection. But you can't add Objects 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.






    share|improve this answer




















    • 2





      To add to this: Collection<?> is not "a Collection of any types." It's "a Collection of some type, but that type is unknown." That's why you can't add non-null objects to it: the compiler is trying to tell you that to add those objects, you'd have to know that the Collection's <T> is a superclass of those objects (whereas you don't actually know anything about T, since you typed the Collection to <?>).

      – yshavit
      2 days ago







    • 3





      Just to prevent the impression that Collection<?> was kind of immutable: you can add null to a Collection<?>, further, you can pass a Collection<?> to a generic method expecting a Collection<T>, which then may add elements of type T, i.e. duplicates of elements already in the collection. As a practical example, you can invoke Collections.swap(list, ix1, ix2) with a List<?>. And, of course, removing elements always works. But you can not add an arbitrary Object to it like with the raw typed Collection.

      – Holger
      2 days ago







    • 1





      FWIW: I think Scala's syntax for existential types may also help to understand the meaning of Collection<?>. Scala's equivalent of this is Collection[_]. And this is shorthand for Collection[T] forSome type T . The latter should be understood as This is a collection of instances of T. There is some specific type which is equal to T but which one is not known at this location in the code.

      – Feuermurmel
      2 days ago
















    47














    The reason is quite simple:



    You may read Objects from a Collection<?> the same way as from Collection. But you can't add Objects 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.






    share|improve this answer




















    • 2





      To add to this: Collection<?> is not "a Collection of any types." It's "a Collection of some type, but that type is unknown." That's why you can't add non-null objects to it: the compiler is trying to tell you that to add those objects, you'd have to know that the Collection's <T> is a superclass of those objects (whereas you don't actually know anything about T, since you typed the Collection to <?>).

      – yshavit
      2 days ago







    • 3





      Just to prevent the impression that Collection<?> was kind of immutable: you can add null to a Collection<?>, further, you can pass a Collection<?> to a generic method expecting a Collection<T>, which then may add elements of type T, i.e. duplicates of elements already in the collection. As a practical example, you can invoke Collections.swap(list, ix1, ix2) with a List<?>. And, of course, removing elements always works. But you can not add an arbitrary Object to it like with the raw typed Collection.

      – Holger
      2 days ago







    • 1





      FWIW: I think Scala's syntax for existential types may also help to understand the meaning of Collection<?>. Scala's equivalent of this is Collection[_]. And this is shorthand for Collection[T] forSome type T . The latter should be understood as This is a collection of instances of T. There is some specific type which is equal to T but which one is not known at this location in the code.

      – Feuermurmel
      2 days ago














    47












    47








    47







    The reason is quite simple:



    You may read Objects from a Collection<?> the same way as from Collection. But you can't add Objects 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.






    share|improve this answer















    The reason is quite simple:



    You may read Objects from a Collection<?> the same way as from Collection. But you can't add Objects 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.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Apr 4 at 21:16









    Kilian Foth

    11.9k32847




    11.9k32847










    answered Apr 4 at 11:05









    LinoLino

    11.3k22344




    11.3k22344







    • 2





      To add to this: Collection<?> is not "a Collection of any types." It's "a Collection of some type, but that type is unknown." That's why you can't add non-null objects to it: the compiler is trying to tell you that to add those objects, you'd have to know that the Collection's <T> is a superclass of those objects (whereas you don't actually know anything about T, since you typed the Collection to <?>).

      – yshavit
      2 days ago







    • 3





      Just to prevent the impression that Collection<?> was kind of immutable: you can add null to a Collection<?>, further, you can pass a Collection<?> to a generic method expecting a Collection<T>, which then may add elements of type T, i.e. duplicates of elements already in the collection. As a practical example, you can invoke Collections.swap(list, ix1, ix2) with a List<?>. And, of course, removing elements always works. But you can not add an arbitrary Object to it like with the raw typed Collection.

      – Holger
      2 days ago







    • 1





      FWIW: I think Scala's syntax for existential types may also help to understand the meaning of Collection<?>. Scala's equivalent of this is Collection[_]. And this is shorthand for Collection[T] forSome type T . The latter should be understood as This is a collection of instances of T. There is some specific type which is equal to T but which one is not known at this location in the code.

      – Feuermurmel
      2 days ago













    • 2





      To add to this: Collection<?> is not "a Collection of any types." It's "a Collection of some type, but that type is unknown." That's why you can't add non-null objects to it: the compiler is trying to tell you that to add those objects, you'd have to know that the Collection's <T> is a superclass of those objects (whereas you don't actually know anything about T, since you typed the Collection to <?>).

      – yshavit
      2 days ago







    • 3





      Just to prevent the impression that Collection<?> was kind of immutable: you can add null to a Collection<?>, further, you can pass a Collection<?> to a generic method expecting a Collection<T>, which then may add elements of type T, i.e. duplicates of elements already in the collection. As a practical example, you can invoke Collections.swap(list, ix1, ix2) with a List<?>. And, of course, removing elements always works. But you can not add an arbitrary Object to it like with the raw typed Collection.

      – Holger
      2 days ago







    • 1





      FWIW: I think Scala's syntax for existential types may also help to understand the meaning of Collection<?>. Scala's equivalent of this is Collection[_]. And this is shorthand for Collection[T] forSome type T . The latter should be understood as This is a collection of instances of T. There is some specific type which is equal to T but which one is not known at this location in the code.

      – Feuermurmel
      2 days ago








    2




    2





    To add to this: Collection<?> is not "a Collection of any types." It's "a Collection of some type, but that type is unknown." That's why you can't add non-null objects to it: the compiler is trying to tell you that to add those objects, you'd have to know that the Collection's <T> is a superclass of those objects (whereas you don't actually know anything about T, since you typed the Collection to <?>).

    – yshavit
    2 days ago






    To add to this: Collection<?> is not "a Collection of any types." It's "a Collection of some type, but that type is unknown." That's why you can't add non-null objects to it: the compiler is trying to tell you that to add those objects, you'd have to know that the Collection's <T> is a superclass of those objects (whereas you don't actually know anything about T, since you typed the Collection to <?>).

    – yshavit
    2 days ago





    3




    3





    Just to prevent the impression that Collection<?> was kind of immutable: you can add null to a Collection<?>, further, you can pass a Collection<?> to a generic method expecting a Collection<T>, which then may add elements of type T, i.e. duplicates of elements already in the collection. As a practical example, you can invoke Collections.swap(list, ix1, ix2) with a List<?>. And, of course, removing elements always works. But you can not add an arbitrary Object to it like with the raw typed Collection.

    – Holger
    2 days ago






    Just to prevent the impression that Collection<?> was kind of immutable: you can add null to a Collection<?>, further, you can pass a Collection<?> to a generic method expecting a Collection<T>, which then may add elements of type T, i.e. duplicates of elements already in the collection. As a practical example, you can invoke Collections.swap(list, ix1, ix2) with a List<?>. And, of course, removing elements always works. But you can not add an arbitrary Object to it like with the raw typed Collection.

    – Holger
    2 days ago





    1




    1





    FWIW: I think Scala's syntax for existential types may also help to understand the meaning of Collection<?>. Scala's equivalent of this is Collection[_]. And this is shorthand for Collection[T] forSome type T . The latter should be understood as This is a collection of instances of T. There is some specific type which is equal to T but which one is not known at this location in the code.

    – Feuermurmel
    2 days ago






    FWIW: I think Scala's syntax for existential types may also help to understand the meaning of Collection<?>. Scala's equivalent of this is Collection[_]. And this is shorthand for Collection[T] forSome type T . The latter should be understood as This is a collection of instances of T. There is some specific type which is equal to T but which one is not known at this location in the code.

    – Feuermurmel
    2 days ago














    16














    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.







    share|improve this answer




















    • 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
      Apr 4 at 15:29












    • 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
      Apr 4 at 21:53
















    16














    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.







    share|improve this answer




















    • 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
      Apr 4 at 15:29












    • 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
      Apr 4 at 21:53














    16












    16








    16







    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.







    share|improve this answer















    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.








    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Apr 4 at 11:20

























    answered Apr 4 at 11:08









    Ondra K.Ondra K.

    978726




    978726







    • 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
      Apr 4 at 15:29












    • 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
      Apr 4 at 21:53













    • 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
      Apr 4 at 15:29












    • 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
      Apr 4 at 21:53








    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
    Apr 4 at 15:29






    "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
    Apr 4 at 15:29














    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
    Apr 4 at 21:53






    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
    Apr 4 at 21:53












    4














    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.






    share|improve this answer























    • OP mentioned leaving the error in, and I agree with (both of) you.

      – jpaugh
      2 days ago











    • Well, if Collection was always treated like Collection<?>, in other words, raw types did not exist, there was no reason to discourage them. Then, insisting on <?> would be nonsense. Just like insisting on repeating types in constructor invocations like new ArrayList<VeryLongType>(). Since Java 7, you can use <> instead, but if this constructor type inference existed right from the start, even writing <> would be unnecessary.

      – Holger
      2 days ago
















    4














    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.






    share|improve this answer























    • OP mentioned leaving the error in, and I agree with (both of) you.

      – jpaugh
      2 days ago











    • Well, if Collection was always treated like Collection<?>, in other words, raw types did not exist, there was no reason to discourage them. Then, insisting on <?> would be nonsense. Just like insisting on repeating types in constructor invocations like new ArrayList<VeryLongType>(). Since Java 7, you can use <> instead, but if this constructor type inference existed right from the start, even writing <> would be unnecessary.

      – Holger
      2 days ago














    4












    4








    4







    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.






    share|improve this answer













    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.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Apr 4 at 11:05









    T.J. CrowderT.J. Crowder

    699k12312431341




    699k12312431341












    • OP mentioned leaving the error in, and I agree with (both of) you.

      – jpaugh
      2 days ago











    • Well, if Collection was always treated like Collection<?>, in other words, raw types did not exist, there was no reason to discourage them. Then, insisting on <?> would be nonsense. Just like insisting on repeating types in constructor invocations like new ArrayList<VeryLongType>(). Since Java 7, you can use <> instead, but if this constructor type inference existed right from the start, even writing <> would be unnecessary.

      – Holger
      2 days ago


















    • OP mentioned leaving the error in, and I agree with (both of) you.

      – jpaugh
      2 days ago











    • Well, if Collection was always treated like Collection<?>, in other words, raw types did not exist, there was no reason to discourage them. Then, insisting on <?> would be nonsense. Just like insisting on repeating types in constructor invocations like new ArrayList<VeryLongType>(). Since Java 7, you can use <> instead, but if this constructor type inference existed right from the start, even writing <> would be unnecessary.

      – Holger
      2 days ago

















    OP mentioned leaving the error in, and I agree with (both of) you.

    – jpaugh
    2 days ago





    OP mentioned leaving the error in, and I agree with (both of) you.

    – jpaugh
    2 days ago













    Well, if Collection was always treated like Collection<?>, in other words, raw types did not exist, there was no reason to discourage them. Then, insisting on <?> would be nonsense. Just like insisting on repeating types in constructor invocations like new ArrayList<VeryLongType>(). Since Java 7, you can use <> instead, but if this constructor type inference existed right from the start, even writing <> would be unnecessary.

    – Holger
    2 days ago






    Well, if Collection was always treated like Collection<?>, in other words, raw types did not exist, there was no reason to discourage them. Then, insisting on <?> would be nonsense. Just like insisting on repeating types in constructor invocations like new ArrayList<VeryLongType>(). Since Java 7, you can use <> instead, but if this constructor type inference existed right from the start, even writing <> would be unnecessary.

    – Holger
    2 days ago












    3














    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.






    share|improve this answer





























      3














      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.






      share|improve this answer



























        3












        3








        3







        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.






        share|improve this answer















        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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Apr 4 at 11:12









        T.J. Crowder

        699k12312431341




        699k12312431341










        answered Apr 4 at 11:07









        Ashishkumar SinghAshishkumar Singh

        2,49411127




        2,49411127



























            draft saved

            draft discarded
















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Club Baloncesto Breogán Índice Historia | Pavillón | Nome | O Breogán na cultura popular | Xogadores | Adestradores | Presidentes | Palmarés | Historial | Líderes | Notas | Véxase tamén | Menú de navegacióncbbreogan.galCadroGuía oficial da ACB 2009-10, páxina 201Guía oficial ACB 1992, páxina 183. Editorial DB.É de 6.500 espectadores sentados axeitándose á última normativa"Estudiantes Junior, entre as mellores canteiras"o orixinalHemeroteca El Mundo Deportivo, 16 setembro de 1970, páxina 12Historia do BreogánAlfredo Pérez, o último canoneiroHistoria C.B. BreogánHemeroteca de El Mundo DeportivoJimmy Wright, norteamericano do Breogán deixará Lugo por ameazas de morteResultados de Breogán en 1986-87Resultados de Breogán en 1990-91Ficha de Velimir Perasović en acb.comResultados de Breogán en 1994-95Breogán arrasa al Barça. "El Mundo Deportivo", 27 de setembro de 1999, páxina 58CB Breogán - FC BarcelonaA FEB invita a participar nunha nova Liga EuropeaCharlie Bell na prensa estatalMáximos anotadores 2005Tempada 2005-06 : Tódolos Xogadores da Xornada""Non quero pensar nunha man negra, mais pregúntome que está a pasar""o orixinalRaúl López, orgulloso dos xogadores, presume da boa saúde económica do BreogánJulio González confirma que cesa como presidente del BreogánHomenaxe a Lisardo GómezA tempada do rexurdimento celesteEntrevista a Lisardo GómezEl COB dinamita el Pazo para forzar el quinto (69-73)Cafés Candelas, patrocinador del CB Breogán"Suso Lázare, novo presidente do Breogán"o orixinalCafés Candelas Breogán firma el mayor triunfo de la historiaEl Breogán realizará 17 homenajes por su cincuenta aniversario"O Breogán honra ao seu fundador e primeiro presidente"o orixinalMiguel Giao recibiu a homenaxe do PazoHomenaxe aos primeiros gladiadores celestesO home que nos amosa como ver o Breo co corazónTita Franco será homenaxeada polos #50anosdeBreoJulio Vila recibirá unha homenaxe in memoriam polos #50anosdeBreo"O Breogán homenaxeará aos seus aboados máis veteráns"Pechada ovación a «Capi» Sanmartín e Ricardo «Corazón de González»Homenaxe por décadas de informaciónPaco García volve ao Pazo con motivo do 50 aniversario"Resultados y clasificaciones""O Cafés Candelas Breogán, campión da Copa Princesa""O Cafés Candelas Breogán, equipo ACB"C.B. Breogán"Proxecto social"o orixinal"Centros asociados"o orixinalFicha en imdb.comMario Camus trata la recuperación del amor en 'La vieja música', su última película"Páxina web oficial""Club Baloncesto Breogán""C. B. Breogán S.A.D."eehttp://www.fegaba.com

            Vilaño, A Laracha Índice Patrimonio | Lugares e parroquias | Véxase tamén | Menú de navegación43°14′52″N 8°36′03″O / 43.24775, -8.60070

            Cegueira Índice Epidemioloxía | Deficiencia visual | Tipos de cegueira | Principais causas de cegueira | Tratamento | Técnicas de adaptación e axudas | Vida dos cegos | Primeiros auxilios | Crenzas respecto das persoas cegas | Crenzas das persoas cegas | O neno deficiente visual | Aspectos psicolóxicos da cegueira | Notas | Véxase tamén | Menú de navegación54.054.154.436928256blindnessDicionario da Real Academia GalegaPortal das Palabras"International Standards: Visual Standards — Aspects and Ranges of Vision Loss with Emphasis on Population Surveys.""Visual impairment and blindness""Presentan un plan para previr a cegueira"o orixinalACCDV Associació Catalana de Cecs i Disminuïts Visuals - PMFTrachoma"Effect of gene therapy on visual function in Leber's congenital amaurosis"1844137110.1056/NEJMoa0802268Cans guía - os mellores amigos dos cegosArquivadoEscola de cans guía para cegos en Mortágua, PortugalArquivado"Tecnología para ciegos y deficientes visuales. Recopilación de recursos gratuitos en la Red""Colorino""‘COL.diesis’, escuchar los sonidos del color""COL.diesis: Transforming Colour into Melody and Implementing the Result in a Colour Sensor Device"o orixinal"Sistema de desarrollo de sinestesia color-sonido para invidentes utilizando un protocolo de audio""Enseñanza táctil - geometría y color. Juegos didácticos para niños ciegos y videntes""Sistema Constanz"L'ocupació laboral dels cecs a l'Estat espanyol està pràcticament equiparada a la de les persones amb visió, entrevista amb Pedro ZuritaONCE (Organización Nacional de Cegos de España)Prevención da cegueiraDescrición de deficiencias visuais (Disc@pnet)Braillín, un boneco atractivo para calquera neno, con ou sen discapacidade, que permite familiarizarse co sistema de escritura e lectura brailleAxudas Técnicas36838ID00897494007150-90057129528256DOID:1432HP:0000618D001766C10.597.751.941.162C97109C0155020