Learning Java alone doesn’t make you Java developer
veerasundar.com
veerasundar.com
...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.
As someone whose day job entails writing servlets (and all Java web development boils down to servlets), I find that I really can no longer get excited about a Java web project because the first thing I think about is how much of a pain it's going to be to make it. Not pain as in difficult, but pain as in tedious.
But the combination of the title and the parent post is quite amusing.
Learning pl alone doesn't make you a pl developer. You become that as soon as you implement a virtual database to make up for deficiencies in the existing customer database which cannot be changed.
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.
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."
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.