6 ms·

Too bad they are still pretty much useless in many cases because of type erasure, and many type constraints cannot be expressed (eg. constructor constraints)...

Too bad they are still pretty much useless in many cases because of type erasure, and many type constraints cannot be expressed (eg. constructor constraints)... Still way better than no generics at all, but if you are used to better implementations these random limitations can be really painful..

cel1ne 10y ago
Kotlin, which is 100% java-interoperable has much nicer generics (declaration-site variance and type projections instead of wildcards). https://kotlinlang.org/docs/reference/generics.html https://kotlinlang.org/docs/reference/generics.html
- rsmckinney 10y ago
  Take a look at Gosu. It provides: - Reification - Declaration-site generics - Default covariance when variance not specified - Variance inference! In practice default covariance is usually the most suitable; it's the pragmatic approach. But you can make a generic type super sound, if that's what you need. And with variance inference your generic type can safely inherit from generic Java types. http://gosu-lang.github.io/2015/11/22/threading-the-needle.html http://gosu-lang.github.io/2015/11/22/threading-the-needle.h...
  - pekk 10y ago
    Is there a reason to take a look at Gosu instead of Kotlin?
    - rsmckinney 10y ago
      You mean aside from it providing better and easier generics support? I personally like Kotlin, but I think Gosu has some advantages that should not be overlooked e.g,. Generics support.
      - oweiler 10y ago
        The problem with Gosu is that it never gained any significant traction.
alimbada 10y ago
Don't know why this is being downvoted. I've been on a Java project for the last ~6 months after ~8 years of doing C#/.NET development. My brain hurts from seeing all the stupid workarounds in Java because it doesn't have real generics.
- the_af 10y ago
  I guess it's one thing to claim Java generics have problems and another to claim they are "useless". They are a big improvement over not having generics and, in my experience, one seldom sees those workarounds you mentioned. Sure, when they are necessary they are ugly... but how often are they needed in standard application code?
  - kodfodrasz 10y ago
    Last week wanted to use GSON in a generic method to deserialize to a type which is generic type parameter, in a method of the abstract base class. Unfortunately it could not be done without the implementations passing up their .class via super constructor. IMHO deserializing JSON is quite a common application code. If you are really interrested I'd create example code, but (as being lazy, and the mentioned code not being my property) I'd hope to take my word for granted :) edit: I wrote useless in many cases!
    - deleted 10y ago
      [deleted]
    - slantedview 10y ago
      There are ways to resolve generics declared on base classes: https://github.com/jhalterman/typetools https://github.com/jhalterman/typetools ...but proper support of reified generics certainly would have been better.
  - dpark 10y ago
    > I guess it's one thing to claim Java generics have problems and another to claim they are "useless". I guess that's why the original comment said useless in many cases. Not completely useless. The next sentence also said they are way better than no generics.
vvanders 10y ago
Or my personal favorite where intrinsic types aren't objects so I can't use them in generics with makes the whole Lambda/Stream api a complete disaster. Sure, I could use Integer/etc, but now each stage of my transform is creating a ton of garbage and I no longer get data locality.
- aardvark179 10y ago
  Keep an eye on project Valhalla.
curried_haskell 10y ago
After spending several years programming with Scala and Haskell, doing back to Java feels like being placed in a straightjacket.
galdosdi 10y ago
Eh, there are hacks around both of those... Gratuitous "typedef classes" for the first problem (instead of using a List<Sandwich> when you want runtime to be able to sniff the type, declare a class/interface SandwichList extends List<Sandwich> and use that) and just wrapping static factory methods around constructors to handle the generic part (to handle the second problem) Admittedly this is a little annoying, possibly even "really painful" so this doesn't really contradict your view... I don't find it really painful, just a little annoying, but that could be because I haven't used C# or another language people say has better generics so I don't know what I'm missing...
kailuowang 10y ago
I actually think type erasure might even be the right way to implement generics. You see, the point of static types is to provide compilation time check. That is, types are compilation time concern. So yeah, type erasure did introduce some inconvenience but if you need to access them during runtime, either you did it wrong or the compiler fails at some point. So, claiming type erasure making generic useless is a false argument.
- eternalban 10y ago
  Pretty sure the scope of the generic stage is the compilation unit.
- kodablah 10y ago
  Not to mention, having type erasure made them backwards compatible with non-generic implementations. I don't think it would have been acceptable to break old Java code or introduce an entirely new collections library like .Net did.
- gpderetta 10y ago
  I think that the problem with Java is not that they are implemented with type erasure (many functional languages do the same and monomorphize only when optimizing), the issue is that this implementation detail is a leaky abstraction in Java.
- MereInterest 10y ago
  Type erasure also makes some forms of function overloading impossible. void func(List<ClassA> list); void func(List<ClassB> list); Using type erasure, I cannot specify functions that are overloaded based on the generic type of an argument. To the runtime, both of these accept an argument of type List<Object>, and so it is ambiguous which one to call. In C++, which does not use type erasure, this sort of function overloading works as expected.
joegaudet 10y ago
Said much more clearly than I could: http://stackoverflow.com/questions/20918650/what-are-the-benefits-of-javas-types-erasure http://stackoverflow.com/questions/20918650/what-are-the-ben...
bitmapbrother 10y ago
If it weren't for type erasure we wouldn't have the abundance of dynamic languages on the JVM. Developing dynamic languages on runtimes that have reified generics is a PIA.
- WorldMaker 10y ago
  IronPython, IronRuby, and plenty more dynamic languages on the CLR which has reified generics certainly disagree with your opinion here. If anything, my opinion is that the abundance of so many dynamic languages on the JVM, and the active use of those dynamic languages in JVM projects, has much more to do with how no one really wants to work in Java than anything to do with how generics work (or don't work) in the JVM.
acjohnson55 10y ago
Java generics are cumbersome for sure, but if they're useless, it's not because of type erasure. As a Scala programmer, I've very rarely run into a situation where type-erasure has been an inconvenience.
bad_user 10y ago
You don't need reified generics with a more powerful type system. You might be feeling that C# .NET is better than Java, but it's actually a symptom that C#'s type-system also sucks. Basically whenever you have to do an `instanceof` check, that's a sign that the type system isn't strong enough and hence needs to be solved at runtime. One such thing missing from .NET for example are higher-kinded types. Basically people end up with the need for `instanceOf` because they aren't able to write generic code that abstracts over containers such as List[T]. And this holds back language development on top of .NET actually. There are good reasons for why alternative languages flourished on top of the JVM and not on top of .NET, in spite of its original marketing, which is a little ironic. Not the only reason mind you, other reasons where availability on Linux, having an easier time to generate bytecode along with debugging symbols, more mature tooling, etc, but having reified generics in the runtime either means that you have to limit your language (e.g. C#'s type-system with a different syntax), or it means that you have to do the type erasure yourself and always have performance problems and be considered a second class citizen. Lack of higher-kinded types is actually what's holding F# back as an FP language, because in FP there is a lot of opportunity to abstract over M[T] types, that are just not doable in a static language without HKT. And don't get me wrong, I like dynamic typing as well, but the problem with languages like Java and C# are that they are neither here, nor there, in many ways being the worst of both worlds. And the only advantage that .NET's reified generics have over Java is actually the specialization it is doing for primitives. Which is nice for performance reasons, since you avoid boxing and so on, but doing specialization doesn't necessarily need to be a runtime feature, when it can very well be a feature of the language's compiler. And we weren't talking about performance anyway.

cel1ne 10y ago

Kotlin, which is 100% java-interoperable has much nicer generics (declaration-site variance and type projections instead of wildcards). https://kotlinlang.org/docs/reference/generics.html https://kotlinlang.org/docs/reference/generics.html

rsmckinney 10y ago
Take a look at Gosu. It provides: - Reification - Declaration-site generics - Default covariance when variance not specified - Variance inference! In practice default covariance is usually the most suitable; it's the pragmatic approach. But you can make a generic type super sound, if that's what you need. And with variance inference your generic type can safely inherit from generic Java types. http://gosu-lang.github.io/2015/11/22/threading-the-needle.html http://gosu-lang.github.io/2015/11/22/threading-the-needle.h...
- pekk 10y ago
  Is there a reason to take a look at Gosu instead of Kotlin?
  - rsmckinney 10y ago
    You mean aside from it providing better and easier generics support? I personally like Kotlin, but I think Gosu has some advantages that should not be overlooked e.g,. Generics support.
    - oweiler 10y ago
      The problem with Gosu is that it never gained any significant traction.

alimbada 10y ago

Don't know why this is being downvoted. I've been on a Java project for the last ~6 months after ~8 years of doing C#/.NET development. My brain hurts from seeing all the stupid workarounds in Java because it doesn't have real generics.

the_af 10y ago
I guess it's one thing to claim Java generics have problems and another to claim they are "useless". They are a big improvement over not having generics and, in my experience, one seldom sees those workarounds you mentioned. Sure, when they are necessary they are ugly... but how often are they needed in standard application code?
- kodfodrasz 10y ago
  Last week wanted to use GSON in a generic method to deserialize to a type which is generic type parameter, in a method of the abstract base class. Unfortunately it could not be done without the implementations passing up their .class via super constructor. IMHO deserializing JSON is quite a common application code. If you are really interrested I'd create example code, but (as being lazy, and the mentioned code not being my property) I'd hope to take my word for granted :) edit: I wrote useless in many cases!
  - deleted 10y ago
    [deleted]
  - slantedview 10y ago
    There are ways to resolve generics declared on base classes: https://github.com/jhalterman/typetools https://github.com/jhalterman/typetools ...but proper support of reified generics certainly would have been better.
- dpark 10y ago
  > I guess it's one thing to claim Java generics have problems and another to claim they are "useless". I guess that's why the original comment said useless in many cases. Not completely useless. The next sentence also said they are way better than no generics.

vvanders 10y ago

Or my personal favorite where intrinsic types aren't objects so I can't use them in generics with makes the whole Lambda/Stream api a complete disaster. Sure, I could use Integer/etc, but now each stage of my transform is creating a ton of garbage and I no longer get data locality.

aardvark179 10y ago
Keep an eye on project Valhalla.

curried_haskell 10y ago

After spending several years programming with Scala and Haskell, doing back to Java feels like being placed in a straightjacket.

galdosdi 10y ago

Eh, there are hacks around both of those... Gratuitous "typedef classes" for the first problem (instead of using a List<Sandwich> when you want runtime to be able to sniff the type, declare a class/interface SandwichList extends List<Sandwich> and use that) and just wrapping static factory methods around constructors to handle the generic part (to handle the second problem) Admittedly this is a little annoying, possibly even "really painful" so this doesn't really contradict your view... I don't find it really painful, just a little annoying, but that could be because I haven't used C# or another language people say has better generics so I don't know what I'm missing...

kailuowang 10y ago

I actually think type erasure might even be the right way to implement generics. You see, the point of static types is to provide compilation time check. That is, types are compilation time concern. So yeah, type erasure did introduce some inconvenience but if you need to access them during runtime, either you did it wrong or the compiler fails at some point. So, claiming type erasure making generic useless is a false argument.

eternalban 10y ago
Pretty sure the scope of the generic stage is the compilation unit.
kodablah 10y ago
Not to mention, having type erasure made them backwards compatible with non-generic implementations. I don't think it would have been acceptable to break old Java code or introduce an entirely new collections library like .Net did.
gpderetta 10y ago
I think that the problem with Java is not that they are implemented with type erasure (many functional languages do the same and monomorphize only when optimizing), the issue is that this implementation detail is a leaky abstraction in Java.
MereInterest 10y ago
Type erasure also makes some forms of function overloading impossible. void func(List<ClassA> list); void func(List<ClassB> list); Using type erasure, I cannot specify functions that are overloaded based on the generic type of an argument. To the runtime, both of these accept an argument of type List<Object>, and so it is ambiguous which one to call. In C++, which does not use type erasure, this sort of function overloading works as expected.

joegaudet 10y ago

Said much more clearly than I could: http://stackoverflow.com/questions/20918650/what-are-the-benefits-of-javas-types-erasure http://stackoverflow.com/questions/20918650/what-are-the-ben...

bitmapbrother 10y ago

If it weren't for type erasure we wouldn't have the abundance of dynamic languages on the JVM. Developing dynamic languages on runtimes that have reified generics is a PIA.

WorldMaker 10y ago
IronPython, IronRuby, and plenty more dynamic languages on the CLR which has reified generics certainly disagree with your opinion here. If anything, my opinion is that the abundance of so many dynamic languages on the JVM, and the active use of those dynamic languages in JVM projects, has much more to do with how no one really wants to work in Java than anything to do with how generics work (or don't work) in the JVM.

acjohnson55 10y ago

Java generics are cumbersome for sure, but if they're useless, it's not because of type erasure. As a Scala programmer, I've very rarely run into a situation where type-erasure has been an inconvenience.

bad_user 10y ago

You don't need reified generics with a more powerful type system. You might be feeling that C# .NET is better than Java, but it's actually a symptom that C#'s type-system also sucks. Basically whenever you have to do an `instanceof` check, that's a sign that the type system isn't strong enough and hence needs to be solved at runtime. One such thing missing from .NET for example are higher-kinded types. Basically people end up with the need for `instanceOf` because they aren't able to write generic code that abstracts over containers such as List[T]. And this holds back language development on top of .NET actually. There are good reasons for why alternative languages flourished on top of the JVM and not on top of .NET, in spite of its original marketing, which is a little ironic. Not the only reason mind you, other reasons where availability on Linux, having an easier time to generate bytecode along with debugging symbols, more mature tooling, etc, but having reified generics in the runtime either means that you have to limit your language (e.g. C#'s type-system with a different syntax), or it means that you have to do the type erasure yourself and always have performance problems and be considered a second class citizen. Lack of higher-kinded types is actually what's holding F# back as an FP language, because in FP there is a lot of opportunity to abstract over M[T] types, that are just not doable in a static language without HKT. And don't get me wrong, I like dynamic typing as well, but the problem with languages like Java and C# are that they are neither here, nor there, in many ways being the worst of both worlds. And the only advantage that .NET's reified generics have over Java is actually the specialization it is doing for primitives. Which is nice for performance reasons, since you avoid boxing and so on, but doing specialization doesn't necessarily need to be a runtime feature, when it can very well be a feature of the language's compiler. And we weren't talking about performance anyway.