Pros
Free, as in beer.
The syntax is familiar to the myriad programmers that know any other C based language.
Java (the platform) has a very large and standard class library, some parts of which are very well written.
Java provides a platform for behavioral transfer from one address space to another. This is particularly evident in the dynamic class loading mechanisms of RMI (Remote Method Invocation).
Automatic Memory Management implemented by GarbageCollection and NoExplicitPointers
NoExplicitPointers
Explicit Interfaces
Improving performance (especially under HotSpot and IbmJava?)
Good portability (certainly better than that of nearly any compiled alternative)
Simplified syntax (compared to C++)
Language design not committee driven
Comprehensive documentation
Lots of available code and third-party libraries
Lots of different choices between JavaIdes which don't tie you into a specific Java implementation.
If you love OOP, the only way to write functions is to make them class methods.
No FragileBinaryInterfaceProblem.
Many standard interfaces defined in the standard library, which would have been vendor/OS specifc otherwise, helps a lot in achieving portability and ease integration/selection of 3rd party libraries. E.g. JDBC, JMS, JCE, JAI, serial I/O, JAXP, JNDI, etc. Some have correspondance in other languages (e.g. ODBC) but not all.
Cons
Much of the Java code as written by experienced coders turns out to be boilerplate. This has led to the charge that Java code is object-oriented Cobol.
If you hate OOP, or used mixed paradigms, the only way to write functions is to make them class methods.
Some people think the class libraries are poorly written.
As with all languages, getting used to the syntax conventions takes a while for those who come from other backgrounds.
Some people think that CheckedExceptionsAreOfDubiousValue
Some people wish for keyword or default arguments to functions
Some people miss closures (see SmalltalkMinusMinus, although BlocksInJava is a good (?) fallback)
Some people want destructors that are guaranteed to be called. (See FinalizeInsteadOfProperDestructor)
Poor garbage collection in some implementations/applications.
Lack of garbage collection on resources other than memory (see FinalizeInsteadOfProperDestructor)
Type system forces programmers to hard-code knowledge of types in multiple places throughout the code -- see Conrad Weisert's article on the topic in http://www.idinews.com/casts.html
Large memory footprint
Requires an interpreter. It is still difficult to deliver a self-contained application [If you feel that this has changed, please give us convincing information on "StandaloneJavaApplications" so we can delete this point.]
If you aren't careful, you can write slow programs. Of course, you can do this in any language.
Bugs in library implementations (especially Swing)
Bugs in JVM implementations (all JVMs are not created equal). This isn't Java's fault, but it has been known to limit Java's usefulness.
Proprietary language (i.e., not committee driven). There have only been a few events that could be construed as Sun abusing this power, and the JavaCommunityProcess (http://jcp.org) helps a lot. The main reason why people dislike this is because of what it "could" lead to.
Primitive types don't inherit from Object. This is a decision the language designers made on purpose, and never causes problems that can't be worked around. Still, it robs the less intelligent of us of that cosy feeling of consistency. And it frequently necessitates special-case code. See java.util.Arrays for example.
No generic programming means no StronglyTypedCollections unless you write 'em yourself one at a time.
Immutable types are a damn poor substitute for restricted references.