Alexander Exner

Page 750, 751:

I did complete the FabricMachine example and added a switch to encourage the JVM to do some thread switching in the while loop of Machines run() method. I did input the machine steps quite quick after the operator was ready. Of cause your output may vary depending on the JVM:

import java.io.Console; public class FabricMachine { public static void main(String[] args) { Operator o = new Operator(); Machine m = new Machine(); m.start(); m.operator = o; m.applicationMayWorkFineSwitch = (args.length == 3); o.start(); } } class Operator extends Thread { public void run() { Console c = System.console(); while(true) { try { sleep(50); } catch (InterruptedException e) {} // Just for pretty output System.out.println("Operator is ready for instructions"); String userinput = c.readLine(); synchronized(this) { System.out.println("Operator calculates steps"); ToDo.toDo = "calculated steps " + userinput; notify(); } } } } class Machine extends Thread { Operator operator; boolean applicationMayWorkFineSwitch; public void run() { while(true) { if (!applicationMayWorkFineSwitch) { try { sleep(2000); } catch (InterruptedException e) {} } synchronized(operator) { try { operator.wait(); } catch(InterruptedException ie) {} System.out.println("Sending " + ToDo.toDo + " to hardware begins"); try { sleep(6000); } catch (InterruptedException e) {} System.out.println("Sending " + ToDo.toDo + " to hardware ends"); } } } } class ToDo { static String toDo; }


$ javac FabricMachine.java && java FabricMachine please work fine
Operator is ready for instructions
a
Operator calculates steps
Sending calculated steps a to hardware begins
Operator is ready for instructions
b
Sending calculated steps a to hardware ends
Operator calculates steps
Sending calculated steps b to hardware begins
Operator is ready for instructions
c
Sending calculated steps b to hardware ends
Operator calculates steps
Sending calculated steps c to hardware begins
Operator is ready for instructions
d
Sending calculated steps c to hardware ends
Operator calculates steps
Sending calculated steps d to hardware begins
Operator is ready for instructions
e
Sending calculated steps d to hardware ends
Operator calculates steps
Sending calculated steps e to hardware begins
Operator is ready for instructions
f
Sending calculated steps e to hardware ends
Operator calculates steps
Sending calculated steps f to hardware begins
Operator is ready for instructions
Sending calculated steps f to hardware ends
^C$
$ javac FabricMachine.java && java FabricMachine please dont work fine
Operator is ready for instructions
a
Operator calculates steps
Operator is ready for instructions
b
Operator calculates steps
Sending calculated steps b to hardware begins
Operator is ready for instructions
c
Sending calculated steps b to hardware ends
Operator calculates steps
Operator is ready for instructions
d
Operator calculates steps
Operator is ready for instructions
e
Operator calculates steps
Sending calculated steps e to hardware begins
Operator is ready for instructions
f
Sending calculated steps e to hardware ends
Operator calculates steps
Operator is ready for instructions
^C


After putting the while loop in the synchronized block the program did meet my expectations.

Page 583

Regarding to the introduction of chapter "Using Maps" i wrote this example:
import java.util.Map; import java.util.HashMap; import java.util.TreeMap; class Cat implements Comparable<Cat> { private String name; public Cat(String name) { this.name = name; } public boolean equals(Object o) { return false; } public int hashCode() { return 0; } public int compareTo(Cat c) { return this.name.compareTo(c.name); } } class MapTest2 { public static void main(String[] args) { { Map<Cat, Integer> m = new HashMap<Cat, Integer>(); m.put(new Cat("A"), 1); m.put(new Cat("B"), 2); m.put(new Cat("C"), 3); m.put(new Cat("D"), 4); System.out.println("Searching D: " + m.get(new Cat("C"))); } { Map<Cat, Integer> m = new TreeMap<Cat, Integer>(); m.put(new Cat("A"), 1); m.put(new Cat("B"), 2); m.put(new Cat("C"), 3); m.put(new Cat("D"), 4); System.out.println("Searching D: " + m.get(new Cat("C"))); } } }

Output:
Searching D: null
Searching D: 3

JDK 6 Javadoc of TreeMap states:

The behavior of a sorted map is well-defined even if its ordering is inconsistent with equals; it just fails to obey the general contract of the Map interface.

The only thing i found in the book is on page 579:

[...] it comes in two flavors: one that returns a new Object array, and one that uses the array you send it as the destination array:

As far as i can see there is no hint that the behavior is different depending on the length of the parameter array. I found more detail in the Java 6 JDK Javadoc of <T> T[] toArray(T[] a) methods from List and ArrayList:

Returns an array containing all of the elements in this list in proper sequence (from first to last element); the runtime type of the returned array is that of the specified array. If the list fits in the specified array, it is returned therein. Otherwise, a new array is allocated with the runtime type of the specified array and the size of this list.

If the list fits in the specified array with room to spare (i.e., the array has more elements than the list), the element in the array immediately following the end of the collection is set to null. (This is useful in determining the length of the list only if the caller knows that the list does not contain any null elements.)

I wrote this example:
import java.util.List; import java.util.ArrayList; class ListTest { public static void main(String[] args) { test(0); System.out.println(); test(3); System.out.println(); test(5); } public static void test(int size) { List<Integer> il = new ArrayList<Integer>(); il.add(3); il.add(55); il.add(2143); Integer[] ia = new Integer[size]; // Just for fun for (int i = 0; i < size; ++i) { ia[i] = 7; } System.out.println(Integer.toHexString(System.identityHashCode(ia))); ia = il.toArray(ia); for (Integer i : ia) { System.out.print("-" + i + "-"); } System.out.println(); for (Integer i : ia) { System.out.print("-" + i + "-"); } System.out.println(); System.out.println(Integer.toHexString(System.identityHashCode(ia))); } }

The output was not obvious to me, even reading the javadoc first:

java ListTest
1feed786
-3--55--2143-
-3--55--2143-
7987aeca

3ae48e1b
-3--55--2143-
-3--55--2143-
3ae48e1b

732dacd1
-3--55--2143--null--7-
-3--55--2143--null--7-
732dacd1


Btw i can hardly imagine that it is useful in most cases to insert a null after the original length of the array.

Some misleading code on

Page 579
Integer[] ia2 = new Integer[0]; ia2 = iL.toArray(ia2); does the job as well. To set the length of ia2 to 3 may cause somebody thinking its necessary to create an array of the same size first.

Page 583f
Cat c = new Cat(); m.put(c, "lost cat"); System.out.println("Just foud a " + m.get(c) + " not having overridden equals() and hashCode()"); The main reason why the Dog was found is not that some methods were overridden but that the same reference was used for construction and searching.

Page 292 ("Equality Operators")

It would probably be worth noting that things like this can happen as well:
int i = Integer.parseInt("01111111110000000000000000000001", 2); // this is a bit pattern float f = Float.intBitsToFloat(i); System.out.println((f == f) ? "equal" : "oops");
oops

AFAIK this happens:
1) Compiler indeed does not see inherited protected method m() in package B (BClass).
2) Therefore compiler looks at superclasses and finds protected method m() as defined in package A (AClass). Compiler is happy with that because its the same package as the "caller".
3) Runtime behavior was in my original example (https://coderanch.com/t/504882/java-programmer-SCJP/certification/Modifier-protected-does-not-hide) different, but in this example the JVM has only one choice as well: m() from AClass.

Maybe K&B should go a little bit more in detail on page 36...

KR Alex

Ad page 194 (Implicit cast from long to double):

I posted some stuff at thread https://coderanch.com/t/467890/java-programmer-SCJP/certification/Compiling-errata-SCJP regarding

No cast is needed in this case because d double can hold every piece of information that a long can store.

I did assume the issue is evident but maybe its better to discuss it.

I agree that all said is absolutely correct as long as you dont put it into one sentence. I wrote this code:
for (long l : new long[] { 0x0000fffffffffffeL, 0x0000ff7fff6ffffeL, 0x00002ffff9fffffeL, 0x00009ffffff3fffeL, 0x7ffffffffffffffeL, 0x7fffffffffffffeeL, 0x7fffffffffffffe4L, 0x7ffffffffffff15eL, 0x7ffffffffffff3e3L, 0x7ffffffffffff26eL, 0x7ffffffffffff6eeL, 0x7ffffffffffffff4L }) { // does not work proper double d1 = l; long l1 = (long) d1; System.out.println(l + " vs. " + l1 + ((l == l1) ? " ok" : " failed")); // better solution double d2 = Double.longBitsToDouble(l); long l2 = Double.doubleToRawLongBits(d2); System.out.println(l + " vs. " + l2 + ((l == l2) ? " ok" : " failed") + "\n"); }
281474976710654 vs. 281474976710654 ok
281474976710654 vs. 281474976710654 ok

280925211459582 vs. 280925211459582 ok
280925211459582 vs. 280925211459582 ok

52776457469950 vs. 52776457469950 ok
52776457469950 vs. 52776457469950 ok

175921859657726 vs. 175921859657726 ok
175921859657726 vs. 175921859657726 ok

9223372036854775806 vs. 9223372036854775807 failed
9223372036854775806 vs. 9223372036854775806 ok

9223372036854775790 vs. 9223372036854775807 failed
9223372036854775790 vs. 9223372036854775790 ok

9223372036854775780 vs. 9223372036854775807 failed
9223372036854775780 vs. 9223372036854775780 ok

9223372036854772062 vs. 9223372036854771712 failed
9223372036854772062 vs. 9223372036854772062 ok

9223372036854772707 vs. 9223372036854772736 failed
9223372036854772707 vs. 9223372036854772707 ok

9223372036854772334 vs. 9223372036854772736 failed
9223372036854772334 vs. 9223372036854772334 ok

9223372036854773486 vs. 9223372036854773760 failed
9223372036854773486 vs. 9223372036854773486 ok

9223372036854775796 vs. 9223372036854775807 failed
9223372036854775796 vs. 9223372036854775796 ok


Please tell me if i am wrong.

Page 194 (top):

No cast is needed in this case because d double can hold every piece of information that a long can store.

vs.
System.out.println(0x7ffffffffffffffeL); System.out.println((long)((double)0x7ffffffffffffffeL));
9223372036854775806
9223372036854775807

Some of the bits are victim of exponent...

Page 192 (bottom):

byte c = b + c
should be
byte c = a + b

Thanks for your clarification, looking at compile time and run time separate explains behavior.

K&Bs Book tells me on Page 36:
Once a Subclass-outside-the-package inherits the protected member, that member (as inherited by the subclass) becomes private to any code outside the subclass, with the exception of subclass of the subclass.

I did ask myself what happens if a class in package B extends a class from package A and another (e.g. static) method within package A tries to use some protected stuff from B:

package A; public class AClass { protected void m() { System.out.println("A"); } }

package B; import A.AClass; public class BClass extends AClass { protected void m() { System.out.println("B"); System.out.println("Super:"); super.m(); }

package A; import B.BClass; public class Test { public static void main(String[] args) { BClass b = new BClass(); ((AClass)b).m(); // Does compile and return B\nSuper:\nA b.m(); // Does not compile } }

I would have assumed that doing ((AClass)b).m(); is ok, because BClass extends AClass and AClass has method m(). m() from BClass should be invisible for "any code outside the subclass", therefore output should be perhaps "A". In fact output is "B\nSuper:\nA".

Please can anybody explain java to me?

KR Alex