Summarized from http://armelnene.blogspot.com/2009/11/10-things-all-java-developers-should.html, this is a list of the things a bona-fide Java developer is supposed to grok.
I summarized this because I'm interested in development. On the other hand, it makes me realize just how much crap people will put up with in order to circle their professional wagons around themselves, and fence everyone else out. It begins to appear very religulous.
Now, I'm not against Java. I like the idea, and I've done some programming in it. But the landscape is looking pretty convoluted. Is it that a lot of former C++/Corba-ORB enterprise developers never learned the lesson of simplicity? The reality is that there are multiple perspectives reflected here, and they don't really come together rationally. (I've commented on that lack of rationality before.) It is likely the case that developers who can check all of these items know little more than surface exposure and cookie-cutter reuse of sample code.
I note too, that the writer omitted any mention of layered or tiered architectures and client-server or peer-to-peer organization. He also compared SOAP to REST, a classical categorical error which is ingrained among many in the Java community. REST is a design philosphy; SOAP is a message packaging protocol. The two are not mutually exclusive. REST practitioners often utilize privately formulated well-formed XML as both the package and payload. Along with URL addressing conventions selected to facilitate caching, this "raw XML" most visibly represents the REST philosophy reduced to practice, and thus surface details are mistaken for the thing itself. REST means that you use the exchange of representations of objects between otherwise stateless servers to accomplish the goals and behaviors of the system. REST is akin to using bakers carts on a factory floor to exchange parts from station to station, instead of keeping everything inside a single complex closed machine. SOAP can be used in a RESTful manner, just as raw XML and URLs are often mangled to implement interfaces to stateful systems.
Java, OOP, and the the core library idioms
ex: What's the diff between using String, StringBuffer, StringBuilder?
Why implement interfaces instead of subclassing abstract classes?
Character of The Platform
Subsets of the Java2 platform: ME vs EE vs SE
Deployment choices: Applets, Servlets, EJBs
JVM configuration and JRE, SDK differences
Enterprise Development Frameworks: Spring, EJB, JPA/Hibernate
Some Scripting Skills: Python, Perl, XSLT, Ruby, command shells...
Basic web service development:
Servlet containers, Tomcat, GAE
ReST and WSDL, SOAP, XML and JSON payload formats
Multithreading: spawning threads, thread intercommunication, thread monitoring
Database Access: SQL, JDBC, JPA/JDO
Web Client Scripting: AJAX, Client-side Libraries (JQuery, YUI, Prototype, Mootools...), GWT
Chose an IDE and learn under it: Eclipse, JDeveloper, IntelliJ...
Build management tools: ANT, Maven, CruiseControl, Hudson...