News: Walking through Generics, and side effects of Erasure

  1. Bruce Eckel has made his thoughts pretty clear when it comes to JDK 5 Generics. He doesn't like the fact that they are compiler sugar. Now he is getting past the politics and delving into the side effects that this choice leaves us with, which leads us into other parts of JDK 5.
    Let's first consider a very basic impact of erasure. If I have a type parameter T, not only am I prevented from making an instance of that type (because, with erasure, the type is forgotten), I cannot make an array of that type. However, I can generate an array of Object and cast it to T[].


    If you look through ArrayList.java, you'll find plenty more of these casts. And what happens when we compile it?

    Note: ArrayList.java uses unchecked or unsafe operations.
    Note: Recompile with -Xlint:unchecked for details.

    Sure enough, the standard libraries produce lots of warnings. So "cast-and- ignore-warnings" is the acceptable idiom for JDK 5.0. I'm told that in a future release (I'm guessing a point release of JDK 5), SuppressWarnings will be enabled, and at that point the warnings will become meaningful again.
    Read more: Puzzling Through Erasure

    From the past: Bruce Eckel Talk: Java Issues & Directions

    Threaded Messages (24)

  2. A note[ Go to top ]

    It's important to note that the expressions 'new Point[10]' and '(Point[]) new Object[10]' results in arrays of different types. They are not equivalent and can not be used the same way.
  3. Java gets horrably unreadable[ Go to top ]

    With all the advanced features, Java gets too advanced for me I guess. I find it difficult to see whats going on in the code.
  4. I don't understand why people object to the new features..
    The only thing I don't like is autoboxing..

    Generics cuold be done better, but at least we get to use them..
  5. I don't understand why people object to the new features..The only thing I don't like is autoboxing..Generics cuold be done better, but at least we get to use them..
    people are afraid of change, in IT as well as elsewhere.
    They fear being left behind by younger people who learn faster, fear having their precious certifications suddenly branding them as obsolete instead of state of the art for mentioning they're 1.4 certified.

    I have some doubts as to the usefulness of some of the new features myself, and feel that metadata is a dangerous direction to take, but I don't fear them.

    Instead I'll decide when the time comes whether they're useful to me or not and use them as seems fit.
  6. A note[ Go to top ]


    and in j2se 1.4 if you write:

    String [] sa = (String []) new Object [10];

    you get a plain ClassCastException, because the runtime type
    is "array of Object" not "array of String".


    class GenericArray<T>
        T[] ta = (T[]) new Object [10];

    works because at runtime T is erased to Object and so you don't have
    a ClassCastException.
  7. Here's why we use erasure[ Go to top ]

    Perhaps we didn't make clear the reasons for our design choices. Please see <
  8. Here's why we use erasure[ Go to top ]

    Sorry, the link is http://www.gafter.com/~neal/Erasure.html
  9. another generics article[ Go to top ]

    A similar, but more thorough walk through generics problems in java.net:

  10. More on Generics[ Go to top ]

    Dean Wette did a pretty thorough talk on Java Generics at the St. Louis Java Users Group in May. Dean touched on many more surprises of Java generics. The presentation slide can be found here.

    I tried to capture some of the sentiments of Dean's talk in this blog entry.
  11. I am getting quite concerned about the new Java features. Chasing C# isnt really doing Java any major favours in my opinion. What seems to be happening is the migration of design pattern knowledge into syntax. Sure, we can use 'generic types' to ensure the consistancy of instance types in a collection, but I already know how to do that with simple wrapper encapsulation (A standard concept that once understood is useful for hundreds of other situations also). So I have to cast down when extracting from the list, a minor annoyance that has the benefit of keeping the code verbose (My IDE does this for me anyway).

    C# has delegates, which, when you break it down is a syntax formalization of the observer pattern.

    It seems to me, that all this added syntax is doing is raising the bar for new developers to get started in the language. I have been coding in Java for nearly 6 years and I am struggling to get my head around the new feature 'end-cases'. I dread to think how the junior guys are getting on.

    IMHO Java got to where it is by being a simple language syntax-wise but with a rich set of 'best-practices' and design patterns to provide simple, elegant solutions.

    I hope I am wrong, but I have a sneaking feeling that this release will do more harm that good... time will tell I guess.
  12. I hope I am wrong, but I have a sneaking feeling that this release will do more harm that good... time will tell I guess.
    Same feeling for me. I know they were potential problems with autoboxing, and now they are also potential problems with generics. My god, does Sun want to kill Java ? I really wonder.
  13. Couldn't agree more.[ Go to top ]

    I really wished that whoever was on the JDK 5 steering committee had read Tony Hoare's "Hints on programming language design", which's based on his 1973 POPL keynote. (Here is a link http://www.cs.berkeley.edu/~necula/cs263/handouts/hoarehints.pdf)

    People who don't learn from history are doomed to repeat it. Extrapolating from the decisions made in the Tiger release, I really started to fear for java's future ...
  14. Learning from Hoare[ Go to top ]

    I really wished that whoever was on the JDK 5 steering committee had read Tony Hoare's "Hints on programming language design", which's based on his 1973 POPL keynote. (Here is a link http://www.cs.berkeley.edu/~necula/cs263/handouts/hoarehints.pdf)

    Hmm, reading that paper I would java definately draws from it's most important points. Typing, yes. Fast compilation, yes. Pointe-less variables, yes. Effecient intermediate code, yes. Simple syntax that allows syntactic errors to be detected and pinpointed to the line, yes.

    The list goes on.

    Are you trying to say java is not as simple a a general purpose language should be? Java is not a complex language. It lacks many of the idosyncrasies of other languanges, and has space for more features before it becomes hard to learn.
  15. Learning from Hoare[ Go to top ]

    I agree with your points - java as originally designed is an exemplary language in simplicity and taste.

    What worries me is the decision process at Sun.

    The basic proposal and implementation of GJ was ready back in 1998. Fortunately Goosling & Steele had the wisdom/desire/stamina to hold the line - not letting these kind of *features* into the language. People at Sun in general understood that language evolution should focus on primitives, not features.

    Then .NET come along. Being late to the game, Microsoft tried very hard to rewrite the rules to its favor. There were concerted effort at conferences, standard processes, trade pubs, Internet message boards to promote the idea that features = innovation. C# is better than java because it has more features. Remember around 2001-2002 in any technical discussion board, how many time have you seen someone innocuously drop in a line, "autoboxing in C# is blah blah"?

    Lo-and-behold, Sun fells right into the trap. Right after GJ was let into Tiger, C# came out with a bunch of gotta-have, new-and-improved features. And java vendors and developers are stuck with the unpleasant tasks of dealing with GJ. *sigh*.

    It seems java's gatekeepers are no longer there. One has to worry what'll happen to java when the decision process seems to be dominated marketing considerations.
  16. share your concern[ Go to top ]

    Developers who are entering the area are getting really bogged down by libraries. Its now has outgrown and offers way too many functionalies. They are getting confused what to use and how to use. I once talked to a junior developer who lamented that he was unable to grasp the concept of templates in C++ and is now forced to do so in Java through generics. I think sun needs to look at those 1-2 years experienced people who make up the bulk of the programming world.
  17. share your concern[ Go to top ]

    The risk in not improving the libraries and language is obsolescense. C++ really extended the life of C by many years.

    VB had to go because of its shortcomings.

    The Java language needs to add features (I agree that some of the ones in Java 5.0 are lame); the ever-present demand for more productivity requires it. A more expressive language can make things more complex but can yield cheaper/better applications.

    I'm all for a better Java language or a replacement of the Java language.
  18. share your concern[ Go to top ]

    I'm all for a better Java language or a replacement of the Java language.
    We all want a better Java language. I don't have bad feelings about the new features. In fact, I like the idea to have generics, metadata, autoboxing, ... (and this since I've read a book about C# a few years ago). But I have bad feelings about the way these features have been added to the Java language. As Microsoft did with C#, Sun could have thrown the compatibility by adding a keyword like "unmanaged" when calling old code and this would have allowed for a cleaner implementation of these new features in the JVM.
  19. share your concern[ Go to top ]

    I think sun needs to look at those 1-2 years experienced people who make up the bulk of the programming world.
    Are you serious? it is 2004 almost 2005. even Dotcomers after "Java in 24 hours" are in IT for 4-6 years...
    Nope. Language and APIs should target experts, because small team of experts with appropriate tools can do projects, which even huge gang of greenhorns simply cannot.

    PS: I do not like some upcoming changes in Java too...
  20. This is one of those issues that make you go Doh! If something is added to Java it should be well thought out and complete. This erasure stuff causes extra head aches and complexity to the language. To me it only looks like a big kludge, not a language-worthy feature.

    If backwards compatibility is an issue, then do not include such silliness to Java at all. If the feature is really useful and should be part of Java, then God Damn, break the backwards compatibility and add a flag to the compiler/VM to handle the old stuff.
  21. All the complexity of templates...[ Go to top ]

    And none of the performance improvements...
  22. Please educate me[ Go to top ]

    And none of the performance improvements...
    To what performance improvements do you refer?

    Probably not the runtime casts; even my laptop Windos PC can do four hundred million of those per second.

    What kind of performance numbers do you get? (You _do_ measure and not just guess, right?)
  23. Please educate me[ Go to top ]

    Do you know of performance improvements I am not aware of?
  24. - Try to add Graph collections to the current collections library. Many real world problems would benefit from a concise graph theoretic solution; thats why people draw diagrams when trying to understand. Every algorithm you can think of returns nested collections of some sort:

    Depth first search returns: Graph -> List of Vertex
    Strongly connected components: Graph -> Set of Graph
    Shortest path by edge: Graph of WeightedEdge -> List of WeightedEdge

    But, it's not so helpful if you lose the type information at runtime.

    - AspectOriented containers / Middleware. Try to grab any arbitrary object in memory and remote it out by merely specifying an endpoint to remote it to. (For instance, a SOAP service that if you do a .bind(url,object), then it will generate WSDL and respond to request for that object). If you actually designed this object to take advantage of collections, by using List,Set, Map in the interfaces.... (think of Hibernate classes) ... then the container will be at a loss when it encounters such collections.

    - Visual Modelling. Throw a jar file into your IDE, and if you have first class generics (without erasure), then it can discern that: Employee has a one to many relationship to Employee because of the List<Employee> typed member. With type erasure, your APIs might be just a giant amorphous hub around Object, List, and Map with no obvious relationships between objects. And we all know that Visual Modelling tools that lose the intent of what you are doing and get out of sync just don't get used as much as management would like.

    Now imagine Microsoft building these sorts of capabilities off of its first class generics; they will.

    There seems to be a curious relationship between making design patterns part of the language, incorporating "generics" (type parameterization), and AOP... Hopefully when the Java spec or its successors get around to dealing with the type erasure issue, we will be further along in thinking about a single mechanism that can simplify all these inter-related problems.

    It seems that where we are headed is to operating systems in which all code is VM based... where you can select an arbirary object from a process and apply remoting/logging aspects to it, or to graph its static/runtime structure. Type parameterization seems to play a big role in enabling this to be done properly.
  25. Are there any good articles or blogs supporting Java generics? I would like to get the other perspective.