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.

Good point Kaydell. Thanks.

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.

Thank you Brad. Actually, that just was my question:-)

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.

No. I want to pass in my keystore file name/password.