Campbell Ritchie

Welcome to the Ranch
Don't worry about not having noticed the errata page.

Good to see you here Welcome

I could have sworn I wrote a reply, but it seems to have valished.

You are starting off well, reading from a database and then creating a List<Client>. That is good. Then you are logging that List, but why have you strayed from the straight and narrow object‑oriented (=OO) path into pulling all the fields out individually? Why aren't you using Client#toString()? Why do you need to log that List at all? You could always write the entire List into a file, but what are you going to do with it afterwards? It is going to be awkward to parse from a String.
I cannot see the point of your having the method to put the List into a single String at all. You will end up with a very long String, which your program will find just as illegible as you will. At least add a line end sequence in your loop, so you will have the different records on different lines. But that String will still be awkward to parse if you ever need to recreate Client objects.
At least your append() call uses the toString() method (indirectly via String#valueOf()), so it is more OO. But are you doing anything you couldn't do faster by calling toString() on your List?

I think I wouldn't write that method at all, but I am not writing the code.

Welcome to the Ranch

I think I would use a Scanner myself; go through that link and you will find out what its default settings are. They are not quite what you have there, but I don't think you will notice the difference. You will find an example which is reasonably similar to what you want to do. I presume you already know how to add elements to your List.

This morning, I wrote:Why are you trying to turn your List into a single String?

That is the problem I have with that method: why is it there at all? The only way I can think of testing it is to predict what sort of String it will return, which is very awkward without reading directly from the database. It is also awkward because the method isn't some sort of function; you cannot pass any sort of input to it and predict its output from that input.

Paul W being the boss of this website is entitled to as many cows as he wants, so ∞ is as good a number as any.

Why have you got a method called printXXX() which doesn't print anything? Why are you trying to turn your List into a single String? Why not simply print the List? Why is your variable name in the for‑each loop listOfClient? That is likely to cause confusion with the List.

Tim Moores wrote:. . . As you said, synchronizing only allows a single thread to run the code . . .

Good point; it might be possible to have different locks for different methods. That is what the read‑write locks are all about.

Al Hobbs wrote:Which version are you using

I presume you meant which version o JCreator not of the JDK.

. . . LE doesn't have a debugger apparently.

Does that mean JCreator Lite?

What makes you think the thinking cap is software?
It is occasionally necessary to drain the Internet, but you do that by unplugging an ethernet cable, not via the keyboard.

Paul Clapham wrote:. . . No, it doesn't. A final class can't be extended . . . .

Another way to put what Paul said is that the final modifier would be applied to the class, not to the fields.

You can apply final to classes, to methods, and to fields, and it means something different in each location.

Paul Clapham wrote:. . . But why would that matter?

Execution speed should probably be the last consideration when designing an app. It is much more important to get the number of classes rright, and any inheritance hierarchy. It might be slightly slower to compile more classes, but that is the least of our worries.

Vaibhav Gargs wrote:. . . "As the name says, ReentrantLock allow threads to enter into lock on a resource more than once. . . . ."

I am just wondering why someone would take the lock more than once?

public class Foo {    private int i;    // constructor, toString, hashCode, equals, etc    public void setI(int i)    {       this.i = i;    }    public int getI()    {       return i;    }    // ... }In that code, although the assignment in line 9 is atomic, you do not know whether a second thread will read the new value or the old value of i. So you use a Lock object to synchronise the two methods. Note that the lock() call doesn't go in a try, but the unlock() call has to be in a finally.public class Foo {    private int i;    private final Lock lock = new ReentrantLock();    // constructor, toString, hashCode, equals, etc    public void setI(int i)    {       lock.lock();       try       {          this.i = i; //       System.out.printf("i set to %d%n", this.getI()); // testing code only       }       finally       {           lock.unlock();       }    }    public int getI()    {       lock.lock();       try       {           return i;       }       finally       {           lock.unlock();       }    }    // ... }That's a very simple and naïve example, but if you are trying to call setI(), and a different thread attempts to use getI(), that second thread cannot acquire the lock on line 24 until after the lock has been released on line 18. The same would happen if a thread executes the getI() method. If you are using beginners' code and un‑comment line 14, the thread executing that code already holds the lock. When it reaches line 24, it can lock the lock again with a count of 2. You should find it easy to work out that, by the time the setI() method completes on line 18, the lock count is back to 0.

. . . we are not calling methods on any object . . .

Yes, you are. The Lock reference points to an instance of the ReentrantLock class, so that is an object. You are not using its intrinsic lock but explicitly counting how often it has been locked.

Is this same thing as synchronized locks?

It is used instead of the keyword synchronized.

Our local fishmonger cleans and fillets fish free after purchase; obviously the cleaning and filleting is included in the price. He also makes some wonderful smoked salmon; I have some in the fridge at the moment