New (as in days) to Java - question about "super()" method

[Don Bruder]

Let's start right from start, ala "12 step" meetings...

Hi, I'm Don, and I'm a serious greenie when it comes to Java.

(This is the part where you all say "Hi Don! Glad to have you here!")

"How serious,", you ask? Well, in the past 3-4 days, I've done a
"power-skim" of a "Learn Java on the Mac" book that came in PDF format
on my DE's install disk, I've got some code to look at/play with, and
I've been playing around in it for the last 2-3 days, give or take,
trying to get a feel for the language.

I come from a fairly extensive programming background - multiple
flavors of BASIC, 6502/65C02 assembler, 8086 assembler, Turbo and UCSD
Pascal, FORTRAN, COBOL, and a handful of others, including some serious
weirdos that are more for the sake of being able to say "I can (or
could at one time) code in _____" than any practical purpose. For the
past couple-four years, I've been doing my thing almost exclusively in
C, with a *VERY* minor foot-wetting in C++, and recently a foray into
Python that pretty much left me shaking my head and asking "Why
mistreat a computer that way?!?!?" (Not much different from my reaction
to its namesake TV program, if you want the truth) The list isn't to
brag, it's simply to put across the fact that I'm *NOT* a newbie to
coding, only to coding *in Java*.

So far, the PDF/book I'm using as a reference is serving me well, and
where it's lacking, my own programming experience is doing a reasonable
job of filling in the few blanks. However, I've encountered something
that the book doesn't address (although there is a tantalizing hint,
more in a moment) and nothing in my knowledge base can be safely
applied, since it's obviously something that's going to have its own
special Java meaning. To save newsgroup space, I've trimmed all the
guts out of the method involved (a constructor, I believe, is the
proper terminology in this case, no?), leaving only the parts that have
me puzzled:

/* Trimmage - lots of "import this.that.and.the.other" lines */

public class StartServer extends Thread {

/* Bunch of instance vars and several methods of class StartServer
elided */

public StartServer() {
super("Start Server"); /* This line is the one that's got me
scratching my head */
try {
/* bunch more eliding here */

} /* end of class StartServer, elide rest of file */

The calling/invoking/instantiating/whatever-you-wanna-call-it-ing
snippet:

public class Main {

/* Several irrelevant chunks of class Main that
obviously do "the boring stuff" elided */

public static StartServer start = null;

public static void main(String[] args) {
/* elide some self-explanatory stuff - instance vars and some setup work
*/
start = new StartServer(); /* There it is... */

/* elide the rest */

The hint the book drops:
Inheritance and discussion of the concept of extending, rather than
flat-out overriding, the behavior of a class and its methods talks
about prepending "super." to the method name, which will have the
effect of invoking both the instantiation's version of the method, AND
the parent object's version of the method.

That's all well and good, but it doesn't QUITE manage to touch on what
I'm looking at. Or does it? I can't help but think that it's at least
related somehow...

I can't figure out what the "super("Start Server");" invocation is
invoking. As *I* understand the languageso far, there's a
"period-something" missing between the end of "super" and the "(", so
it doesn't parse to anything sensible to me.

At no time does "super()" appear to be declared/defined/instantiated,
or anything-elsed by anything in the source code. Which makes me think
it must be one of two things: a special notation that I haven't learned
about yet, or a method that's hiding in one of the
java.something.something "library" packages that get imported every
which way but loose.

Obviously, I've missed something relatively important.

Anybody wanna spray-paint it flourescent green and hand me a
black-light?

 

[Antti S. Brax]

Let's start right from start, ala "12 step" meetings...

No, please. Don't waste our time. Cut right to the question.
Most people stopped reading your question after the second
line.

public StartServer() {
super("Start Server"); /* This line is the one that's got me
scratching my head */

Calling method "super" in a constructor calls the superclass'
constructor (in this case Thread's constructor).

You see, unless otherwise specified, when starting to execute
a constructor the JVM implicitely calls superclass' zero
parameter constructor so that for example all private attributes
in the superclass will be initialized properly. In this case
you override that rule and tell the JVM to call Thread(String)
constructor instead.

Naturally, if you want to call super in your constructor, it
must be the very first thing.

The hint the book drops:
Inheritance and discussion of the concept of extending, rather than
flat-out overriding, the behavior of a class and its methods talks
about prepending "super." to the method name, which will have the
effect of invoking both the instantiation's version of the method, AND
the parent object's version of the method.

Yes, that is when you are calling normal normal methods.

 

[Antti S. Brax]

Calling method "super" in a constructor calls the superclass'
constructor (in this case Thread's constructor).

You see, unless otherwise specified, when starting to execute
a constructor the JVM implicitely calls superclass' zero
parameter constructor so that for example all private attributes
in the superclass will be initialized properly. In this case
you override that rule and tell the JVM to call Thread(String)
constructor instead.

Naturally, if you want to call super in your constructor, it
must be the very first thing.

Forgot these:

http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.8
http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.8.7

 

[.]

Let's start right from start, ala "12 step" meetings...

The crowd here is quite different from the group you'd find at any "12
step" meeting. Might not be the best approach.

Hi, I'm Don, and I'm a serious greenie when it comes to Java.

(This is the part where you all say "Hi Don! Glad to have you here!")

"How serious,", you ask? Well, in the past 3-4 days, I've done a
"power-skim" of a "Learn Java on the Mac" book that came in PDF format
on my DE's install disk, I've got some code to look at/play with, and
I've been playing around in it for the last 2-3 days, give or take,
trying to get a feel for the language.

I come from a fairly extensive programming background - multiple
flavors of BASIC, 6502/65C02 assembler, 8086 assembler, Turbo and UCSD
Pascal, FORTRAN, COBOL, and a handful of others, including some serious
weirdos that are more for the sake of being able to say "I can (or
could at one time) code in _____" than any practical purpose. For the
past couple-four years, I've been doing my thing almost exclusively in
C, with a *VERY* minor foot-wetting in C++, and recently a foray into
Python that pretty much left me shaking my head and asking "Why
mistreat a computer that way?!?!?" (Not much different from my reaction
to its namesake TV program, if you want the truth) The list isn't to
brag, it's simply to put across the fact that I'm *NOT* a newbie to
coding, only to coding *in Java*.

The problem here is that we don't know how you learned this stuff. I was
self-taught and had a list FAR longer than your list. Wasn't prepared to
learn Java because Object Oriented Programming is quite different from
procedural or assembly programming. Went to university and learned all
about the theory behind different programming languages. Learning Java
became much easier. Bottom line, I knew a lot before going to university
but there were gaps in my knowledge that made learning OOP difficult.

So far, the PDF/book I'm using as a reference is serving me well, and
where it's lacking, my own programming experience is doing a reasonable
job of filling in the few blanks. However, I've encountered something
that the book doesn't address (although there is a tantalizing hint,
more in a moment) and nothing in my knowledge base can be safely
applied, since it's obviously something that's going to have its own
special Java meaning. To save newsgroup space, I've trimmed all the
guts out of the method involved (a constructor, I believe, is the
proper terminology in this case, no?), leaving only the parts that have
me puzzled:

[lots of code snipped]

If you see something like:

super("start server");

you are dealing with inheritance and constructors. Learning two concepts
at once can be confusing. Learn one then the other.

Constructors: if I have a class called MyFabulousClass it can contain
methods. If the name of the method is the same as the name of the class,
e.g.

MyFabulousClass() {
// your code goes here
}

then it is called a constructor. When you create an instance of the class
it calls the constructor, e.g.

MyFabulousClass test = new MyFabulousClass();
^ ^ ^
| | |
| | constructor
| instance
class

Second topic, inheritance: if I have a class and I want to add some extra
functionality to it I can use inheritance. For example, I have the class
Human. I want to add the method Urinate(). A Man does this different than
a Woman. So I will have:

class Man extends Human
and
class Woman extends Human

I'll then add a Urinate() method to each class. Methods like Sleep() and
Eat() will come from Human. That is inheritance.

Now we can answer your question, what is super(). If I create a contructor
for Man it might look like:

Man(String name) {
super(name);
// do stuff for Man
}

Because Man extends Human, the super(name) is calling the parent
constructor, i.e. it is calling Human(name). You will also see things
like:

this(name);

If I have more than one constructor, e.g.

Man() {
name = "Joe Public";
}

Man(String s) {
name = s;
}

I can write it as:

Man() {
this("Joe Public"); // use the constructor below
}

Man(String s) {
name = s;
}

Before you go any further, I think you want to get a good book that
clearingly explains things like inheritance, interfaces, overloading, etc.
In other words, all the Object Oriented concepts. You want to question why
we need Java? Why cannot everyone write everything in C, COBOL or Scheme?
If you find the answer to that you will find learning Java much easier.

 

[jan V]

Let's start right from start, ala "12 step" meetings...

Friendly tip: I started reading your post, kept reading, and reading.. then
noticed the scrollbar to the right telling me I had only read 20% of your
post... so -verbose=PLAIN (please).

 

[Don Bruder]

No, please. Don't waste our time. Cut right to the question.
Most people stopped reading your question after the second
line.

Jeeze... tough crowd... *SOMEONE* apparently read through, though.

Calling method "super" in a constructor calls the superclass'
constructor (in this case Thread's constructor).

Bingo. There's the missing piece I needed.

You see, unless otherwise specified, when starting to execute
a constructor the JVM implicitely calls superclass' zero
parameter constructor so that for example all private attributes
in the superclass will be initialized properly. In this case
you override that rule and tell the JVM to call Thread(String)
constructor instead.

Naturally, if you want to call super in your constructor, it
must be the very first thing.

I don't (yet - maybe with a few more days of learning) see the
"Naturally, ...it must be..." part, but regardless of the language, it
does make good basic sense to get everything, including inherited
privates/protecteds, into a known state before doing any further
tinkering in a new class, even (maybe "particularly") if that tinkering
is nothing more than class construction.

Yes, that is when you are calling normal normal methods.

Got it. Thanks.

 

[Don Bruder]

Friendly tip: I started reading your post, kept reading, and reading.. then
noticed the scrollbar to the right telling me I had only read 20% of your
post... so -verbose=PLAIN (please).

Yeesh! What a crowd! I post a question with all the details that seem
likely to get me an answer, and what do I get back? One answer with
handy cites accompanied by a mini-lecture/grump about the length
(Thanks, "Antti S. Brax" - despite the grumping), a lecture that could
have come from the teacher with the world's biggest "You pathetic
maggots aren't worthy to lick the crap off my boots, let alone learn
something from me" complex, and a gripe that I posted too much!

I guess next time I've got a question, I should try a subject line of
"It don't work! Why?!?" and body of "Subject says it all! HELP!"?

Then again, it might just work, without getting me treated like I just
tried to off the pope... Fergawdsake, people, lighten up already!

 

[Don Bruder]

<snip lecture>

While I appreciate the effort, most of your post was wasted on creating
an "I'm so superior to you" feel that I just had to say something about
it.

Before you go any further, I think you want to get a good book that
clearingly explains things like inheritance, interfaces, overloading, etc.
In other words, all the Object Oriented concepts.

I've already got what I consider to be a pretty good grasp on the
concepts involved in OOP. What I was lacking was a clue that "super()"
alone equals "call the ancestor's constructor".

You want to question why
we need Java? Why cannot everyone write everything in C, COBOL or Scheme?
If you find the answer to that you will find learning Java much easier.

Wha-huh???? Who pissed in yur cheerios, matey?
Where the hell do you get the concept that I'm questioning the "why" of
Java? Or care that someone can/can't write everything in COBOL? Or have
any interest in the answer?

Suggest you stick to talking to the computer - At least it won't mind
your holier-than-thou attitude.

 

[Monique Y. Mudama]

I don't (yet - maybe with a few more days of learning) see the
"Naturally, ...it must be..." part, but regardless of the language,
it does make good basic sense to get everything, including inherited
privates/protecteds, into a known state before doing any further
tinkering in a new class, even (maybe "particularly") if that
tinkering is nothing more than class construction.

It's not obvious on first blush, but it does make sense once you think
about it.

If you have a class Foo that extends Bar, when you instantiate Foo
(call its constructor), a Bar object is always created "under the
hood", and then the Foo stuff is added onto that. Foo really is a
Bar. You need to have the Bar object in place before you can start
adding Foo stuff to it, so you need to construct the Bar object before
you do anything in Foo. If your constructor uses no arguments, this
is handled for you by the compiler, but if you need to use a Bar
constructor that has arguments, you need to tell it that yourself.

The book Thinking In Java by Bruce Eckel has some excellent step by
step examples to demonstrate the order in which things happen upon
construction. I think it would be very helpful to you.

 

[Monique Y. Mudama]

Then again, it might just work, without getting me treated like I
just tried to off the pope... Fergawdsake, people, lighten up
already!

Dude. I agree that the atmosphere is a little harsh here, but that
being said, the best way to get useful help from a newsgroup is to
follow its guidelines. It's also a good idea to lurk for a while. If
you'd done that, you'd have already figured out the kind of atmosphere
and response you were likely to encounter. Lambasting a group for its
character does not typically result in all of the group members
changing their minds, apologizing for their wicked ways, and providing
you with detailed answers for the rest of your days.

I did something against guidelines in my first post here, too, and
unsurprisingly got little response. But I'm not annoyed at the group;
I'm annoyed at myself for not taking the time to lurk and find the
guidelines first, which would have made my first foray more
successful.

 

[.]

Yeesh! What a crowd! I post a question with all the details that seem
likely to get me an answer, and what do I get back? One answer with
handy cites accompanied by a mini-lecture/grump about the length
(Thanks, "Antti S. Brax" - despite the grumping), a lecture that could
have come from the teacher with the world's biggest "You pathetic
maggots aren't worthy to lick the crap off my boots, let alone learn
something from me" complex, and a gripe that I posted too much!

I don't know about most people but I read this group while something is
compiling, unit tests are running or I'm waiting for someone to get back
to me. I pop in here to see if I can learn something new or to see if I
can help someone (helping someone helps me to reinforce that knowledge).

I suggest to verbose posters that they should try to be concise so that I
might be able to help them. If it takes too long for me to read and
understand the problem then I'd just skip it.

If you came here looking for help and you are doing something that is
stopping me from helping you then I feel obliged to let you know. Once you
know, you have the choice to ignore me and post very verbose messages or
to be more concise and obtain my help.

 

[Andrew Thompson]

I guess next time I've got a question, I should try a subject line of
"It don't work! Why?!?" and body of "Subject says it all! HELP!"?
LOL!

Then again, it might just work, without getting me treated like I just
tried to off the pope... Fergawdsake, people, lighten up already!

<not that I think it needs saying, but sounds good..>
...aaaah, they were just takin' a poke. Chill.
</not that I think it needs saying, but sounds good..>

It's the multi-posting, top-posting, (excessively) x-posting,
trolling, spamming, SCREAMing ..or otherwise cretinous posters
that might get a full-on flame!

And hey - I'm with you on 'err on the side of more detail',
rather than 'vaguely wave your hands about' in the hope someone
may accidentally recognise the exact problem you are
experiencing.

As an aside. Folks are a lot ..gentler, on c.l.j.help,
<http://www.physci.org/codes/javafaq.jsp#cljh>
but then, ..I suspect you do not need a 'gentler' group.

Oh, BTW.. Welcome to c.l.j.programmer. ;-)

 

[Andrew Thompson]

I don't know about most people but I read this group while something is
compiling, unit tests are running or I'm waiting for someone to get back
to me. I pop in here to see if I can learn something new or to see if I
can help someone (helping someone helps me to reinforce that knowledge).

I suggest to verbose posters that they should try to be concise so that I
might be able to help them. ..

<nothing deep intended>
I find that ironic, given you offered up around 100
lines of detailed, carefully formatted advice, as
an answer.

...If it takes too long for me to read and
understand the problem then I'd just skip it.

I see your point about the poster being brief to be noticed,
though I usually argue the opposite - be detailed, ..with a
catchy intro. to hook people in.

If you came here looking for help and you are doing something that is
stopping me from helping you then I feel obliged to let you know. Once you
know, you have the choice to ignore me and post very verbose messages or
to be more concise and obtain my help.

Simply and plainly stated.

What about medium (perhaps with a catchy intro.)?
What are your limits (if you can put them into words)?
- All up, 2 screens of your news client?
- Openning paragraph has to be a gripper.
- Must hook you in, in the opening sentence?
- ..are you ignoring me? No - don't answer that. [ ;-) ]

 

[Thomas Weidenfeller]

Yeesh! What a crowd! I post a question with all the details that seem
likely to get me an answer, and what do I get back?

Ask for a refund.

/Thomas