Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 951741
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 15, 20262026-05-15T23:47:04+00:00 2026-05-15T23:47:04+00:00

Could someone please explain to me why there is explicit need to assign generic

  • 0

Could someone please explain to me why there is explicit need to assign generic type for ForEachLoop instance?

Why compiler complains: Type mismatch: cannot convert from element type Object to String?

JDK 1.5.0_09

import java.util.ArrayList;
import java.util.Collection;

public class ForEachLoop<T> {

public static void main(String[] args) {

    // Non functional version
    ForEachLoop f = new ForEachLoop(); 

    // Functional version
    //ForEachLoop<Integer> f = new ForEachLoop();

            // Type mismatch: cannot convert from element type Object to String
    for(String a : f.getStrings()) {
        System.out.println(a);
    }
}

public Collection<String> getStrings() {
    Collection<String> strings = new ArrayList<String>();
    strings.add("Hello");
    return strings;
}

} 
  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-15T23:47:04+00:00Added an answer on May 15, 2026 at 11:47 pm

    This is a rather common mistake:

    ForEachLoop f = new ForEachLoop(); 
    

    should be

    ForEachLoop<Something> f = new ForEachLoop<Something>();
    

    If you use the raw type (which you shouldn’t) the compiler will erase all generic information for that instance even if it’s not the type parameter T, to make it compatible with pre 1.5 code.

    Only use raw types if you’re writing for Java 1.4 or less, in which case you shouldn’t have any generics whatsoever. At the bytecode level the method returns a Collection (raw) after type erasure. Normally, if the instance has the generic type set, when you try to do get on the collection, the compiler will use the generic information to decide that it should return a String, and then at the bytecode level it automatically casts the Object it receives from the Collection to String (since it’s guaranteed to be a String). But if you use the raw type the compiler will ignore all generic information and will not automatically cast the object for you anymore.

    Edit: In the section on Raw Types there are these things:

    Another implication of the rules above
    is that a generic inner class of a raw
    type can itself only be used as a raw
    type:

    class Outer<T>{
      class Inner<S> {
        S s;
      }
    }
    

    it is not possible to access Inner as
    partially raw type (a “rare” type)

    Outer.Inner<Double> x = null; // illegal
    Double d = x.s;
    

    because Outer itself is raw, so are
    all its inner classes, including
    Inner, and so it is not possible to
    pass any type parameters to it.

    The use of raw types is allowed only
    as a concession to compatibility of
    legacy code. The use of raw types in
    code written after the introduction of
    genericity into the Java programming
    language is strongly discouraged. It
    is possible that future versions of
    the Java programming language will
    disallow the use of raw types.

    It is a compile-time error to attempt
    to use a type member of a
    parameterized type as a raw type.

    This means that the ban on “rare”
    types extends to the case where the
    qualifying type is parameterized, but
    we attempt to use the inner class as a
    raw type:

    Outer<Integer>.Inner x = null; // illegal
    

    This is the opposite of the case we
    discussed above. There is no practical
    justification for this half baked
    type. In legacy code, no type
    parameters are used. In non-legacy
    code, we should use the generic types
    correctly and pass all the required
    actual type parameters.

    Notice that the Inner class has it’s own type parameter independent of the one of the Outer class, and it still gets erased. Basically they don’t want us mixing raw and generic types on the same instance, since it doesn’t make sense in any version (in pre 1.5, the generic part will be an error, in 1.5+ the raw type is discouraged, and may even be removed from future versions)

    Then there’s also this:

    The type of a constructor (§8.8),
    instance method (§8.8, §9.4), or
    non-static field (§8.3) M of a raw
    type C that is not inherited from its
    superclasses or superinterfaces is the
    erasure of its type in the generic
    declaration corresponding to C. The
    type of a static member of a raw type
    C is the same as its type in the
    generic declaration corresponding to
    C.

    It is a compile-time error to pass
    actual type parameters to a non-static
    type member of a raw type that is not
    inherited from its superclasses or
    superinterfaces.

    which says that constructors, instance methods and non-static fields will be treated as raw in a raw instance. Static members will be treated as generic anyway, since they don’t require an instance to be accesed.

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.