Thanks for the reply (same to Jim and Manfred). I love a good debate, so let me respond ... meant in the spirit of friendly disagreement.
I had quite a debate with a friend who claims he puts zero value on standarized tests, because all they prove is you can pass a test, and prove nothing about whether a person can design, develop and maintain quality code ... that is what a programer does (we have both been around a long time FWIW). He would always take a proven quality programmer without the particular skill and let them pick up the language, rather than someone with less experience, but a SCPJ2 certificate. I don't agree with him totatlly.
If I am an employer interviewing a java candidate, here is how I would view the value of the SCJ2P certification. Also assume I am interviewing candiates for enterprise n-tier development (EJB, yada yada yada).
1) It proves the job candidate has a core knowledge about the Java language. At a minimum, the candidate isn't totally bluffing about having java skills.
2) It does not prove the candidate will be a good developer.
3) It does not prove the candidate brings enough to the table for n-tier development. N-tier development is hard. We are not in Kansas, anymore. In an EJB development effort, knowing Java is just a piece of the puzzle. Not to bore you, but for example, the following is what I have been up to from my office at home in an effort to "home school" on the J2EE platform. Set up a LAN, with a Windows 2000 client talking to a Redhat 7 Linux server (got Samba to work for file sharing). Spent some time trying to pick an Application server for education. Looked at BEA and IBM, but products expire. Installed ORION, but documentation sucks. Not a good place to learn. Settled on Allaire's JRUN... better documentation, good starter application server at a mininum. Then read .. forever (Sun Blueprints book, Core J2EE Patterns
, Roman's Mastering EJB, UML Distilled, Thinking in Java, ExamCram, ...).
My point for the rant... java is just a piece of the puzzle and just another language (although an awsome one, and the OO addition makes it a significant learning curve).
So back to my point about SCPJ2 and it's value as a tool for screening job candidates for a EJB project. One place I disagree with my friend, I mentioned above, is that you can still just bring in good people and learn everything on the fly. That worked fine in the old days when basically you only had to learn one procedural language and then you were useful. But all bets are off with J2EE. You have to at least bring a major portion of the J2EE skills to the table to have a chance... you still will be faced with other significant learning requirements. I would say, a solid grasp of the Java concepts is a minimum. But for my needs, I would be much more interested in someone with sound Java knowledge who didn't know anything about threads or has not memorized contructor arguments, but maybe used the time to learn JSP also, maybe tag libraries, maybe javabeans, maybe XML \ XSLT. The learning curve is so large, it just seems like a waste of time to spend time nailing down stuff like File IO, and AWT.
You said that a programmer saves the project time by having stuff memorized. In my opinion, in the scheme of J2EE land, that is fairly trivial. What will save time is knowing the broad range of J2EE skills, being able to look up stuff in a hurry, being able to learn new stuff quickly, because you will never know it all, knowing the framework your project uses for it's J2EE plumbing, ... that kind of stuff. I have been a consultant for over 15 years and have never made a point to memorize syntax. You almost always end up looking at example code, cutting and pasting, and referring to documentation. Now, I would agree you are way ahead of the game to know what class, what subclass, what method, yada yada... but memorizing actual syntax requires expending alot of energy that could be used accumulating other required skills. JMO.