The main two reasons I don't like Java:
-Virtual Machine. Retarded.
-Completely OO? Nonsensical.
Well, dissing the VM seems kind of strange, after all, the virtual machine is what makes Java - Java - right? If you want maximum portability and greater security, you don't have any other choice but to use a VM (sure, there is GCJ but let's wait and see how that turns out - I have some doubts). This really isn't so different than what brought C into the world either. A compiler was considered an intrusive program that generated bloated and slow code in comparison to assembly. However, K&R were willing to sacrafice speed and size for portability. In a very real sense, a VM is just compiler evolution. If this were 1985, we'd be making the same arguement about how compiled languages like C++ are slow and bloated in comparison to assembly, right?
Quite a few knowledgable people criticize the VM for being slow, memory hog, etc. However, the world doesn't need another C, C++ or Fortran. JIT compilation is still relatively new, improving rapidly, and in some situations outperforms normal compiled programs. There are even some mixed JIT / AOT VM's out there that may literally offer the best of both worlds going forward. And of course, if you have tight memory requirements, you can always use J2ME instead of J2SE. Java is probably broadest platform available which is very nice and due in part to the VM.
Regarding the OOP only situation, again, Java wasn't designed to be another bash, perl, or C/C++. Sure, it pisses some people off, but in many cases, it was an excellent choice. Modularity and abstraction are a computer scientests best weapons for dealing with complexity. Complexity rarely decreases - ALL of the simple apps were originally written in the 60's and rewritten in the 70's.
Anyways, I tend to think that if what you're writing is so dead simple that it shouldn't be done in an OOP fashion, well, you probably shouldn't be using Java either. After all, how hard is it to create a class name and make all of the methods static, or even the class static, and optionally package it? And how beneficial is doing this? If you're working on some math functions not in the Java API, go ahead and create another Math class with static methods - or better yet, extend another Math class. This probably wouldn't occur as frequently w/o the OOP req in place, right? Hence, there are many libs available in JAVA - despite all the moaning. For good, honest, down to earth scripting that requires portability, there are alternative languages for the Java platform like Jython, JRuby, and Groovy, which don't require OOP.
Also, I doubt that it would be possible to create something like the Java API w/o OOP. Just look at how messy the PHP libs are in comparison (IMHO - and you'll notice that they chose the Java OOP model now, not C++). Threading, toString, Collections, and many other usefull methods descend from the Object and other common superclasses.