Java's Original Sin
gbracha.blogspot.com
gbracha.blogspot.com
Primitives made sense at the time, but with operator overloading we wouldnt be stuck with the mess we have now.
And methods should have been first-class objects. More messes that could have been avoided.
Unfortunately, vocational Java programmers are terrified of anything that resembles metacircularity. There's a depressing tendency to just label anything mildly functional as 'closures'.
I assume you mean primitive data types not being first-class objects? When Java was born, Smalltalk had a very long history of Ints and Chars being first class objects. The VM/byte-code compiler took care of in-lining values to make their time/space behavior as if they were primitive data types.
Too many concepts that overlap - containers, arrays, generics, iterators, classes, interfaces, etc. An important factor in whether you want to use a language is "how many concepts am I going to have to understand to read other peoples code ?"
A lot of the library is very poorly designed, probably because they rushed it out the door. Take a look at the GUI inheritance hierarchy for instance. Also, a lot of the code looks like C code IIRC.
The comments below, in my view, are just as interesting as the post.
As to the 16 byte char just do what most languages do when they get a basic feature down and add a Byte32 or whatever.
PS: I tend to think of Java as a slightly more friendly version of C rather than a high level language. It's fairly easy in Java to open a socket and decode a bit stream, where most high level lanugaes make that far more difficult.
Forgive me if I'm being dense -- I haven't done much Java programming lately -- but what do mean by "convert everything to runtime exceptions"? Sure, you can define all your own exception classes as runtime exceptions. But checked exceptions seem unavoidable, as you can't (practically) avoid calling all the Java API methods that throw them.
> But checked exceptions seem unavoidable, as you can't (practically) avoid calling all the Java API methods that throw them.
Yes, that's what I mean by "at the edges". You can't avoid hitting the ones built into Java but you can stop them penetrating into your own code with a simple try / catch that wraps them with RuntimeException.