Slashdot Mirror


Sun to Add Variance to Java in 1.5?

Ahe writes "I have been working on a joint project between Sun Microsystems, The University of Aarhus, and The Alexandra Institute. As you might know, Sun has for long been commited to adding generics to Java. Our project was to extend this with variance annotations for more flexible typing of parameterized classes and arrays. Recently Sun has released the project result as a new prototype with variance. If you like variance, please vote for this bug."

6 of 55 comments (clear)

  1. Somebody understood something ? by IIEFreeMan · · Score: 2, Interesting

    I did not but I would be interested to learn (I know what generics are but not variance)

    Thanks

    1. Re:Somebody understood something ? by Anonymous Coward · · Score: 1, Interesting

      I'm all for variance because it is complicated and ugly. C++ is complicated and ugly and it looks like Java and C# will move even further in that direction.

      Features like these will only hasten the move towards dynamically typed languages like Python, Smalltalk, Ruby, and CLOS.

      Dynamic typing may some dangerous, but the main thing that static typing prevents: calling a function that doesn't exist, happens in code about as often as dereferencing a null pointer. We don't see people shoveling syntax and static checking into languages to prevent that error, do we?

  2. Re:Definitely a bug! by DeadSea · · Score: 4, Interesting
    I can see myself using generics when designing APIs. Lets say that I currently have a method that returns a list of Strings. Internally I store those Strings in a Vector so that I can add to it easily. I want users to be able to access these Strings so I create a getStrings() method. Since want the user to know that they are Strings and not have to do any casting I currently do something like this:

    public String[] getStrings(){
    String[] s = new String[vector.size()];
    return vector.toArray(s);
    }

    Maybe in the future I could just store them in a list and return that list because it is a string list specifically:

    public List<String> getStrings(){
    return list;
    }
  3. Re:Definitely a bug! by scrytch · · Score: 3, Interesting

    Unfortunately, since Java's generics act solely through type erasure, you're still screwed -- all Java generics do is insert invisible casts into your code, with all the overhead you expect from that. Type erasure is overall a good thing -- the fact that Foo is a subclass of Foo is very useful, and lets you avoid many of the ugly traits hacks in C++, and it does give good hints to the compiler, but at the same time, lack of a typedef also removes many of the things that are still useful in traits classes, and all the extra casts you don't see still cost as much as the ones you write by hand.

    The current release of jsr104 will even create mysterious ClassCastExceptions in some cases because the type inference is unsound. The documentation even warns of being able to do invalid casts (e.g. a String to a JFrame), which casts doubt on the safety of the complier. If that's the case, you can be sure that the jsr104 compiler is going to have one or more of its features axed before it makes it into tiger.

    --
    I've finally had it: until slashdot gets article moderation, I am not coming back.
  4. Re:Definitely a bug! by elflord · · Score: 5, Interesting
    Generics are at best a trade-off: compile-time type safety in exchange for less readable code.

    Given the choice between explicitly using a parameter, and using a nebulous "Object", I'd say that the template code is easier to read, because the parameter conveys more meaning than the word "object" (which offers no clue about what "type" is being used)

    Where C++ has no safety without generics, Java has runtime safety.

    Wrong. See dynamic_cast.

    As for readability, C++ has two major benefits over Java: a preprocessor and typedefs

    Shows how much you know -- you've named what are arguably two of the most botched legacy features of C++.

    Without at least one of these features, generics make code almost unreadable.

    This is not true. What makes code difficult to comprehend is complexity (allocaters, classes with several parametrised types, etc). Fortunately, C++ offers features that make complexity manageable (though typedefs don't deal with templates as well as they should)

    (I say mostly, because using STL with threads in cross-platform development is a recipe for disaster

    No, naively assuming that every STL implementation on every platform is thread safe is a recipe for disaster. Well, duh! The same is true even for straight C code -- you need to use thread safe versions of the library functions.

  5. Generics more readable by AT · · Score: 4, Interesting

    Huh? Generics make code more readable!

    When using non-generic containers in Java, you are usually forced to make a cast when accessing its members. For example:

    String s = (String) list.get(0);

    It gets worse if you are making multiple calls, because you usually need parentheses to bind the cast:

    String s = ((Foo) list.get(0)).fooMethod();

    However, with generics, you don't have to write the cast, because the type is implied. The bytecode is the same, but the code is much clearer:

    String s = list.get(0).fooMethod();

    Tell me how that is less readable. Anybody who thinks generics are unreadable is probably thinking of the worst C++ template abuses, needless complexity, and obscure syntax. Thankfully, Java generics are simple and clear.