Popular posts

In most cases I've encountered, it was possible to change it so that one gets a compile error instead of a cast exception, which I think we can agree is preferable. So I'm wondering if that's always the case or whether there are edge cases that can't be checked at compile time.

Architecturally, I think it's weird to say that a method takes a GeneralObject if it actually needs information from SpecificObject. Feels like you're violating the substitution principle.

And just because it's in Java doesn't make it a good idea :-) Java is an old langauge with a focus on backward compatibility. Not everything is still a good idea (raw types, arguably checked exceptions). In this specific case, maybe it's just an artifact from before generics existed?

M if I remember correctly, Philip Wadler who wrote/helped writing the generics for java explains in one of his talks that all generics are in the end just are castings that are wrapped and hidden by the compiler. you just don't write it like your example anymore ... anyhow this is just an anecdotal side-note :)

Agreed, compile time errors are always preferable.

Well I think in the end it depends heavily on the use case.

Like your system is a dms (document management system) and I have to handle docs, folders (top structure) and registers (sub structures). They have things in common but also specifics for each and its that way projected in Java (inheritance tree). So when I’m running a search I get a result list with mix types but as a general top object they derive from. And here it’s pretty valid after an instanceof check to use “hard” casts even within using streaming api.

As said it depends but I don’t feel any negative about it. It’s just another tool and it’s not got stale just because it’s one of the early features.

Edit: j absolutely my point.

Edit 2: little side note: currently I considering and evaluating using kotlin (in a Spring Boot env) as a future java replacement. ATM just for fun. I’m eager to see what challenges are coming up there.

Hmm my first thought for your example is I'd use an enum, but Java of course only has crippled enums. +1 for Kotlin there (sealed classes) :-) Maybe that's an example of a use-case then.

As for the JVM compiling generics down to casts, that's true, but just another limitation for backward compatibility, it's still checked at compile time (in the absence of raw types), and other languages do it without casts, so it's not inherent.

Well actually there’s an enum which states the type but to actually access specific properties I still have to cast to the matching class.

But that’s what I try to say is that class casting is still “active” in the java architecture and no legacy at all.

At generics: I didn’t point to what generics get compiled to but what you have to do when implementing a generic class oder function yourself. Most cases you do some return (T) someObj; at the end

I’m not trying to convince you into type casting. Just saying it isn’t as bad practice and more common than you might think

I'm not sure what the generic thing is about then... I don't use casting when making generic classes...