Win a copy of Modern JavaScript for the Impatient this week in the Server-Side JavaScript and NodeJS forum!

Joseph Zhou

Ranch Hand
+ Follow
since Aug 01, 2000
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Joseph Zhou

You are right Bert. Also, uses the same way for both good for getting correct result: Thus the length of the substring is endIndex-beginIndex.
Hi Joseph,

I think you can find more mock exams before you try another one. If you can pass those mock ones at around 90, I believe you can pass the real one.

Another Joe
On page 422, there is a discussion about String.substring(int begin, int end)
ON page 426, there is a discussion about StringBuilder.delete(int begin, int end)

the book says the the second argument is one based and give a way to count it, the result is correct.

As I recalled, Java is a language using index starts from zero (a few cases related with database etc. excepted), so we'd better to use the way described in JDK API:
start - The beginning index, inclusive.
end - The ending index, exclusive.

I also think what is max value the end parameter is worth to be mentioned.
Sorry Manfred, I think we are forced, otherwise there is "Object" in the table, not Foo[].
Thank you Kaydell. From my point, it better to put a System.out.println() there, instead of an assert, in the place. at deploy time, you will see the result immediately from the log, no assertion on/off required, and many production run is not really repeatable.
We know assertion usually disabled before deploy time, if we use it like this, could be not good for production running:

Do Use Assertions, Even in Public Methods, to Check for Cases
that You Know Are Never, Ever Supposed to Happen

This can include code blocks that should never be reached, including the default of a switch statement as follows:
switch(x) {
case 1: y = 3;
case 2: y = 9;
case 3: y = 27;
default: assert false; // We're never supposed to get here!
If you assume that a particular code block won't be reached, as in the preceding example where you assert that x must be either 2, 3, or 4, then you can use assert false to cause an AssertionError to be thrown immediately if you ever do reach that code.
Repeat my question: Is the line in the table at the page correct?
Thanks you to find a way to make it compile-able, but it is not what I want to say.

When you look at the table:

First Operand_____________|instanceof Operand________|Result
(Reference Being Tested)__|(Type We�re Comparing the_|
__________________________|Reference Against)________|
Foo[]_____________________| Foo, Bar, Face___________| false

it's the Foo[] object, not Object, instanceof Foo, Bar, Face, get result false.

I think this is not a correct result, because you can't pass the compile.
From my point of view, we should use fooarr, not fooarr[0] here:

System.out.println("Foo[] instanceof Foo: " + (fooarr[0] instanceof Foo));
System.out.println("Foo[] instanceof Bar: " + (fooarr[0] instanceof Bar));
System.out.println("Foo[] instanceof Face: " + (fooarr[0] instanceof Face));

Just as in:
System.out.println("Foo[] instanceof Object: " + (fooarr instanceof Object));

Because both are Foo[].
Here it is:

Table 4-1 summarizes the use of the instanceof operator given the following:
interface Face { }
class Bar implements Face{ }
class Foo extends Bar { }

table 4-1 Operands and Results Using instanceof Operator.

First Operand instanceof Operand Result
(Reference Being Tested) (Type We�re Comparing the
Reference Against)
Foo[] Foo, Bar, Face false
Line 5 in the table says: Foo[] object instanceof Foo, Bar, Face, result is false. Actually, it should fail to compile. Did I miss anything?
I got it by a test run. you can put multiple -D.
14 years ago
No. I want to pass in my keystore file name/password.
14 years ago