I'm currently on "Providing Constructors for Your Classes" under "Classes and Objects in the Java Tutorials, and so far I've learned quite a few new stuff that I didn't know before. You might be tempted and say "I know this topic, so I'll skip this one." but don't do that! You might find out something new you don't know. Or I'm just stupid. Hahaha.

The example for this one is really good, checking for the number of days per month. I don't know if all of you know this and if so please bear in mind that I always forget how to do switches as I'm not particulary fond of them. Yeah. my bad.

- Labeled breaks and continues
I didn't even know there were labeled stuff in the Java language! Basically a label is giving a name to a particular code block, like this:

It will stop execution of that particular loop. What is it good for, you ask? I guess you can use it for nested loops and break inside a particular one, for example you have 5 nested loops(Inception!) you can theoretically break from one of those, but I've never found a circumstance where I had to do that. The continue on the other hand uses the continue statement for that particular labeled code block.

- Make sure your superclass has a default no argument constructor!
Wait, what? The tutorial says that if you've extended a class and you call that class with a no argument constructor, then you must make sure that the superclass has a no argument constructor. If you don't extend another class, then the superclass would be the Object super super class(god class, the class where it all began, mother class, number 1 class, ancestor class, the oldest class, whatever) which has an explicit declaration of a no argument constructor.

But wait? Doesn't it mean that if you extend a superclass and that one has a no argument constructor then wouldn't it logically look for a no argument constructor in the Object class since it is the parent of all classes?

4 Comments On This Entry

Good stuff. One minor quibble - your first example, the switch, won't compile because you have a duplicate case 2.

I agree that the documentation on the no-arg constructor is confusing, but I think what they're getting at (and doing it badly) is that if you had a constructor that took, say, an int, that this would block the default constructor.

As for labeled blocks, you're right on both counts. You'd use those to exit a loop, and if your loops are deeply nested this would exit to the named loop. However, as you say, this is only of limited use if you're making reasonable use of objects and methods.

Personally, I can't think of a single time I've used labelled blocks in java except to test the functionality either for myself or to answer a question in the Java forum.

I didn't notice the multiple case, thanks for spotting that one. I find some of the stuff in The Java Tutorials are quite inconsistent, and there are typos too, my guess is no one has updated them yet. I plan to send them an email of those spelling errors I've found out and maybe I'll try to ask that they clear some of the topics there too.

I don't get what you said on your second paragraph, wouldn't creating another constructor that takes an integer argument be independent of the default no argument constructor?

I didn't notice the multiple case, thanks for spotting that one. I find some of the stuff in The Java Tutorials are quite inconsistent, and there are typos too, my guess is no one has updated them yet. I plan to send them an email of those spelling errors I've found out and maybe I'll try to ask that they clear some of the topics there too.

I would love to see those corrected, and I hope you pursue this. However, I have to say I've heard some complaints about Oracle's lack of initiative in addressing bugs on the Java issues list, and I wouldn't be surprised to see this without resolution as well.

Quote

I don't get what you said on your second paragraph, wouldn't creating another constructor that takes an integer argument be independent of the default no argument constructor?

That would be a little Java "gotcha". The default constructor is only inherited if there are no constructors defined for that class. So if you define a class Foo as follows:

this will fail at compile: symbol not found. You'd have to write an explicit no-args constructor - with an empty body - to get the expected behavior (call the Object constructor).

The reasoning here is reasonable I suppose. If you specify any constructors, it's assumed that you're providing what you want. The default is only provided if you don't specify anything. And this makes sense, because you'd like to be able to prevent people from creating null objects. Looking back at my Foo object, suppose I want it to be an immutable object with an int value. I don't want to provide any set methods - it's immutable. Therefore, there's no reason for anyone to create an object without specifying an int for it. If I want a no-object constructor, then, I have to provide one (perhaps it would default to some value). But it would make no sense to allow the default constructor in that case.

Another reasonable approach would be to provide the default constructor in any case, and let me override that by providing a no-arg constructor which maybe throws an Exception - but then the compiler sees a no-arg constructor and so

Foo foo = new Foo();

passes the compiler, which we don't want.

So it makes sense, but you have to follow the logic through a little. It's certainly not intuitive.

Everything makes sense now. I learned from your example that every Java class should have a constructor and if you define an explicit constructor then it would automatically be the default constructor, and the no argument constructor is now out of the picture, unless you create one in your class. Thank you very much.