rob mcfarland

Greenhorn
+ Follow
since Oct 04, 2000
Merit badge: grant badges
For More
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 rob mcfarland

There is a fair bit of stuff to learn with IO and I found it helped to remember the class hierarchy structures. For example classes derived from InputStream have pretty much the same structure (and names) as ones derived from OutputStream. The same applies to Reader and Writer. Definitely learn the constructors - many of them take the same arguments. Learn the File class well. In terms of methods, a lot of them are inherited from the abstract superclasses so once you've learnt them (there's not that many) you only really need to worry about the extra ones provided by DataInputStream and DataOutputStream.
Most of the questions I encountered on the exam concentrated on the more commonly used classes, FileInputStream, DataInputStream, File and RandomAccessFile.
Cheers,
Rob.
Sagar,
My understanding is that even if there is a static synchronized method which has obtained a class level lock, non-static synchronized methods can still be run, as they'll be trying to obtain a lock on the object itself so there is no contention. (I've written some code to prove this) Non-synchronized method can be run willy-nilly irrespective of what locks static or non-static synchronized methods have as they're not bothered about locks at all.
Cheers,
Rob.
Kishor,
I think it's dangerous to take the objectives literally and as a result only learn the classes they mention. I took the test yesterday and there were a whole bunch of questions on StringBuffer which is not mentioned explicity (I don't think) in the objectives. I would take the approach of learning quite thoroughly any packages they mention and I would also take the time to learn the Collections APIs as well as just their general features (uniqueness/sorting etc) - you never know, you may need to use them one day! I don't know how pressured you are for time, but there would be nothing more annoying than getting questions which you don't stand a hope of getting right just because they're on areas you haven't revised.
Cheers,
Rob.
Asundar,
I know its easy to say, but don't get too disheartened. At least next time you'll know what to expect. Its very easy to spend a lot of time re-reading a relatively easy question just because of nerves/uncertainty and as a result not end up with very much time for the longer ones. One tip I used when I took it was to always read the answers first before clicking the exhibit button. At least that gives you an idea as to what you're looking for. If none of them say "compilation error" then you know that you haven't got to scan every line looking for a wrong spelling or capital letter.
The best of luck for next time,
Cheers,
Rob.
Mohit,
Apologies for the delay in getting back to you. I had my SCJP exam yesterday so I had to
focus on that! I really appreciate you taking the time to look at the code - its starting
to drive me mad!! I do have a couple of questions/points regarding your version:
1) If you change the notify() to a notifyAll() in the Supply class, then you'll start
to see the same problem I was having where one of the Demand objects falls over with an
Exception as there aren't any Integers to fetch. This is what I don't understand. I
thought the only difference between notify and notifyAll was that notifyAll gave all
waiting threads the chance to reacquire the lock, but at the end of the day only one
will be successful which is the same result as notify. I can't see why making this
change means that one of the Demand threads starts falling over. A thread which wakes
up but fails to acquire the lock should go back to waiting and won't try again until
another notify is called. (ie another Integer has been built by Supply)
This doesn't seem to be happening. As soon as the thread
which did acquire the lock exits its synchronized block, the other thread wakes up
and goes to get an Integer which it then finds doesn't exist.
2) After changing the notify to a notifyAll, you can stop the thread from falling over
by moving the code which removes the Integer from the ArrayList back inside the
synchronized code loop. To be honest I think this is where this code should go anyway as the
thread should still be synchronized on the list until it has removed the Integer. Once
this has happened the Supply object can build another one and both threads can compete
to see who should remove it. However, the same thing is happening, ie as soon as the
thread that has removed the Integer exits its synchronized block, the other thread
wakes up from its waiting state and checks the List even though another notify hasn't
been called. You can see this in the output as the following statements will be
consecutive:
Demand 1 : Yes, I'm in for a wait- got lock on List but List is empty
Demand 1 : ...finished waiting- finished waiting (been woken up by other Thread exiting synchronized block)
Demand 1 : Yes, I'm in for a wait.- however, List is still empty as Supply hasn't created another Integer yet.
So in summary, I'm not sure I'm any closer to understanding the problem here! However,
between the two of us I'm confident we can crack it! I'd be very interested to hear your
thoughts on it.
Cheers,
Rob.
Just passed the new exam with 96% and thought i'd attempt one of those inspirational postings that so
helped me when I was considering giving up and going back to being a C programmer! The exam is
straightfoward as long as you're very comfortable with the basics. There's a lot of overriding/
overloading questions so spend a lot of time on that. I agree with many of the other posts in
that the best way to do that is to write a lot of code. The biggest piece of advice I have is
not to worry about the little idiosyncracies of the language. In the ideal situation everyone would have
two years to prepare for the exam and learn the language back to front. In reality you may have
six weeks and trying to learn every minute detail just isn't possible. When going through the
various mocks I met so many questions which relied on knowing facts like passing a string
other than "true" or "false" to a Boolean constuctor would result in a value of false which to me are
pretty irrelevant. In the real world you're never going to write or have to read code like that
and checking those things out when you have to is what the API documentation is for. I agree
wholeheartedly that there is a difference between learning the language properly and just learning
it for the exam but I don't think knowing these sorts of things makes you a better programmer. Writing lots
and lots of code and reviewing code other people have written is a better way. The good thing is
the exam doesn't test you on these things, it just tests you on the basics - but you do need to know them thoroughly. The
questions were all worded better than any of the mocks I took - there was never any ambigiouty. As
for the time, I only had 18 minutes to check through which meant I could only review the half a dozen questions I'd
marked. I would have a good stab at each question the first time through. Something
that worked for me was that I spent about 5 minutes before starting the exam just writing out on the paper
that they provide the important class hierarchies, stuff like IO, Events, Containers, Collections. This meant
that when I had a question which relied on remembering what inherited from where, I could just look at these notes
and not work myself into a frenzy and possibly making a stupid mistake by trying to remember. Ok, a few more specific points:
1) IO stuff was very straightforward. Nothing on any of the more obscure classes like PushbackReaders etc.
Focussed on things like File, InputStreamWriter, DataInputStream, FileInputStream etc.
2) Collections. Very easy. No API calls to remember - just the characteristics of the collections -
ability to contain duplicates, natural ordering etc.
3) Overriding/Overloading - loads of stuff on this. Also a lot
of questions which relied on knowing whether you could change the modifiers of methods defined in
abstract classes or interfaces which the class extended/implemented.
4) Definitely read the tips/traps section in the Javaranch FAQ. A lot of these came up - calling
non-static methods from static ones, = instead of ==, that sort of thing.
5) AWT wasn't too bad. Focussed on layout managers. I did get a question about GridBagLayout and
you need to know the implications of nested containers with different layout managers and the
effect that will have on the contained components when they're resized.
6) Threads - wasn't as bad as I was expecting. Big emphasis on synchronisation and I found it
really helped to draw out pictorially what was happening in terms of threads/locks etc.
Hmm...can't really think of much else. Don't get too worried about mock scores. I was scoring 85 - 95 on the
ones I took (Marcus Green, Jxam) but there was always at least one question which could be interpreted in
a different way or was badly worded which just won't happen in the exam. As for the exam, I got 2 wrong in
Declaration/Access control. Everything else was 100%
I haven't checked out all the various Java sites that are available, but this one seems excellent. I don't
know how the moderators find the time to answer so many questions and in such detail but you're all doing a
great job. Good luck to anyone else taking it in the near future.
Cheers,
Rob.
PS - Meant to mention this initially. I referred to Ivor Horton's Beginning Java 2 for the basics. Its very good with lengthy explanations and then it was onto to trusty Billy Brogden's Exam Cram which really makes you focus on whats important (for the exam). I read the JLS a couple of times, but its so dry its hard to remember stuff from it and then I would just go through every post on Javaranch each day. Oh, and of course, Mahas site with the various discussions and mock exams which is excellent.

[This message has been edited by rob mcfarland (edited October 17, 2000).]
Vivek,
Yes, I've studied all the discussion threads on Maha's site and unfortunately none of them really cover this. My understanding is that when a thread enters a wait state (by calling wait()) within a synchronized code block on a specific object (synchronized(obj)) then the only way it can come out of this wait state (apart from another thread calling interrupt()) is for another thread to call obj.notify() or obj.notifyAll(). My example contains two threads both waiting on the same resource. obj.notifyAll() is called and only one thread should get the lock and continue. The other should continue waiting until the next call to obj.notifyAll(). That doesn't seem to be happening. The second thread comes out of its wait state when it feels like it. Any help would really be appreciated.
Cheers,
Rob.
Several recent postings from people who've taken the new exam have emphasised how important it is to have a solid understanding of Threads and their sychronization. I thought I had a fairly solid understanding until I managed to write some code where a Thread is removed from a wait state on a particular object without another Thread having called notify() or notifyAll() on that object. My whole basis of Thread understanding is threatening to crumble around me and I desperately need some guidance. I originally posted this question in the Threads forum yesterday and although have had one reply (thanks for that) it still hasn't really cleared it up. Unfortunately the code looks fairly daunting, just because there's a fair bit of it, but what its doing really is very straightforward. I'm sure I'm making the sort of mistake a recently born infant could spot but I'm suffering from code blindness. If anyone feels brave enough to tackle it, its posted under the same title 'Thread Communication'. All I can offer in the way of an incentive is potentially a marriage proposal (don't worry, you don't have to say yes). If thats not enough, just think of the sense of mental superiority.
Yours hopefully,
Rob.
I'm having a Threads nightmare. I've been trying all day to write some relatively simple
code whereby a Supply object places Integer objects in an ArrayList one at a time and
two Demand objects compete to remove them and process them. I've read the JLS and various
textbooks but I still can't work out why its not working as I think it should. If
anyone has the time and patience to explain to me whatever annoyingly simple mistake
I'm making, I would be eternally grateful. I've slimmed down the code as much as I can
but there's still quite a lot of it I'm afraid. Here goes:

Basically I thought that the first Demand object would start, succeed in getting a lock
on the ArrayList and then after finding it was empty, call wait and so relinquish the lock.
Meanwhile the second Demand object does exactly the same thing : gets the lock, finds its
empty and then calls wait. So the two Demand objects are both waiting on the same
object (ArrayList). Then the Supply object comes along, acquires the lock on ArrayList,
creates an Integer and adds it to it, then calls notifyAll to tell the Demand objects
about it. One of the Demand objects succeeds in reacquiring the lock and processes the
Integer. Now this is the bit I don't understand. When this Demand object leaves
the synchronized code block, the second one seems to come out of its wait state. Why??!!
I thought only a notify or notifyAll would cause a thread to leave its wait state. Needless
to say the Supply object hasn't supplied another Integer yet and the second Demand object
tries to access an empty ArrayList creating an Exception. Help....!
Ajith
Apologies for the lack of line numbering - that was a schoolboy error. Many thanks for the previous thread references and garbage collection explanations. I get the feeling that this particular discussion point is out of scope for the exam.
I promise to use the Search facility in future!!
Cheers
Rob.
After a week or so of being a passive Javaranch participant, I've plucked up the courage to actually post something. Following is a question from Exam Cram by Bill Brogden:
1. public void countDown(){
2. for (int i = 10 ; i >= 0; i--){
3. String tmp = Integer.toString(i);
4. System.out.println(tmp);
5. }
6. System.out.println("BOOM!");
7. }
When the program reaches line 6, how many of the String objects creatd in line 3 are eligible for garbage collection? (Assume that the System.out object is not keeping a reference.)
a) None
b) 1
c) 10
d) 11
The answer given is c with the explanation that even though the tmp variable is out of scope in line 6, the local variable still has a reference to the last String created.
I've read this about a hundred times and still don't get it. I thought tmp would be out of scope by line 6 as its declared within the for loop, thereby meaning all the Strings created in the for loop (11) would be eligible for garbage collection. If anyone can explain I'd be much appreciated. Also, does anyone know where theres a really solid explanation of the garbage collection process. Every question I see on it seems to rely on the use of words like 'should' as opposed to 'must' with regard to when its activated.
Cheers,
Rob.
[This message has been edited by rob mcfarland (edited October 05, 2000).]