> I was thrown at huge list of Java jargon, which I’ve never heard before. log4j, DI, IoC, RMI, JNDI, to name a few.

...and therein lies the problem. J2EE is the umbrella word that covers up a rat's nest of API's that are constantly changing and being replaced in favor of other other API's.

What is so complicated about web development that Java developers feel that it requires 18 different layers of code and special servlet containers to accomplish? Take a peek at a plain Tomcat server process running absolutely nothing: it uses 430MB of RAM for one process, and that without any extra servlets installed. I'm convinced J2EE only exists only to keep mediocre developers employed at big companies that don't know any better.

You become that as soon as you implement a FactoryFactory complete with your own xml driven configuration.

It's not clear from the article what sort of classes the author took to learn Java. If the title was something resembling "enterprise software engineering in Java" then he has a valid complaint; not covering the many libraries and tools commonly used for that purpose is a serious omission.

If the subject was something like "computer science" then failing to include any of several tools popular in industry is entirely appropriate if those tools aren't optimal for teaching about how computers or computation works. From what I know of Java and associated tools, it seems entirely appropriate to omit the whole language from a computer science curriculum.

College alone will never prepare you for real-world anything, programming or otherwise.

The article is quite wrong. Learning Java does make you a Java developer. You don't have to know any particular framework to be a Java developer, because there are dozens of popular frameworks in use, and different projects use different frameworks.

There's no point in learning J2EE if you don't want to work on J2EE applications.

There's no point in learning Swing if you don't want to work on Swing applications.

I think what this he meant was, "Learning Java alone doesn't qualify you to apply for most Java jobs," or maybe, "You will not be immediately productive at your new job if all you know is Java."

I think that "Java" is being used as a variable name here, which can stand for any programming language ever compiled/interpreted.

Learning the language and the du jour APIs will also not make you a skilled Java developer, which is what I think the author means; doing that in any language X will not make you an X developer of any reasonably high skill.

The problem I have with posts like this is that they seem to be focusing entirely on the wrong way of learning to develop software. They work from the assumption that becoming a developer is a matter of memorization, and the reason they aren’t there yet is because they haven’t memorized enough API definitions or acronyms.

Approaching anything from this level of abstraction results in needing to learn most everything as if it were a completely new area of knowledge. And it is an incredible timesink, as the author has already confessed

Instead of realizing the need for a hash table to solve a problem, and researching what options are available in this language, they either perform a scan of all of the options and pick the one available that looks best, or they rely on some mnemonic to decide what data structure to use without really understanding why it should be used. Both arrive at approximately the same place -- hopefully -- but they approached it from entirely different directions.

The former developer already knows the metaphor he is looking for, and thus his search will be very limited in size and when he finds class/library/etc. he needs the API will already make some intuitive sense provided it implements what it claims to.

The latter developer has no metaphorical basis for what they are doing, and thus even when they find something that works, they’ll have to rote memorize the API, because to them it’s just a formless black box.

To answer the author's question about what APIs one ought to know, my response is that the author is asking the wrong question. I’d like to ask what has convinced them that APIs and acronyms are the thing most worth knowing. It seems to me the author's time could be far better spent learning the metaphors and theory behind those acronyms and APIs, and then realizing that finding and learning new APIs and class libraries aren’t all that tricky once the fundamentals are understood.

You see the same mindset in any programming student regardless of the language. Nothing can ever replace real-world experience, especially not with just one language.