Discussions

News: Java Generics a Step Closer?

  1. Java Generics a Step Closer? (13 messages)

    Sun has released another early access version of the JSR 14 "Generics for Java". Generics are expected to be delivered with the J2SE "Tiger" release. The early access allows you to play with Generics now.

    Find information here:

    Sun: Prototype for JSR014: Adding Generics to the JavaTM Programming Language v. 1.3

    WebLog: Ted Newards comments

    JSR 14: Add Generic Types To The JavaTM Programming Language

    Threaded Messages (13)

  2. Java Generics a Step Closer?[ Go to top ]

    JSR14 has been available for quite some time now. Good to hear that there is an upgrade -- even when the last build I've downloaded was working fine so long.

    Anyway, I'll go hunting for the changelog :)
  3. Java Generics a Step Closer?[ Go to top ]

    Fun! I can't wait for this to be rolled in. I would prefer an implementation that didn't need to be backword compatible (a List<String> should _not_ be assignable to a List), but I can understand the reasoning.
  4. Java Generics a Step Closer?[ Go to top ]

    It will be interesting to see this as "the norm".
    When things like this are added to a language, you tend to see a lot of best practices and design patterns come from them, and people get inspired / a bit more excited at using something new.
  5. Fun! I can't wait for this to be rolled in. I would

    > prefer an implementation that didn't need to be
    > backword compatible (a List<String> should _not_ be
    > assignable to a List), but I can understand the
    > reasoning.

    Why not? Isn't a List<String> of type List?
  6. Why not? Isn't a List<String> of type List?


    If List<String> were of type List you would have the following weirdness.

    The following is illegal and caught at compile-time.

      List<String> stringList = ...;

      stringList.add(new Integer(0));

    But the following would not be caught at compile-time

      List<String> stringList = ...;
      List list = stringList;

      list.add(new Integer(0));

    So the code in the second case would corrupt the original stringList by putting a non-String in it.
  7. Java Generics a Step Closer?[ Go to top ]

    So the code in the second case would corrupt the original > stringList by putting a non-String in it.


    But this is nothing new:
    String[] stringArray = new String[] { "0", "1" };
    Object[] objectArray = stringArray; // no CompilerError
    objectArray[0] = new Integer(0); // no CompilerError
    // but ArrayStoreException at runtime

    As far as i have understood the spec, List<String>
    will not be silently corrupted, but will throw
    a ClassCastException, so you won't be more unsafe
    as you are with arrays now.

    The real key point is whether the design of your
    generic class honors the (sometimes attributed to
    Barbara Liskov) Substitution Principle (LSP),i.e.
    will a Generic<Subtype> under all circumstances
    behave like a Generic<Supertype>.

    Collection<Object> for example promises you the
    add(Object object) method, which Collection<String>
    will not provide as promised, what may cause more
    trouble than one might expect on first look.

    But as in general generic classes might be designed
    properly it is better to allow things like
    Generic<SuperType> var = new Generic<SubType>
    (and List ist just a shorthand for List<Object>)

    I guess it would need some AI for the compiler
    to check source for compliance with the LSP.
  8. Java Generics a Step Closer?[ Go to top ]

    "...I guess it would need some AI for the compiler
    to check source for compliance with the LSP...."

    Well, SOME people think that the intelligence built into C++ compilers is highly artificial...

    ;-)
  9. Fun?[ Go to top ]

    Fun? You are a complete geek and a disgrace to the human race.
  10. Java Generics a Step Closer?[ Go to top ]

    Looks and I am looking forward to have this feature in standard JDK.
    One thing is really is a pity...that primitive types are not allowed as parameters so you still have this "spaghetti" code which decreases performance:

    int i = 9;
    ...
    List<Integer> iList= new List<Integer>();
    iList.add(new Integer(i));
    ...
    int j = iList.elementAt(0).intValue();

    Ok, we saved one cast, but you still have to generate a lot of useless wrapper classes and calls to intValue().

    So with Java Generics we have more type safety at compile time and we need less casts, but in my opinion it is still not as powerful as C++ Templates.

    Can anybody explain me what this means:
    "To enable a direct mapping into the class file format of the JVM, type variables are not allowed in
    catch clauses..."

    Does this mean, that this is not allowed:

    try {
      List<String> iList = new List<String>();
      ..
    } catch(Exception e) {
      iList.elementAt(x); // ERROR???
    }

    Thanks,
    Mirko
  11. Java Generics a Step Closer?[ Go to top ]

    That code is not compilable anyway. The iList is declared inside the try { } catch statement.
  12. Java Generics a Step Closer?[ Go to top ]

    Ok. Maybe this is clearer:

    List<String> iList = new List<String>();
    try {
      ...
    } catch(Exception e) {
      iList.elementAt(x); // ERROR???
    }


    ...how did you know that iList wasn't declared twice somewhere outside the code-snippet? :-)

    Thanks,
    Mirko Novakovic
    :wq
  13. Java Generics a Step Closer?[ Go to top ]

    I think they are referring to something like:

    try {
    ...} catch (MyGenericException<Something> e) {
    }
  14. Java Generics a Step Closer?[ Go to top ]

    Yeah, I think ender is correct, they are just saying that parameterized exceptions isn't handled, which seems to be fine in my book, I think the main advantage to generics is dealing with collection-oriented problems.

    -Chris