I find Java's approach to specs to be one of the worst parts of the ecosystem. I've come across numerous obvious bugs with various Java specced libraries that have been marked `won't fix` because the bug is actually either a bug in the spec or just got left out in order to rush the spec out the door (rush being a loose term here given how often Java actually updates it's various specs).

At least the bugs are documented. Ruby bugs just are, theres nothing confirming them.

Java bugs need to stay there because if they were fixed then it would be a backward incompatible change.

That attitude is exactly why I have no interest in working with Java.

Wait, you're saying you'd prefer undocumented bugs and a constant stream of breaking changes to the runtime that force you to constantly port and report existing, working code?

I don't get it... the Java way seems pretty right to me. That said, I will allow that they might have been a little bit too rigid about not allowing breaking changes. At the very least this policy has resulted in Java evolving more slowly than it might have otherwise. But I don't necessarily find that to be unacceptable, all things told.

I prefer that bugs get fixed when found.

In my experience the Java way is 'oh, a bug, well, that's a bug defined in the spec so we can't fix it now, we'll make a note for the next version'...5 years pass.

The 'I don't want to touch working code' argument is another strange Javaism. If you expect your code to not rot your going to have to constantly maintain it anyway.

Maybe this doesn't work for the library ecosystem (standard libraries being where modules go to die), but the language and VM specs are very well designed.

> but the language and VM specs are very well designed

Java's language spec exists, I'll give it that. Well designed? It was when it was created but, it has evolved very poorly. Look at C# as an example of what a similar language designed at a similar time could become while still being 'Enterprise'.