two questions

[Pete]

Hi All,

Just revising for my SCJP exam and have a couple question I trust you
will be able to help please.

1)

below is a package structure for a set of classes

com -- foo ( 1st level dir)
bar ( 2nd level dir)
dog ( class )
blatz (3 level dir)
Book ( class )

-- bar (1st level dir)
Car (class)
blatz (2nd level dir)
Sun (class)


Insert 3 statement in the following code from choice below

<insert statement 1>
<insert statement 2>
<insert statement 3>

public class Car {
Book book;
Dog dog;
}

Choices

a) import com.foo.bar.blatz.*;
b) import com.bar.*;
c) package com.bar;
d) import com.foo.bar.*;
e) package com.foo.bar.blatz;
f) import com.*;
g) package com;
h) //blank
i) import com.foo.bar.Book;

The first statement has to be c).

However, the next could be either

1) import com.*;
//blank
//blank

or
2) import com.foo.bar.*;
//blank
//blank
or
3) import com.foo.bar.*;
import com.foo.bar.blatz.*;
//blank


But there is only one correct answer .... am I missing something
( probably ) .. can someone explain !!



2) My second question is to do with threads.

public class foo extends Thread implements Runnable {

public void run() { };

}

As both Thread & Runnable have run() as abstract, is it ok for Foo to
provide
definition of run as above ?
If correct, is the run assoicated with Thread abstract method of the
Runnable abstract method.


Thank all for you help.

Pete

 

[Mark Space]

1) import com.*;

This imports nothing. * imports classes, not packages. Packages are
not hierarchies. They don't nest. Each package is a discrete thing, so
importing com.* would only import any classes in package com, but not
com.bar.Book, because that's a different package.

//blank
//blank

or
2) import com.foo.bar.*;

imports "Dog".

//blank
//blank
or
3) import com.foo.bar.*;
import com.foo.bar.blatz.*;

imports "Dog" and "Sun"

So none of these work. I got c, a and d.

public class foo extends Thread implements Runnable {

public void run() { };

}

As both Thread & Runnable have run() as abstract, is it ok for Foo to
provide
definition of run as above ?

I don't think so, although I'd have to look it up. There's a special
syntax for method declarations when there are name collisions due to
inheritance.

I'm not seeing it in the JLS right now, so I might be misremembering and
there is no special syntax (I might be thinking of chaining inheritance
to rename one of the methods so both can be accessed) but the syntax you
have is not legal.

 

[Daniel Pitts]

I don't think so, although I'd have to look it up. There's a special
syntax for method declarations when there are name collisions due to
inheritance.

I'm not seeing it in the JLS right now, so I might be misremembering and
there is no special syntax (I might be thinking of chaining inheritance
to rename one of the methods so both can be accessed) but the syntax you
have is not legal.

Actually, it legal, although the ";" is unnecessary.
Also, the class name should be "Foo" not "foo" to follow propery naming
conventions.
Thread already implements Runnable, so Foo implementing it is
superfluous, overriding run() if Foo is perfectly valid (and one
approach to creating a worker thread).

 

[Pete]

Actually, it legal, although the ";" is unnecessary.
Also, the class name should be "Foo" not "foo" to follow propery naming
conventions.
Thread already implements Runnable, so Foo implementing it is
superfluous, overriding run() if Foo is perfectly valid (and one
approach to creating a worker thread).

Mark, Daniel

Thank you for your replies.

My "wrong" understanding was import com.* would allow for classes in
the com directory AND in the sub directories.

As to my second question ..it is interesting that it is possible and
just the sort of question that could crop up in the SCJP exam... and
thank you for the syntax and naming corrections.

Pete.

 

[Mike Schilling]

This imports nothing. * imports classes, not packages. Packages
are
not hierarchies. They don't nest. Each package is a discrete
thing,
so importing com.* would only import any classes in package com, but
not com.bar.Book, because that's a different package.


imports "Dog".


imports "Dog" and "Sun"

So none of these work. I got c, a and d.

I agree that those are the answers the test-writers want. In the real
world, though, "*' imports are a bad idea, as they make it difficult
for someone trying to maintain the code to see what's being imported
from where.

import com.foo.bar.Dog
import com.foo.bar.blatz.Book;

is superior.

 

[Daniel Pitts]

I agree that those are the answers the test-writers want. In the real
world, though, "*' imports are a bad idea, as they make it difficult
for someone trying to maintain the code to see what's being imported
from where.

import com.foo.bar.Dog
import com.foo.bar.blatz.Book;

is superior.

That depends on the tools that you use. My favorite IDE actually hides
the imports from me, but I can quickly determine which instance of a
class is being referred to, simply pressing ctrl and hovering. That
way, I never have to "parse" the import statement. However, the down
side is that even as an experienced (and dare I say "expert") Java
programmer, I tend to forget where standard classes actually live
Which seems to be detrimental to the SCJP scoring.

Ah well, productivity vs certification, which is more worth while?

 

[Mike Schilling]

That depends on the tools that you use. My favorite IDE actually
hides the imports from me, but I can quickly determine which
instance
of a class is being referred to, simply pressing ctrl and hovering.

Mine does the same thing. However I can't assume that everyone
reading my code is using an IDE with that capability (or an IDE at
all). And there are times I'm not using an IDE, for instance when I'm
browsing file versions in our SCM system. Fortunately, the IDE also
lets me set "always use individual imports" for a class, so there's no
effort in making the imports useful to all readers.

 

[Mark Space]

Actually, it legal, although the ";" is unnecessary.

Thanks for that correction. I dug through some books and I couldn't
find the section I thought I had read as "not legal" but I couldn't find
it. I must have simply misremembered.

 

[Roedy Green]

As both Thread & Runnable have run() as abstract, is it ok for Foo to
provide

A method can do triple duty, implementing an abstract method, and
implementing methods of two different interfaces.

 

[Daniel Pitts]

A method can do triple duty, implementing an abstract method, and
implementing methods of two different interfaces.

N different interfaces, actually, up to the limit of the number of
interfaces a class can implement.

 

[Mike Schilling]

A method can do triple duty, implementing an abstract method, and
implementing methods of two different interfaces.

Suppose class C contains method M. M can implement interface I1 in subclass
S1 of C and interface I2 in subclass S2 of C, even though S1 doesn't
implement I2, S2 doesn't implement I1, and C doesn't implement either of
them.