>> Strong push towards threading. Before NIO, there wasn't a way to avoid threads if you wanted to talk to multiple sockets. NIO has solved that for networks, but the whole java framework/idioms push you towards threads where it shouldn't.

> Where? I'm starting to think people dislike Java for the community / way it's used in enterprise rather than anything to do with the language. There's no push toward threading in the language :/ And NIO has been around for years.

I've used Java (and was burnt by it) before NIO made its appearance -- it was 2002 or maybe even 2003. I recently had to join a Java project that's "only" been around 2 years, so it could have benefited from the years of NIO -- but other than the base language, there is no async interface to be found. You want to talk to a database or key value store? You have to block (meaning thread). Want to do a URL fetch? you have to block, because there is no non-blocking libraries to be found.

It's not that it is impossible to do -- it is quite possible -- but it is almost against java culture.

> Where? I'm starting to think people dislike Java for the community / way it's used in enterprise rather than anything to do with the language.

You can say that again!

The java language is, I guess, ok (I don't like it, but it's mostly a matter of taste). The java ecosystem encourages verbosity-for-verbosity's sake, engineering-for-engineering sake, and ignoring common sense in the name of "purity".

That Java project I joined, for example, has hundreds of classes that do nothing but store a field or two, have getters and setters for them, and perhaps have one "action" in them. Each such class is only a couple of hundred lines. This is totally useless, and when optimization time comes (and it comes, because the project is running too slow because of hundreds of layers of encapsulation), it is nearly impossible to find a culprit because everything is spread thin through hundreds of useless classes.

I put up a plea for good java code on HN a few days ago: http://news.ycombinator.com/item?id=2094274 it didn't get high enough to ellicit much response (20 on the "ask hn" page, not sure how far on the main). But the responses that are there did not cause me to re-evaluate.

> - No way to tell how things are implemented. What?? Look at the source code. Decompile the class file into byte code :/

I have a merge sort that takes 40x long as it does in C. The reason I needed to implement it myself is that for the 400MB of data I'm looking it, the library tried to allocate over 2GB (which is all the deployment machine has), and that's just my test data -- when I try to sort 2GB of data, it would have required ~10GB.

I carefully wrote it so that no object gets allocated during the sort. 40x slower than C. WTF? Perhaps that MemoryMappedByteBuffer I am using does not inline it's ".get()" method -- that would explain x5, I think, not x40. But I have no frigging way of checking.

I am doing high performance code, which I agree is not common, but my experience with Hadoop (which is becoming ever more popular) is that the design decisions are such that the performance cost is x10 for just using hadoop compared to writing straightforward code -- meaning you would need 10 nodes to just break even.

I've been burnt by Java. I came back only after I could treat it with an open mind. I've been burnt again. I hate Java.