Rob Ward

Originally posted by Mark Herschberg:
I can usually get a good sense of someone's Java skills within about 15-20 minutes. But having your own set of interview questions, you can establish some baslines by which to judge people. (Of course, it took me a while to get questions for all skill levels--in fact, I can stand to use some more in my arsenal.)

Mark,
I'm curious, could you share some of these questions with us? I'd like to see how well I do, given my Java experience!
Cheers,
Rob

Today, I passed the SCJP with a score of 84%, a result that I am pleased with considering how little study I did for this exam.
I am a software engineer and have a reasonable amount of experience with programming in Java.
While preparing for the exam I found myself questioning the relevance of some of the material tested on the exam (eg. honestly, who needs to memorise constructors? That's what the API docs are for!). On the other hand, it was also a valuable learning experience, and as a result I have a new appreciation for some subtlties of Java that I hadn't given much thought to before.
My preparation consisted of reading RHE once, and reading a couple of chapters in Exam Cram (on AWT stuff). I also made use of the Javaranch resources to help me get a feel for what to expect on the exam. I did two mock exams - one of Marcus Green's exams and Brogden's "hardest questions". These helped me pick up a few tricky things I had missed. I also did the Javaranch Rules Roundup (gotta love that applet!).
The total amount of preparation I did amounted to about 2 days.
I found the exam itself to be clear, straightforward and very fair. There are no traps or surprises here. I found that the mock exams I took often deliberately try to trip up the candidate - this does not happen on the real exam. That said, you do still need to be careful when reading the code samples.
To add to the confusion that seems to abound about how long the exam is, I got 90 minutes to do the 59 questions. This was quite adequate - I did not need to rush and had plenty of time to review my marked questions.
So do not be put off by those who report that the exam is very hard - it isn't that bad! I feel the certification is well worth doing, if only for the learning experience - so for all those who haven't done it yet - go for it!
Good luck and may the source be with you!
Rob

One of the tenets of good coding practice is to use names for classes, interfaces, variables and other identifiers that are descriptive. This is not always easy when dealing with abstract concepts, and of course, everyone has their own idea of what descriptive means.
I was thinking that it would be really useful to establish a dictionary (and perhaps a thesaurus) of recommended class, method, etc names. That way, we could perhaps promote some standardization and make life a little easier for all of us. I find, for example, that sometimes it can be hard to come up with a name for a class or interface that is both succinct and descriptive, and it would be great to have a resource to provide some possible names.
While many names are domain specific, there are many generic modifiers that are not. Trivial examples include "Collection", "Filter", etc. Other examples of recommended names I would include would be names based on the GoF patterns (e.g. "xxxxFacade" is a Facade for the class "xxxx"). More abstract examples include those based on "nouned verbs" (e.g. Java's "Comparable").
Has anyone set up a page/site with something like this? I guess it is a relatively small issue, but it would be nice to see more consistency in naming of classes, interfaces and methods out there. As a mini version, perhaps we could have a "10 commandments of naming" to encourage good naming practices (come to think of it, some parents could do with this too...).
Here is my proposal for the First Commandment of Class Naming:
Thou shalt not append the word "Object"* to a class or interface name.
* Or "Interface". Or "Class". Or "Snafucator"**.
** Except as a name for a methodless and completely undocumented interface.
Rob

You've come to the right place!
Javaranch has an excellent collection of Java links at http://javaranch.com/gramps.jsp . For SCJP tips, I recommend the following as being the two best starting places:
Maha Anna's Site
Marcus Green's Site
Good luck, and may the source be with you!
Rob

------------------
Rob Ward
rob.w@mail.com
"Maths and alcohol do not mix. Remember, don't drink and derive"
[This message has been edited by Rob Ward (edited December 18, 2000).]

I'm not sure exactly what you're asking here, so please forgive me if I answer the wrong question.
You can put packages and JARs in the directory C:\jk1.3\jre\lib\ext, and you will not need to explicitly set the classpath to find these. This is intended for JAR files that you might use frequently (ext = extensions), such as crypto classes.
Note that a common gotcha here is to be sure that if you have put the classes in C:\jk1.3\jre\lib\ext, that you are actually using c:\jdk1.3\bin\java, and not some other jvm.
I haven't heard of there being a feature that you describe (eg. putting classes in jdk1.3\jre\classes), although I suppose it is possible there is - I don't have jdk1.3 on this machine to test that theory. If the feature does indeed exist it doesn't sound like something I'd advise anyone use though. You're much better off setting the classpath explicitly (in your environment or via the -classpath flag) so that always you know exactly what classes are in your classpath. Inadvertently leaving old classes in your classpath can lead to a lot of confusion!
Rob


------------------
Rob Ward
rob.w@mail.com
"Maths and alcohol do not mix. Remember, don't drink and derive"

You're close. The code fragments 1, 2 and 3 are correct.
1 - the signature is identical
2 - a method may declare fewer exceptions than declared in the method being overidden
3 - Both declared exceptions are subclasses of IOException, so this is ok
4 - Incorrect because IllegalAccessException is a checked exception that is not a subclass of IOException
5 - Incorrect becaus Exception is a checked exception that is not a subclass of IOException

------------------
Rob Ward
rob.w@mail.com
"Maths and alcohol do not mix. Remember, don't drink and derive"

I did think about implementing the paging DOM thing, but I lack the time I would need to devote to do it properly. It would be something that would be an excellent addition to the Xerces project though.
Yes, I agree SAX is the only option with large XML documents. The difficulty is when you want to traverse child nodes in it, access specific nodes, and other DOM-like things. It can be done, it's just more work than using the DOM.
Cheers,
Rob

As many of you are no doubt aware, when using Xerces (or XML4J) parsing a simple 1Mb XML document into a DOM requires roughly 6 Terabytes of RAM.
Ok, maybe I'm exaggerating a little. But the fact remains, the IBM implementation of the DOM uses insane amounts of RAM.
Does anyone know of a DOM implementation that pages portions of itself in and out of memory, as required?
Rob