Alan Jump

I took this today...it was 122 questions with a 3-hour time limit.

Strange, I entered the code as presented in HFJ and had no problems getting it to run.

Maybe I did something unconsciously that corrected the problem...?

*goes to review code*

Okay, on review, I see I have the 2nd edition, and the line
sequencer.setLoopCount(sequencer.LOOP_CONTINUOUSLY);
does exist. This tells me I'm in a potential pitfall when it comes to reviewing someone else's code: don't presume everyone is working from the same version, be it of a text or of a JDK.

Just my two cents' worth...save up the change for a milk shake or something.
[ June 13, 2005: Message edited by: Alan Jump ]

Originally posted by Marzo O.C:
Why does the j variable get initialzed to 0 each time it comes back around?

Because that's exactly what the code segment is set up to do as written. If you exit a for-loop with either a 'break;' or 'continue;' statement, then enter it from the beginning, the counter variable will be reinitialized. (I haven't had my coffee yet, so I'm not sure that came out as clearly as I'd like.)

What is it you're intending to do with this code segment? Do you want to keep both counters running, and just ignore the result if the two counters are equal in value?

outer: for(int i=0; i<3; i++){ for(int j=0; j<2; j++){ if(i==j){ continue outer; } System.out.println("i=" + i + ", j=" + j); } }

Originally posted by Marzo O.C:

does the call to 'continue outer;' TERMINATE the current loop variables?
In other words, i know it continues with the next iteration of the outer loop, but does j get initialized back to 0 in the next iteration of the outer loop?

The best way to find this out is to run the program as written and look at the results. It's not like you're having to pay for compile time, right? (Okay, I'll quit being cheeky now.)

Were it me, I'd replace the 'continue outer;' statement with a 'break;' statement. That will exit the inner loop and leave the outer loop counter functioning properly, not to mention make the code segment more human-readable. (I'm told it's also considered much better programming form.)

Originally posted by Jeremy Clark:
IIRC, Borland's JBuilder still installs a version of the 1.4 SDK and uses that.

You are correct, it does. But that can be overridden fairly easily. Install the 1.5 SDK as usual, then go to Tools -> Configure -> JDKs, select Add, then point to the directory the new SDK is installed in. Then go to Project -> Default Project Properties and select the new SDK as the JDK to build with.

(Hrm...maybe this thread should be moved?)

Adding generics to ArrayList() is a new feature in the 1.5 SDK; the 1.4 compiler will reject it.

I'd suggest looking at your PATH environment variable and seeing if the 1.4 compiler is being called when you enter 'javac'. If you rearrange your PATH so the 1.5 SDK appears first, the 1.5 compiler will be called first. The alternative is entering the full pathname to the 1.5 compiler (which is more typing than I like, since I'm fairly lazy).

Hope this helps...

Originally posted by Serge Plourde:

For some clarification: interfaces do not define constructors. Constructors belong to classes only.

Ah...incorrect choice of terminology on my part, but an important difference. Classes have constructors, interfaces have abstract methods.

<-- /me hammers fact into brain

(I'm betting I see that on an exam sometime soon...but I digress.)

The main point is that a class that implements an interface must define all methods contained in that interface, and if a variable is defined in the interface it will be a static final. Did I miss anything?

Originally posted by Steven Bell:
[QBAs I said the variable 'a' is declared as type Animal and will from then on always be of type Animal. [/QB]

*cue sound effect: light switch*

Got it now...many thanks.

Originally posted by miguel lisboa:

why dont you experiment your own sugestions?

did you run my last post?

If I were at my own machine I could do just that. Sadly, I'm not at a machine I can drop a JDK onto, so I have to try and process all these good ideas and suggestions in my grayware (which may be what's confusing me).

Originally posted by Steven Bell:
However the variable 'a' is still an Animal and therefore only Animal methods can be called on it.

Just to make sure I've got it straight in my head, the only way to get 'a' to refer to (and therefore make use of the methods in) a Dog() class would be to break the reference first, then rereference it as a Dog(), like this:
a = null; Dog a = new Dog();

...or would casting it at declaration time work?
Animal a = (Dog) new Dog();

I admit, polymorphism still confuses me, even with the good books and tutorials available...

Originally posted by Maduranga Liyanage:
[QB]
Can I refer like this as long as some_method() and some_vlaue is defined in keyboard interface?
Using "k" instance is it only mehods and variables of keyboard interface that I can call?
QB]

The interface provides a set of constructors only...if you implement the interface, it's up to you to write the methods that the constructors refer to. So if the interface specifies a constructor:
public interface keyboard { public abstract void some_method(); }
...you have to write the body of some_method() in the class that implements the interface:
public class Computer implements keyboard { public void some_method() {// code for method body here } }

What I'm not sure of is if an interface can specify a variable value in its constructor; neither of my texts (Deitel & Deitel and Head First Java) make note of that. Can someone answer that small question for me? I'm sure I'll see it again sometime...

Ah...my bad. I came into Java at 1.4.

Originally posted by Manuel Moons:
I believe Swing is added to the standard classes since 1.3.

The J2SE 1.5 API documentation still shows Swing as a javax package.

API Overview - Java 2 Platform SE 5.0

Class or interface `javax.swing.JOptionPane' not found in import. import javax.swing.JOptionPane;

Perhaps you're trying to be too specific in your import. Try using this:
import javax.swing.*;

Hope this helps...

My bad...you're right...if there's a main() in the superclass and also in the subclass, the fact that the "standard" signature for main() includes the static designator will hide the main() in the superclass from the main() in the subclass. My thinking was that since neither the arguments or return type change between them, it could be thought of as an override.

Hrm...I'd better stop before I confuse anyone (including myself) any worse...