From what I've seen the last I tried Java, there's another thing as well.
Java APIs are way more clunky than C#
In C# they're usually done in a natural way, in Java you have all this Rube Goldberg machinery to do something simple.
And if you try to tell me "they are much more flexible" I'll call BS because I never seen something that could be done in Java (except trivial limitations) that couldn't be done in C# or Python or something else, probably in an easier way
> In C# they're usually done in a natural way, in Java you have all this Rube Goldberg machinery to do something simple.
I've done my share of C# and Java, and while it looks like true at first, you then notice some dark corners, and before you know it you're looking at System.Configuration or something in Reflector because of some oddball. The next minute you notice you're actually surrounded by dark corners, and the more light you pour on it, the more the maze reveals its complexity.
Those may be fine languages for some people, but for me both feel like some terribly grinding noise in my head, similar to Pyramid Head's blade[0]. Not being dismissive, this is just my "radar" lighting up in some (painful) way.
I have to say, yes, sometimes there are such issues. I remember some localization function having these problems.
But then again, difficulty should be staged, the most common cases should be the easiest, and yes, even if you're doing something off-beat you should avoid going into dark corners.
There's the utterly retarded getter/setter convention, which while it's the most trivial thing must have wasted billions of programmer-hours by now. More generally I think the existence of a bunch of autogenerated java code (WSDL etc.) has lead many java programmers to write APIs that look like they were autogenerated, for consistency, rather than writing APIs that are actually nice to use.
That's a little unfair. The "Type getX(); setX(Type t);" convention to define a "property" dates from 1997, long before anyone was autogenerating Java code. And frankly at the time it was a revelation. People who were used to writing junk like CORBA IDL suddenly saw this "beans" API using "reflection" to detect this stuff automatically, with no assistance from the programmer except adhering to a simple convention. Really, this looked amazing at the time.
But obviously it's been improved. Managed runtimes (and especially more dynamic ones like Python or Ruby or Javascript) have become the norm. The idea of inspecting the metadata of an objectat runtime is no longer so strange. So when C# or Ruby decided to implement the same kind of property interface they felt comfortable taking a few more risks.
Also, the zeitgeist has moved and values different things than it did in the 90's. At the time, clarity seemed like a valuable goal (especially in comparison to C++), so Java preferred a write-it-out-longhand style where types lived in com.domain.subdomain.module.submodule.MyClass namespaces and all the APIs were multiWordCamelCase() things. And this was intentional, and believe it or not people liked it this way. The advent of Rails and DRY (re-)popularized the idea of a "terse" API, so Java's more verbose stuff looks clunky and "bad" to modern eyes in a way that it didn't.
Basically, don't hate on Java. It was good in its day. And it sits in a more important place in history than I think you give it credit for.
Yeah that's the other thing I forgot to mention that Java should steal from C#. In my own code I often just use public members but even with auto-generation in the IDE the getter/setter thing is gross.
Java APIs are way more clunky than C#
In C# they're usually done in a natural way, in Java you have all this Rube Goldberg machinery to do something simple.
And if you try to tell me "they are much more flexible" I'll call BS because I never seen something that could be done in Java (except trivial limitations) that couldn't be done in C# or Python or something else, probably in an easier way