Dick Eimers

I've been prepping and hanging around the saloon for about 2 months now. This morning I took the exam and scored 84%. I'm happy with my score even though I was dissapointed with the 'Concurrency' part:

Declarations, Initialization, Scoping..91%
Flow Control...........................72%
API....................................90%
Concurrency............................60%
OO Concepts............................90%
Collecttions/Generics..................90%
Fundamentals...........................90%
------------------------------------------
84%

I'd like to thank K&B for their book (dispite the huge amount of error ) and the fellow ranchers, of course.

Next up: SCWCD

I guess, the "write-though" only holds for Arrays.asList() and not for Collections.toArray().

This will not work, i.e. compiler error, because the IS-A relation does not apply to the elements of the array.

for (final int i: getCharArray(arr)) System.out.print(i);

The enhanced for-loop as shown above is actually just syntactic sugar for something along the lines of:

{ char[] result = getCharArray(arr); for (int index = 0; index < result.length; index++) { final int i = result[index]; System.out.print(i); } }

That is, 'i' is a local variable (local to the for-loop) and it is not been assigned a value twice so it's just fine.

To finish this up. The following will *not* compile, because 'i' is assigned a value twice.

Assignment 1: the result of getCharArray(arr)[someindex].
Assignment 2: i = i+1
for (final int i: getCharArray(arr)) { i = i+1; System.out.print(i); }

584 "For example, imagine a classic (simplified) polymorphism example of a veterinarian (AnimalDoctor) class with a method checkup()." s/b "For example, imagine a classic (simplified) polymorphism example of a veterinarian (AnimalDoctor) class with a method checkAnimal()."

642 see this thread

The amount of errors in this book is starting to annoy me. I've paid 60 euros -- about 70 dollars-- for this book and it is packed with errors.
[ June 05, 2006: Message edited by: Dick Eimers ]

It'll unbox the Integer.

See JLS 15.21;
If the operands of an equality operator are both of numeric type, or one is of numeric type and the other is convertible (�5.1.8) to numeric type, binary numeric promotion is performed on the operands (�5.6.2).
[ June 01, 2006: Message edited by: Dick Eimers ]

I have this priority scheme burned into my brain, saying 'widening >= boxing >= varargs'. Since widening has priority over boxing is expected this to just work. It turns out it is not. Nice post!

UPDATE: I've been playing with it a bit and it seems that even the following code is ambiguous according to javac:

class Test { void take(char... chars) {} void take(Character... objs) {} void give() { take('a'); } }
So, it is not the combination of widening and var-args as the type (char) matches.
[ May 29, 2006: Message edited by: Dick Eimers ]

The 1.x naming scheme is the old naming scheme and a few years ago Sun changed the naming scheme.

Please read the Generics Tutorial and ask specific questions.

217 myDogs(0) s/b myDogs[0]

I am trying to explain why you can't combine transient with static and/or final. However, after searching the JLS and trying some examples I am starting to think that final+static+transient, although not always as useful, is just fine..
[ May 27, 2006: Message edited by: Dick Eimers ]

Using transient you are saying that it should not be used when serializing.

static: Serialization does not apply to classes but only to objects, so using static is in combination with transient is bogus.

transient: This is not as easy to explain. I can't find an explanation for this is the JLS, but it has to do with the fact that final fields have to be initialized exactly once and that while deserializing the constructor, i.e. the place where the initialization code is, is not invoked.

You don't have access to a this or super in a static method. But when you do have access to this or super, i.e. in an instance method, the trick of invoking a static method a.k.a. class method using an object reference works just fine:

class SuperBla { static void foo() { System.out.println("SuperBla.foo()"); } } public class Bla extends SuperBla { static void foo() { System.out.println("Bla.foo()"); } public static void main(String... argv) { Bla bla = new Bla(); bla.instancemethod(); } void instancemethod() { Bla.foo(); // OK, obviously calls Bla.foo() SuperBla.foo(); // OK, obviously calls SuperBla.foo(); this.foo(); // OK, calls Bla.foo(); super.foo(); // OK, calls SuperBla.foo(); } }

The type of the reference is used when invoking static methods using object references. The type of this is always the class in which it is used (Bla) and the type of super is always the superclass of the class in which it is used (SuperBla).

The code I posted in my initial post compiles and runs just fine on Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)

Originally posted by Sharn Arora:
Hence, si being the static variable gets the value 0 & is stored on the stack.

This is incorrect. Static fields are not on the stack, but I don't think they are on the heap either. Static fields a.k.a. class fields are special in that they are part of the class not the objects that belongs to that class. If 'si' would have been an instance field it would have been stored on the heap together with the object it is part of. However,
if I remember correctly, they are on the 'method area' together with the rest of the class definition such as the class's methods..