Timothy E. Hay

Edisandro, you're right.

The key details are to be found in the JavaBeans API spec, sections 6 & 8 - the discussion Bert is referring to above is one I started.
What it comes down to is that the 'Listener Type' also has a naming convention - it has to end with the word 'Listener'.

Here's the full discussion:
JavaBeans Listener naming conventions?

Cheers,

Tim
[ February 19, 2006: Message edited by: Timothy E. Hay ]

Ah thanks gents.

Apologies for re-asking the question. I think I must have got slapped by a moment of laziness. Having done a proper search, I've found several posts now.

How embarassment! Will try harder next time.

The only other thing I'd comment on is for Fred - don't put yourself down: there's nothing lowercase about being a Dad! It's a great job that should even be uppercase DAD all the way! Well that's what I tell my children anyway.

Cheers,

Tim

Hi all,

OK, this may sound a tad desperate, but does anyone (Bert?) know how multiple choice questions are graded? For example, if the choices are A - E, and the correct answer is A, B and E, what is the result if I choose just A and B?
What if I choose A, B and D?

These are situations I have experienced when doing the self test questions in K&B's study guide.

Cheers all,

Tim

Hey, thanks for the tip Levani!

Gotta love SourceForge.

Cheers,

Tim

Todays rant has been prompted by covering the Dates, Numbers and Currencies section in K&B's Java 5 Study Guide.

Can someone please explain to me what was going through the minds of the clever little bunnies at Sun when they decided that the year and date parameters to Calendar's set() method would be 1-based, however the middle parameter, to indicate the month to which the Calendar's date is to be set, is 0-based?
I't just so natural isn't it? I mean I always express my dates in terms of 0-based months - doesn't everyone?

It would be interesting to know how many bugs have been caused by this one little gotcha.

razzasnazzagrizzumbonnafrazzasnazza.....

Not happy.... in fact one could use the word grumpy.

There, I've had my rant now; feeling better.

Tim

Well, for a start, it depends a whole lot on what country you're in. You've gotta remember this internet thingy is international. (Call me Sherlock Holmes, but I'm guessing you're in America? ) So, for example, here in Australia, the answer would be 'no'. Probably the same answer for the U.S., Britain and most of Western Europe. India and Asian countries however, I would have no idea.
The fact that you're asking tends to suggest that Sunday has some sort of significance in the country you're calling from.

You're better off contacting your local testing centre.

Cheers,

Tim

Laugh!

Just when we were all feeling smug, warm and fuzzy and all in agreeance, along comes Michael with the biggest spoke-mangling spanner I've seen for a long time. That is a magnificent catch. Love it - well done!

Loving it is one thing, but I'm stiil quite pleased the exam won't have such a question.

Cheers all,

Tim

Hi all,

regarding the other thread discussing Listener naming conventions, that was one of mine titled, imaginatively: "JavaBeans Listener naming conventions?" on Jan 31st, 2006.
But what Bert and Saskia have said above reiterates those comments - ie: by quoting from Section 8 in the JavaBeans API spec.

Cheers,

Tim
[ February 11, 2006: Message edited by: Timothy E. Hay ]

Hi Bert,

I don't actually see it as being that tricky a question - despite the fact I got it wrong first time round!
I thought it demonstrated quite well the concept which had been discussed in the chapter, and highlighted the need to look for chains of object references, as well as capital 'S's!
I suppose the trickiness for me was in mis-reading the Short object as a short primitive. I think the use of auto-boxing to create the object from the primitive value '5' probably contributed to that. Whereas, if it had been declared as:

Short story = new Short(5);

...that may have changed the outcome for me.

Anyway, I like the question because I got it wrong - it made me make a mental note to keep an eye out for this sort of thing.

Cheers,

Tim
It's just what I reckon, but it's what I reckon.

Hi Thanigai,

I'm in much the same boat as you - been a developer for 10 years (lived in the Microsoft C++ world for the first 6), and have been a Java developer for the last 4-5 years. This year I finally decided to do the SCJP, principally as a methodical approach to rounding out my understanding of Java 5 and the new bits and pieces. (OK, a pay rise might be nice too!).

I've found the Study Guide written by Kathy Sierra and Bert Bates combined with this forum have been an excellent way to study for it. One of the suggestions early on in the book is to write lots of little programs. I'm half way through the book and have written dozens - mainly just to try things out, especially variations on what's in the book. Each chapter gets it's own package. I can't recommend this technique highly enough. If you're not sure about something, try it out, experiment.

As for this forum, it's is one of the friendliest I've been involved with. Practically devoid of any of that attitude you so often get on other forums. Dunno how they does it, but I know they does it!

Of course, I haven't taken the exam yet, so take this with a couple of grains of salt, otherwise, I hope this is helpful.

Cheers,

Tim

Hi Jason,

it's actually like a common construction area, which is automatically called immediately after the (in this case implicit) call to super() in every constructor for the class. It's similar to declaring an init() method and calling that from each overridden constructor, to do common construction stuff.
A common use for it that comes to mind is as a common area for the initialisation of final members (if they're not being initialised at declaration) - which you can't actually do in the above-suggested init() method.

Cheers,

Tim

Hi Josh,

regarding your question as to what difference it would have made if the story member had been a short (with a lowercase 's') rather than a Short; a lowercase 's' short is a primitive, not an object. As such, it would never be eligible for GC. The member variable itself (story) exists as part of the Cardboard object, c2. As I understand it, this means that it exists on the heap, as part of the object it is a member of, but (if it were a short, and not a Short) is not an object itself.

For A. Kumar, the short answer is "yes". Edisandro has correctly named the issue at hand.

Cheers all,

Tim
[ February 08, 2006: Message edited by: Timothy E. Hay ]

Josh you are absolutely correct (or so I reckon).

The Short (with a capital 'S' and therefore an object, and therefore, in turn, allocated on the heap) is the reason I initially got this question wrong. I thought that c2 was the only object left, but forgot to look at objects referred to by *member variables* of c2. Bother. Self-application of a kick up the backside was tricky, but required.

A note for Venkatesh, the instance variable is a reference. It refers to an object (the Short (with a capital 'S')). Objects live on the heap, and thus at some time become eligible for GC. When c2 finally gets GC'd (sometime after main() finishes), the reference to the Short (story) will cease to exist. As such, the actual Short object will no longer have any references to it, and will also then become eligible for GC itself.

Am I helping?

Cheers,

Tim

There are three main reasons:

1) To ensure that for subsubclasses which eventually implement the method, the return type is narrowed to a subclass of the return type specified by the superclass.
eg:

class Fruit {} class Banana extends Fruit {} class SmallBanana extends Banana {} abstract class ClassA { abstract Fruit getFruit(); } abstract class ClassB extends ClassA { // Cannot return a Fruit, // must return a Banana // or subclass of Banana abstract Banana getFruit(); } class ClassC extends ClassB { Banana getFruit() { return new Banana(); } } class ClassD extends ClassB { Banana getFruit() { return new SmallBanana(); } } class ClassE extends ClassB { Banana getFruit() { return new Fruit(); } // Will not compile. } class ClassF extends ClassB { Fruit getFruit() { return new Fruit(); } // Will not compile //(not a valid overload). } class ClassE extends ClassB { Fruit getFruit() { return new Fruit(); } // Will not compile (go on, try it!) }

2) As already mentioned by Tia, to reduce the number of exceptions thrown by classes derived from the subclass, BUT ALSO to restrict the exceptions thrown by these classes' implementation to subclasses of the Exceptions declared in abstract method declaration in the superclass.

3) As already mentioned by Hamid and Tia, to increase the accessibility of the method in classes derived from the subclass - ie: from default or protected to public.

Cheers,

Tim

The way I see it now, if your javabean needs to register a Listener, the JavaBeans naming standard requires add and remove methods to be named with a prefix of 'add' and 'remove' respectively, followed by the name of the Listener. Now the tricky part that I couldn't find info on until Satou pointed me at the JavaBeans spec, is that Listeners themselves also have a naming standard stipulated by the JavaBeans API spec. That is, "where the �<EventListenerType>� type name ends with �Listener�." as stated in Section 8.4.
To relate it back to the question from the book (see previous post), 'addSize' does not fit this 'Design Pattern'/naming convention. Sure it has a prefix of 'add', but if 'Size' is a Listener (which it could be if you view it as a verb instead of a noun), it does not conform to the naming convention. To do so it would need to be named 'SizeListener'.

It's actually worth reading all of section 8 in the spec to get the reasoning behind the naming conventions. I won't reiterate it here, I'll leave that for readers to do in their spare time. But it's titled 'Introspection' and covers naming conventions for properties, events and methods.

In summary, I think the JavaBeans API spec is the ultimate source of information on this subject. An interesting excercise is to do a search through the document for the phrases 'convention' and 'design pattern'. There are quite a few.

I think I've prattled on long enough now, so I'll leave it there.

Hope this helps,

Tim