Not OP, and not sure about OCaml and Haskell, but one example where Java's type system is unhelpful/incorrect is mutable subtyping.

E.g. Java assumes Cat[] is a subtype of Animal[]. But this only holds when reading from the array. The correct behavior would be:

- `readonly Cat[]` is a subtype of `Animal[]`

- `writeonly Cat[]` is a supertype of `Animal[]`

- `readwrite Cat[]` has no relationship with `Animal[]`

But Java doesn't track whether a reference is readable or writable. The runtime makes every reference read-write, but the type checker assumes every reference is read-only.

This results in both

- incorrect programs passing the type checker, e.g. when you try to write an Animal to an Animal[] (which, unbeknown to you, is actually a Cat[]), you get a runtime exception

- correct programs not passing the type checker, e.g. passing a Animal[] into an writeCatIntoArray(Cat[] output) function is a type error, even though it would be safe.

(Although all that is assuming you're actually following the Liskov substitution principle, or in other words, writing your custom subtypes to follow the subtyping laws that the type checker assumes. You could always override a method to throw UnsupportedOperationException, in which case the type checker is thrown out of the window.)

Interestingly, AFAIK Typescript makes these types both subtypes and supertypes at the same time, in the interest of not rejecting any correct programs. But that also allows even more incorrect programs.

I can't make a Mappable interface, and have my classes implement map(f). Because map(f) will necessarily return Mappable, not my class itself. So no method chaining for me.

Also null. Yeah I know it's contentious. People don't want to let go of it. Since learning to hate null, I've also lost any nuance in my ability to explain why it's bad. Because I know longer see it as 'subtly-bad' or 'might lead to bugs'. It's just plain, on-the-surface-wrong. One might as well have named it 'wrong' rather than 'null'.

'Null' is the thing which it isn't. I can write business logic that says every Person has a Name. Once you admit null into the mix, I can no longer make that simplest of statements. My autocomplete now lies to me, because person may or may not implement the method .name().

"But how will I half-arse instantiate a Person? I don't have a Name, yet I want to tell the computer I have a Person?" It makes me happy that you can't.

"I wrote a function that promises to return a Person. I was unable to return a Person. How can I tell the computer I'm returning a Person even though I'm not?" Glad that you can't.

It's not really about the implementation of Java (might be bad, I don't know). It is the specification.

- People talked about null being an issues and that is a big one.

- The entire idea of OOP extremism Java implemented was a mistake - though just a consequence of the time it was born in. Much has been written about this topic by many people.

- Lacking facilities and really design for generic programming (also related to the OOP extremism and null issue

So much more more you can find out with Google or any LLM