Win a copy of Beginning Java 17 Fundamentals: Object-Oriented Programming in Java 17 this week in the Java in General forum!

Dave Reinhardt

Ranch Hand
+ Follow
since Aug 07, 2006
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dave Reinhardt

questions about this code:
1. If you passed a single a1 thread to the two threads t and t1, would it then print 1-10 twice one after the other? That's what I would assume since now there are two threads working on a single runnable. see below

A a1=new A();
Thread t=new Thread(a1);
Thread t1=new Thread(a1);
t.start();
t1.start();

2. I know that Thread implements Runnable, and so that is probably why you can pass another thread to a thread constructor, but why would this method be preferable over creating a Runnable instance and passing it instead? It seems overly confusing to pass threads to threads, so I'm wondering if this design is real-world or just contrived for an exam question? In the first example are there still only two threads (ignoring main)since start is never called on a1 and a2?
you need: test.size coffeesize;

btw, java classes should start with a capital letter-- Test instead of test

I use eclipse to write java, and it's nice because it warns you of errors and programming conventions as you're typing---and best of all it's free!
I'm trying to go thru the SCJP book and also the Sun exam objectives and organize some notes on the subject of exceptions. All the exceptions listed in the objectives seem to be unchecked exceptions (they are subclasses of RuntimeException or Error). I see nothing listed on direct subclasses of Exception, so I'm wondering which checked exceptions were are supposed to know for the exam. Can anyone help or refer me to some notes on exceptions?

Here's what I have so far:

Exceptions:
java.lang.Object <-- Throwable<--Exception <-- RuntimeException
java.lang.Object <-- Throwable<--Error

Checked: ClassNotFoundException, DateFormatException, InterruptedException, IOException, NoSuchFieldException, NoSuchMethodException

Unchecked: RuntimeException, ArithmeticException, ClassCastException, IllegalArgumentException<--NumberFormatException, IllegalStateException, IllegalMonitorStateException, IndexOutOfBoundsException<--ArrayIndexOutOfBoundsException, NullPointerException, Error<--AssertionError, Error<--LinkageError<--ExceptionInInitializerError, Error<--VirtualMachineError<--StackOverflowError, Error<--LinkageError<--NoClassDefFoundError.

from Sun:
"Understand which of these are thrown by the virtual machine and recognize situations in which others should be thrown programatically."
I've read the section on this in K&B, and am still fuzzy on the concept, if someone could provide some clarity I'd appreciate that.

thanks
Yes, the difference is that the actual object is created in main, and it's that single object that is being passed around and refered to by multiple references.

When you see this:
StringBuffer sb = new StringBuffer("A");

It may help you to think of the thing on the left of the = as a reference and the thing on the right as the actual object. Since there's only one place in the code where you see "new" there's only one object being created. There are several instance references that are specific to the class instances, but they all point to this single object.

StringBuffer letter; // this is not a StringBuffer object, just a StringBuffer reference that will eventually refer to a StringBuffer object

I hope I'm understanding your question and this is helpful.
I was thinking that somewhere in SCJP they say you should only use assertions for conditions that should _never_ happen. During the life of the container, it should be allowed to be empty without getting an assertion error I would think. Maybe this is wrong...what do you think?
that's a good question, not sure I have the answer, but I will try.

I think the original StringBuffer object is passed by value to the 3 InSync constructors. Because what you're passing by value is really a reference to the object, you end up getting 3 new references to the same object. Then inside the method, you get 3 more references, but they are also assigned the same object.

Total 7 references to the same object:
sb references "A"
the 3 method local vars named letter reference "A"
and the 3 this.letter fields reference "A"

So, my guess is this is why they are all locking on the same object. I bet this is also why you can only lock on objects and not primitives. Since if you pass a primitive around, you get a new copy of that primitive. Let me know if this is wrong, I find this topic difficult too.
Unless this is a possible answer, I think there is a bug in the following code sample:

void start() {
InnerRun ir = new InnerRun();
Thread t = new Thread(ir); //wasn't passed the runnable ir
InnerRunTwo irr = new InnerRunTwo(t);
Thread uu = new Thread(irr);
t.start();
uu.start();
}

If you make this change then you will get 100 Ren and then 100 Stimpy. As it was in the original code, the thead t wasn't given a job(a runnable) to do.
I just re-read the link that Fred posted.

It appears that objects in the string pool are eligible for garbage collection, but not until the program is unloaded. So, for the exam, it seems to me it makes sense to think of all strings as objects that are eligible for GC if nothing references them. The specifics of the pool are not important for the exam.
SCJP page 413-415 reads:

String s = "abcdef";

is a shortcut for

String s = new String("abcdef");

Then they go on to show that the 1st example creates "abcdef" on the heap. figure 6.1

So it seems to me, by the K&B definition, that the answer to the original question is: 1 object is eligible for garbage collection.
Jegon,

That's a good point you make, but I was just trying to point out that you _could_ have an IS-A relationship in terms of Class B extending class A and have no possibility of polymorphism. So technically, the way I read the answer it is false.

That's the trouble with some of the questions that _should_ be easy questions on the exam. It's easy to write an ambiguous question about cohesion, or coupling, or polymorphism. I've come across several situations in the mock exams. Unfortunately, I read the questions very literally and then get the answer wrong. I would have phrased it as:

IS-A relationships usually rely on polymorphism
there are many programmers who are also musicians, I think they are similar disciplines on many levels. Several of my csci profs had undergraduate music degrees.
<Perhaps the question would have been better as "Polymophism always depends on the IS-A relationship - true or false?">

I can get behind this being true, but not the reverse.
It's my understanding that polymorphism is specifically when a super class reference refers to a sub class object. The runtime machine can polymorphically call the correct instance method based on the actual object. However, it seems to me that you could have this inheritance structure between two classes that have only static methods and there will be no polymorphism

So inheritance (IS-A relationships) are not always polymorphic. Amy I wrong about this?
true-- from the LearnKey exam.

Is this ALWAYS true? What if you have a class B that extends class A and they don't have any instance methods/vars--only static. Isn't there technically still an IS-A relationship between the classes with no chance of polymorphism?