Another SCJP study chapter down. I no longer feel bad about missing some questions in the last chapter, because THIS chapter is the one that talks about abstract classes being able to implement interfaces etc. Nice to ask questions about things before actually covering them.

Those silly default no-arg constructors in Java. I missed one review question about those. This is an example of the opposite of the "principle of least surprise" so touted in Perl and Ruby. Default constructors are magically automatically created in Java, but only if you don't supply any constructors of your own. Calls to superclass constructors are magically inserted in all constructors including those you define yourself, but they're always calls to super() with no arguments, and those super() calls aren't inserted into any constructor that calls another constructor as its first line. And so on and so forth.

Interesting that interfaces can extend multiple interfaces, while classes cannot extend multiple classes. One of the reasons behind forbidding multiple inheritance is supposedly so that you don't have to deal with method name collisions when multiple parent classes each let a child inherit methods with the same name. I tested what happens when there are name collisions in interfaces:

interface Blarg {
    public void test();
}

interface Blarg2 {
    public int test();
}

public class Test2 implements Blarg, Blarg2 {
    public void test() {}
    public static void main(String [] args) {}
}

It appears in this case there is no way to actually implement both the Blarg and Blarg2 interfaces in one class. (If there is, I can't see it.) You can't have two methods with the same name, same argument signature, and different return value. Trying to compile this fails with a "Hey you forgot to implement Blarg2's test() method" error. Similarly if I try

interface Blarg3 extends Blarg, Blarg2 {}

I get an error about Blarg and Blarg2 being "incompatible" because both define a method of the same name. That's handy. (Why not use the same error and allow multiple inheritance, and forbid it only whenever there are method name collisions? Who knows. Not I. I'm sure there are reasons. I hope there are reasons.)

I have a very good grasp on overriding vs. overloading. I remember going over it in my very first C++ class at college. I've somehow carried it all the way with me. Same goes with typecasting. Perl/Ruby don't have an equivalent, but I remember enough of it from C++. I also don't seem to have any trouble remembering which things happen at runtime and which things happen at compile-time. That should serve me well on the exam.

I plan to move to the west coast sometime within a few months, and that means job searching. That means time to hunker down and get this SCJP overwith. I don't know if it'll help me find a job, but it can't hurt me. I'm going to keep track of what I learn here, and I'm going to write about things I found troublesome in hopes that the act of typing it will help me remember, and that I'll have some kind of record of it.

Today I went through one chapter, dealing mostly with Java class/method/member access modifiers. In the practice questions I missed a couple questions, which was depressing after having just studied it for nearly two hours.

One I missed because I didn't know abstract classes can implement interfaces. But it makes sense that when an abstract class DOES implement an interface, it doesn't need to provide all the methods in the interface.

Another I missed due to Java's screwy syntax. Java will supply an implicit public abstract on any methods in an interface, but when you implement those methods in a concrete class you have to specify them explicitly public. Otherwise they revert to default and that means they don't properly implement the interface's methods at all.

Similar to above, I forgot that even though an interface provides an implicit abstract to its methods, and abstract class does NOT. That makes sense after I think about it for a second, because abstract classes can contain both abstract AND non-abstract methods. However given that abstract and non-abstract methods have different syntax themselves (abstract methods end with a semicolon, and non-abstract methods end with curly braces containing or not containing code) you'd think the compiler could figure it out. But nope.

It's amazing how I studied Java for two years at college and I never got these kinds of rules spelled out in so many words. I sort of picked it up as I went. And I took a class on compiler theory / general computer language design theory, which helped IMMENSELY whenever I need to understand things like scoping rules and inheritance rules and parameter-passing methods. I think those very subtle things are one of the more difficult aspects of computer programming, especially because they differ so often between various programming languages.