> What are actual Java's shortcomings?

I guess, it depends on the application.

- I would not use Java for desktop applications.

- Not for small quick and dirty scripts that I will use once on a while. I use Perl for that.

- Neither for command tools. Start up times may be an issue.

- For server applications, java is great.

> - For server applications, java is great.

...unless it's not the main application run by the server (like in auxiliary services, message spooler, monitoring agent, some kind of cleanup service, stuff like that). Then its memory usage is a mess.

Mostly OOP's shortcomings. c2 wiki will lead you to much discussion on how "design patterns" are a band-aid patch for the deep, deep problems with massive OOP projects.

The problem isn't OOP, OOP's fine. The problem is how Java implemented Objects in a fairly rigid way which led to all this insane boilerplate. Furthermore design patterns aren't tied to OOP. And finally design patterns =/= JEE patterns .

There are about as many definitions of OOP as there are programming languages.

I'm not a software developer and have no dog in this fight. Sometimes I use Matlab's idea of OOP to factor out code by domain of representation (so simulations of agricultural yields are instances of a LandUnit object with some properties and one or two methods); never to abstract programming out the way OOP design patterns do.

I'm more attracted to the Haskell style of types and type classes, as far as "abstracting progrmaming out" goes, but I don't do any programming in the large, so what the hell do I know. I just pointed to the debate between people who should know, c2 wiki is very good on the things I do know.

Mostly a problem of how people use OOP.

I don't think there is a problem with the Java Language or the JVM.

Well, see, there are deep, deep problems with massive software projects. They don't have to be OOP.

But if you don't use OOP, what are you going to use that makes things significantly better? "There is no silver bullet", as Fred Brooks said.

Imagine you have two java apps on your pc. You want one to have full network access, but restrict the second one. Well, you can't, because application firewall sees both java apps as java.exe

Besides the fact that this is a very contrived example, and that this is not how I would go about managing firewall rules (why wouldn't you use ports / services? You trust the security of your PC on just the name of the application?), this is not true in many cases. To pick one: Eclipse (A Java app) does not identify itself as "java.exe".

Eclipse isn't a java app, it's a native app that happens to start a JVM that drives native widgets. If you ship a new platform tomorrow, and someone ports a JVM to it, java apps will Just Work, but eclipse still won't run until SWT and the launcher get ported.

This seems more like a complaint about the Windows firewall... and most people don't care to restrict network access on a per-app basis anyway--plus, any application with access to other local resources could very likely find some way to send network traffic besides opening its own socket.