Java
  Home arrow Java arrow Page 8 - Generics of Java 1.5 Tiger
Dev Articles Forums 
ADO.NET  
Apache  
ASP  
ASP.NET  
C#  
C++  
ColdFusion  
COM/COM+  
Delphi-Kylix  
Design Usability  
Development Cycles  
DHTML  
Embedded Tools  
Flash  
Graphic Design  
HTML  
IIS  
Interviews  
Java  
JavaScript  
MySQL  
Oracle  
Photoshop  
PHP  
Reviews  
Ruby-on-Rails  
SQL  
SQL Server  
Style Sheets  
VB.Net  
Visual Basic  
Web Authoring  
Web Services  
Web Standards  
XML  
Mobile Linux 
App Generation ROI 
IBM® developerWorks 
Sun Developer Network 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
JAVA

Generics of Java 1.5 Tiger
By: O'Reilly Media
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 5 stars5 stars5 stars5 stars5 stars / 15
    2005-05-26

    Table of Contents:
  • Generics of Java 1.5 Tiger
  • Using Type-Safe Maps
  • Iterating Over Parameterized Types
  • Accepting Parameterized Types as Arguments
  • Returning Parameterized Types
  • Checking for Lint
  • Generics and Type Conversions
  • Using Type Wildcards
  • Writing Generic Types
  • Restricting Type Parameters

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT


    Generics of Java 1.5 Tiger - Using Type Wildcards


    (Page 8 of 10 )

    So now you’ve got generic types figured out, and even understand all the unchecked warnings your code is generating. Still, here are times when you really do want a plain old List, or Map, or whatever, without parameterization. This is going to result in unchecked errors, unless you employ the generics wildcard.

    While I’m sure
    plenty of folks
    disagree, I think production code
    shouldn’t issue warnings.

    How do I do that?

    To illustrate the problem, here’s a really simple method that prints out all the members of a List:

      public void printList(List list, PrintStream out) throws IOException {
        for (Iterator i = list.iterator(); i.hasNext( ); ){
          out.println(i.next().toString());
        }
      }

    Since writing this,
    later versions of
    the compiler don’t
    throw warnings
    here. Still, it
    makes a good
    point, so I’ve left
    it in for you.

    The problem is that this generates unchecked warnings, something you
    should avoid whenever possible. What you’re really saying, though, is
    that printList() takes any List. This is where the wildcard operator
    comes in, which for generics is a question mark (?). Make the following
    change:

      public void printList(List<?> list, PrintStream out) throws IOException {
        for (Iterator<?> i = list.iterator(); i.hasNext( ); ) {
          out.println(i.next().toString());
        }
      }

    You’ve now expressed in syntax what you meant—any type is acceptable, and the unchecked warnings go away.

    What about…

    …using List<Object> to get around this same problem? You might want to review “Generics and Type Conversions,” and see if you really want to do that. A List<Integer> cannot be passed to a method that takes a List<Object>, remember? So your printList() method would be limited to collections defined as List<Object>, which isn’t much use at all. In these cases, the wildcard really is the only viable solution.

    You should also be thinking about the declaration of methods in classes like this:

      public interface List<E> {
        public E get();
        public void add(E value);
      }

    You would read
    this as a “list of
    unknown”.

    Since you’ve declared the list as a List<?>, get() now returns an Object, which is as close to “unknown” as Java gets. At the same type, this is very different from a List<Object>, which can only work with Objects. Where things get even odder is for the add() and other methods that take a parameter that matches the type of the collection. Since the compiler cannot check to ensure type-safety, it rejects any call to add(), addAll(), and set() for a List<?>. In other words, supplying the wildcard to a generic type effectively makes it read-only.

    More Java Articles
    More By O'Reilly Media


       · List<Integer> ints = new ArrayList<Integer>();ints.add(1);ints.add(2);// This...
       · public static int biggest(Box<T> box1, Box<U> box2) { int box1Size =...
     

    Buy this book now. This article was taken from chapter two of Java 1.5 Tiger: A Developer's Notebook, written by Brett McLaughlin and David Flanagan (O'Reilly, 2004; ISBN: 0596007388). Check it out at your favorite bookstore. Buy this book now.

    JAVA ARTICLES

    - Deploying Multiple Java Applets as One
    - Deploying Java Applets
    - Understanding Deployment Frameworks
    - Database Programming in Java Using JDBC
    - Extension Interfaces and SAX
    - Entities, Handlers and SAX
    - Advanced SAX
    - Conversions and Java Print Streams
    - Formatters and Java Print Streams
    - Java Print Streams
    - Wildcards, Arrays, and Generics in Java
    - Wildcards and Generic Methods in Java
    - Finishing the Project: Java Web Development ...
    - Generics and Limitations in Java
    - Getting Started with Java Web Development in...






    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 4 hosted by Hostway
    Stay green...Green IT