Hacker News Reader

Comment by matwood | Hacker News Reader

Basically, because of type erasure you cannot have overloaded methods using different Optional types. So test(Optional<A> a); is the same method as test(Optional<B> b);

I think you can define the types to get around it, but that is messy and a PITA. For example, class OptionalA extends Optional<A>.

View on HN

That doesn't seem so bad to my eye, though. In Haskell terms it just means that any overloaded operators on Optional have to respect parametricity. If you need something more specifically typed then you can just use a new name.

Is there a particular use case?

Wow that's a real pain point. Why would they even do that, is there a use case?

Backward compatibility - you could run an application that uses generics, introduced in Java 1.5, on a Java 1.4 VM. At the time that was pretty amazing. These days, with so many backward compatibility-breaking changes being introduced, it doesn't feel so great.

That was the original plan, but it never worked in my experience. The compiler as shipped required that -source 1.5 use -target 1.5. So hobbling the language this way served no benefit in the end.

Btw, type erasure is only a problem for Java because it supports runtime type information (which is incomplete, because of type erasure), and overloading (which I have no idea why the compiler can't handle). For languages like ML and Haskell, type erasure is no problem, because you can't access the types at runtime anyways.

In my opinion, no it really isn't. You can just create a method with a different name or a static constructing method if you need to overload constructors.

The major pain point with generics is that they don't work with primitives.

Reply on news.ycombinator.com