- JOI Exercise 4-17 (Directory). You will find the stub program at
www.cs.umb.edu/joi/latest-joi-cd/joi/4/textfiles/Directory.java.
You'll also need the
TextFile class compiled from
www.cs.umb.edu/joi/latest-joi-cd/joi/4/textfiles/TextFile.java
but you won't need that source code.
To save you some tinkering with the body of the loop you will be
writing in main, here's a hint. For a
TextFile object tf , the String
you want to print is
tf.getOwner() + '\t' + tf.getSize() + '\t' + tf.getModDate()
From: Ethan Bolker
To: eb@cs.umb.edu
Subject: HW6 EX4-17
Date: Wed, 24 Mar 2004 19:30:09 -0500 (EST)
No. You can't change the API. The Directory object must not print
anything - only clients can do that (or main, for unit testing).
> From: a classmate
> To: eb@cs.umb.edu
> Subject: HW6 EX4-17
> Date: Wed, 24 Mar 2004 17:22:45 -0500
>
> Can I make getFileNames method as a void method ?
> e.g.
> public void getFileNames()
> {
...
> System.out.println(tf.getOwner() + '\t' + tf.getSize() + '\t' +
> tf.getModDate() + '\t' + word);
> }
> so , when i put dir.getFileNames(); in main method will have the output
>
- JOI Exercise 4-22 (LittleBank). You might want to start with
a solution (yours or ours) to Exercise 4-21 to modify. Your little
bank should allow a customer to close an account.
While opening an account if the name provided by the client is
already present as account name in the Bank then what should happen?
Clearly that wouldn't be allowed in a real bank. There are two
possibilities here
1. Check, and print the message
Sorry, account name is already in use.
2. Let it replace the old one.
The argument for number 2 is that we have been leaving out all error
checking, which I've promised to take up when we get to Chapter 7.
But I think you should do number 1 for this homework.
- Closing an account. Explain (in your memo) why JOI Exercise 4-25
is easier for a
little bank that identifies accounts by name than for a big bank that
identifies them by number.
> From: a classmate
> To: eb@cs.umb.edu
> Subject: RE: hw6
> Date: Tue, 23 Mar 2004 18:41:44 +0000
>
> hello Prof. Bolker,
>
> when I am tring to close the account, I got the following message which I
> don't understand.
>
> banker command: c
> account name: hao
> Customer transactions: deposit, withdraw, transfer, balance, quit,close,
> help.
>
> transaction: c
> java.util.ConcurrentModificationException
> at java.util.TreeMap$EntryIterator.nextEntry(TreeMap.java:1026)
> at java.util.TreeMap$KeyIterator.next(TreeMap.java:1051)
> at Bank.close(Bank.java:139)
> at Bank.processTransactionsForAccount(Bank.java:199)
> at Bank.visit(Bank.java:93)
> at Bank.main(Bank.java:378)
> Exception in thread "main"
Java will not (usually) let you remove something from a Collection in
the middle of an iteration. That's probably what's happened here.
One solution is to find a design that iterates just to find the key you
need. Then after the iteration is over you can remove the BankAccount.
Another is to try to send the remove() message to the Iterator object
instead of to the TreeMap. (You can find out about this strategy if
you hunt around in the JavaDoc for Collection and Map.)
- JOI Exercise 4-23. The explanation goes in your memo, of course.
From: Ethan Bolker
To: class
CC: william.campbell@umb.edu
Subject: JOI exercise 4-23
Date: Tue, 23 Mar 2004 20:15:17 -0500 (EST)
Changing public to private as required will have no effect at all
unless you recompile BankAccount at the same time.
That was not our intent when we wrote the exercise. I didn't realize
that Java worked this way until a student pointed it out. It surprises
me, and does not please me. I might discuss this in class.
-
Optional.
JOI Exercise 4-28 (Transaction history). If you do this problem
be sure to discuss it in your memo so we grade it.
Your bank will need a new customer transaction, "history". You can
choose the format for the history that the Bank prints for the
customer.
If you do this exercise, be sure to submit your BankAccount class
along with your Bank - since your Bank will not compile with our
BankAccount class.
From: Ethan Bolker
To: eb@cs.umb.edu
Subject: hw6
Date: Sat, 13 Mar 2004 21:42:27 -0500 (EST)
Yes you should submit a Transaction class too. You can consider making
it an inner class in BankAccount, like the SimpleObject class in
ArrayListDemo.
> From: a classmate
> To: eb@cs.umb.edu
> Subject: hw6
> Date: Sat, 13 Mar 2004 11:01:31 -0800 (PST)
>
> hello Prof. Bolker,
> I have got a question about the optional part. I went through the
> exercise in JOI and there it's written that we need to design a
> Transaction class to store Transaction instances. So do we need to
> submit our Transaction.java file also. It's mentioned in the
> homework page that we need to submit only the updated
> BankAccount.java program for the optional part.