Clearly you didn't reach the conclusion. First, because the conclusion is not "Java sucks", but rather "Most of these things, while not kosher, are unlikely to happen in practice." Second, because the author didn't just leave it at criticising the language — he opened a bunch of bugs in the OpenJDK tracker.

People criticizing constructive criticism are often not constructive.

> It doesn't help anyone writing "this is broken" not offering any alternatives or suggesting ways to fix the problem.

Clearly stating and detailing problems is absolutely helpful. We can't solve problems if we don't understand them.

>It doesn't help anyone writing "this is broken" not offering any alternatives or suggesting ways to fix the problem.

Actually identifying a problem is of very much help, even without a solution.

For one, it lets people know of the problem, so they can get to an eventual solution.

Second, it lets people know of the problem, and avoid those areas, even if there's no solution available.

C# is a similar language in it's goals and architecture. LINQ to Objects type system will throw an error if you try to return conditionally different types from a lambda expression, so it is doable.

I think it would've been better to write "unsound" rather than broken, but it's pretty common to present little proofs/results like this without saying how the system should fix it. Doing so is helpful, because many times you'll know there's a problem without there being an obvious fix.

> It would be nice of you to compare Java generics with equivalents instead of just criticizing it. It doesn't help anyone writing "this is broken" not offering any alternatives or suggesting ways to fix the problem.

Hmm. If I knew your coolant was leaking, but had no idea how to fix it, would you prefer I didn't tell you? Just want to keep driving that car around with that coolant leaking?

At the very least, this is educational and helps better understand Java for those of us who work with it.