Re: A question related to type casting

On Tue, 30 Dec 2008 20:56:33 -0700, Joshua Cranmer <Pidgeot18@xxxxxxxxxxxxxxx> wrote:

Peter Duniho wrote:
The big problem that I see with non-reifiable generics is that there's no way to support value types.

Primitive types are one of Java's biggest mistakes. The inclusion of auto{un}boxing is Java's attempt to ameliorate the situation, and is probably the best that can be done.

To have added primitive types would be to make generic much more complex. Given that the distinction already had to be worked around (you couldn't put an int in a List before Java 5), the added complexity would end up being rather pointless. Auto{un}boxing in Java 5 is probably faster than what you would write yourself, and I'm guessing that the codepaths would be likely to be JIT'd more quickly and possibly even optimized out.

No. Lack of support for value types means more than just the execution overhead of the boxing. It means that you cannot even store the value type in a variable in your generic class. For example, ArrayList<T> stores the elements in an array of type T. But, there's no way for the class to use an array of ints; it has to be Integer, with each array element a reference to a boxed int, and of course for there to be a separately allocated Integer instance for each non-null array element.

A reified generic would be able to implement the array as an actual array of ints, without boxing, but more importantly by being able to allocate just the array itself and not have all these other little objects consuming the heap (which is a specific advantage of value types in general). Again, since Java doesn't have very good value type support anyway, this isn't too surprising, but it's an issue.

I agree that there are certain things that can be in the JIT compiler to help prevent it from being _too_ terribly bad, but you can never get to something as efficient as if you had a genuine, reified value-type-supporting generic.

As far as the question of working around the distinction, that's a red herring. C# didn't start out with generics; when they were introduced, they didn't make the non-generic types the same as the generic types, and so backward compatibility was a non-issue. Java _could_ have done the same.

You're correct that it would have been more complex to support generics in a reifiable way. And it's also correct to point out that, even without, generics in Java are very useful and not at all bad. But I think it's important to not express _too_ much enthusiasm for the decision process that led to generics as they are in Java now. :)

I don't know that I'd go so far as to say Java generics aren't implemented "particularly well", but I do feel that the Java implementation is inferior to the C# implementation. I understand the motivation (mainly, to make it a 100% compile-time thing only, so that it's backward-compatible with the run-time), but it does limit one's code somewhat.

Wildcards make certain reification patterns hard:

public class Cache<T> {
public T makeNewElement() {
return new T();
}
}

/* in some code */
Cache<? extends HashMap<String, String>> cache = <...>;
cache.makeNewElement();

What should makeNewElement be making a new thing of? HashMap?

There are probably even edgier cases to worry about.

You're right, because Java erases the type, it can't handle this. But C# handles this just fine.

Type parameter constraints are the equivalent of wildcards, but there are other constraints such as requiring the type parameter to have a default constructor. Since the reified generic type doesn't erase the type parameter, it has all the information it needs to successfully instantiate the actual type used as the type parameter, rather than just whatever was known when the generic type itself was coded.

Pete
.

Relevant Pages

  • Re: A question related to type casting
    ... While Java's implementation of generics isn't as complete as some would like, I think one would need to make a case, supported with engineering-oriented evidence, that they aren't implemented "particularly well". ... Granted, Java has fairly limited support for value types as it is, so this is less of a problem than it might be in another language. ... trying to make class cast exception impossible in Java is just not ...
    (comp.lang.java.programmer)
  • Re: why doesnt ruby have generics?
    ... For example an array which can only hold ... I'm taking a Java course which will be covering Generics and, ... Java, this a big part of the point of Generics: ... sense in ruby) is that they are only checked on _compile_ time. ...
    (comp.lang.ruby)
  • Re: A question related to type casting
    ... Granted, Java has fairly limited support for value types as it is, so this is less of a problem than it might be in another language. ... Another thing -- as I mentioned before -- with the generics not being reifiable, that means that at run-time one _can_ in fact do casts that aren't type safe. ... One other drawback is the lack of any elegant way to reflect on a generic type in a way that reveals the type parameter used. ...
    (comp.lang.java.programmer)
  • Re: A question related to type casting
    ... but with the lack of support for value types. ... But even if generics just supported reified types using the built-in primitive types, ... not being familiar enough with the specific jargon of compiler warnings and errors for Java. ... The only reason the use case for Java generics doesn't encompass things supported by reifiable generics is that Java doesn't have reifiable generics. ...
    (comp.lang.java.programmer)
  • Re: A question related to type casting
    ... I've been on a kick about reified generics in Java ever since I found them. ... of implementations of certain collection interfaces in which dynamic type safety is done. ... But that's unique to those implementations; Java the language doesn't in fact provide any specific support for that, and any time one wants this behavior, they would need to implement it explicitly. ... There is also the subtle issue that if the runtime understands reified generics, the dynamic type checking is likely to be more efficient. ...
    (comp.lang.java.programmer)
Loading