Ade Barkah

I'm seriously considering moving to Beijing. If anyone has some views on what it's like to live & work in Beijing, I'd love to hear them!!

In the short term I'm planning to get a Chinese F-visa and take Mandarin courses at a Beijing university, to get "acclimated" if you will (actually I just sent in my school application yesterday.)

Hey everyone, I just took the 1.5 Upgrade exam. I'll save my results for "that other forum".

Some (subjective) observations for those contemplating this exam:

1. "Preparation"

As you know, the upgrade is a shortened version of the full SCJP exam (not simply the full exam at a discounted price). There are only 46 questions on the upgrade exam, and you are given 105 minutes to complete them.

Obviously if you're contemplating this exam, you've passed a previous SCJP version. For me, I did SCJP 1.2 in 2001. I did not take the 1.4 exam. Over the years I've learned a lot, and forgotten a lot! (I started Java in 1997.)

I took the exam as a way to force myself to learn 1.5 features. In my work we use JDK 1.4 exclusively due to our app server choice. My next project will be in 1.5 and I wanted to be better prepared.

Since I thought I knew most of the topics already, I only scheduled 5 days to study for this exam. This was too short. I moved back my exam one day, which was barely adequate.

I had a choice of concentrating on the new 1.5 topics (using Sun's online training module), or to review "everything" again. I decided to review everything by reading K&B end-to-end.

Despite adding another day, I had just enough time to read all the K&B chapters without doing any of the self-tests or mock exams. I was planning to "save" the self-tests for the last day, but in reality I just started reviewing the Inner Classes & Threading chapters this morning. Good thing I scheduled the exam for the afternoon.

I did write numerous small programs along the way to "test things out". For me this works best anyway.

2. The Upgrade Exam Itself

There were a good mix of questions between the "new" features (varargs, generics, etc.) vs. "existing" features. I half-expected the exam to focus mainly on new features due to the limited number of questions.

I thought the 1.5 exam asked "better" questions than the old 1.2 exam. There were a few "tricky" questions but I felt they were fair. I felt the old 1.2 exam concentrated too much on syntax, trying to "fool" you rather than test you. Also the 1.5 questions were clear and to the point. Kudos to the 1.5 test team.

Usually I finish Sun exams with tons of time to spare. This time I had just enough time to finish and double-check some questions. I finished the exam with less than 2 minutes remaining. Keep an eye on the clock!

There were quite a lot of "task" based questions (drag & drop, etc.) These were much more time consuming for me than the multiple-choice ones.

I felt there were numerous threading questions, but your exam might be different.

I felt the 1.5 upgrade was easier than the 1.2 exam, perhaps because the exam was better written.

You can miss 19 (!) questions and still pass. As I progressed, I kept track of the number of questions I wasn't sure about, and half-way through the exam I knew that obviously I was going to pass even though time was "tight." This relieved a lot of the pressure; you may want to do the same.

Due to my time constraints I relied on K&B exclusively in my preparation. If you honestly read all of the chapters sequentially, moving ahead only after having a good understanding of each chapter's main objectives, then without any doubt you will pass the exam!

If you get to this line, thanks for reading all my ramblings.

Ooops, sorry Burkhard replied while I was typing.

Burkhard: you write "The key is, that c1.getObject() returns an A-type and not a B-type as you would expect in the first place."

No, in fact c1.getObject() returns a B-type, as one would normally expect. Please verify this yourself.

... Object x = c1.getObject(); System.out.println("OBJECT TYPE: " + x); result: B@82ba41

I guess we can agree to disagree. My last reply to this topic.

I leave you with a piece of code below... which is ALL that is actually happening. The rest of the fluff (covariant, bridging, etc.) are simply red-herrings. Feel free to use any JDK.

class A { int x = 5; } class B extends A { int x = 6; } public class TestRef { public static void main(String[] args) { A b = new B(); System.out.println(b.x); } }

Result: 5

Nah, the modified example I provided above would return the same result even under JDK 1.4. :roll:

The behavior hasn't much to do with covariant returns, then, obviously if the same exact result can be obtained: a) when covariant return is used; b) when covariant returned is not used; and c) under a JDK when covariant returns didn't even existed.

Then please explain why the code below, which has NO covariant return, and therefore no bridging method whatsoever, still return the SAME result.

You can't have it both ways.

class A { int x = 5; } class B extends A { int x = 6; } class CovariantObj { public A getObject() { System.out.println("In A"); return new A(); } } class SubCovariantObj extends CovariantObj { public A getObject() { System.out.println("In B"); return new B(); } public static void main(String[] args) { CovariantObj c = new SubCovariantObj(); System.out.println(c.getObject().x); } }

Right!

wise owen: Try it yourself. Modify SubCovariantObj.getObject() to return A instead of B, i.e., "public A getObject()", so there is no covariant return, and therefore no "synthetic bridge".

How come the result is still the same? Because covariant returns has nothing to do it this issue!

Maybe we should review this link instead.

In pg. 563 (Using Maps) the comparison in the code segment "((Dog)o).name == name" should perhaps be rewritten using equals() instead. Otherwise the comparison may fail if a non-literal String was used to construct the Dog object.

Sorry, but the explanation provided in that link is wrong. This issue has nothing to do with covariant returns really.

For example, if we modify SubCovariantObj.getObject() to return A instead of B (so there is no covariant return at all), the answer would still be the same.

The "int x" declaration in class B "shadows" the one in class A, and thus does NOT participate in the inheritance.

If class B simply inherited "x" instead of declaring its own version, the result would be what you had expected.

This topic is already in the errata list.

My (printed) copy of the book has the error as well; Must be an older printing.

Also on the next page (465), 2nd para from bottom reads in part:

"Notice that because we were using a SHORT style, we lost some precision when we converted the Date to a String."

The above statement is wrong. The time component was "lost" because getDateInstance() was used instead of getDateTimeInstance(). The SHORT style has nothing to do with it.

Sorry to nitpick again. Page 458, "Working with Dates", reads:

With the help of the Locale class you'll be able to convert a date like "10/08/2005" to "Segunda-feira, 8 de Outubro de 2005" in no time.

Should instead read:

With the help of the Locale class you'll be able to convert a date like "10/08/2005" to "S�bado, 8 de Outubro de 2005" in no time.

Since October 8, 2005 was actually a Saturday.

Older exam results will not show on the Prometric site, but can be seen from Sun's certification site.

After logging into Prometric, note your candidate id (usually SPxxxxxxx). Then see if you can log into the Sun site at https://i7lp.integral7.com/sun using that id.

Otherwise you may need to go in person to a Prometric center and have them retrieve your test info (I'd call them ahead of time.)

In 3rd para: "...constructing a Reader or Writer will automatically create a file for you..."

Should perhaps read: "...constructing a FileWriter or PrintWriter will automatically create a file for you..."

(Readers don't create files, nor do most Writers.)