You would be very lucky to find a case where you can directly execute code via a simple coding error in Java. It is possible that a bug in the implementation of the JVM allows memory corruption through benign code, but at worst phenomenally rare.
However, even within the JRE (OpenJDK) a portion of the libraries are written in C, and therefore contain memory corruption vulnerabilities when used with untrusted data. Rendering a malicious JPEG would be the canonical example.
There are lots of non-memory related bugs, such as injection (HTML, SQL, LDAP, HTTP headers, etc), but those in general wont lead you directly to remote code execution.
A far too common situation is where a handy library deliberately executes remote code without deliberate being enabled by the application programmer. Examples given in Secure Coding Guidelines for Java SE (5.0) Guideline 3-8 / INJECT-8: Take care interpreting untrusted code are certain feature in: the scripting API, LiveConnect, XSLT extensions, Long Term Persistence of JavaBeans Components, Java Sound, RMI, LDAP and certain JDBC/SQL implementations. An application may deliberately load mobile code, which leads to a whole other world.