Peer review please

Question

I have a working project (attached), but I'd like any suggestions on how I might do it better.
I have tried to keep to good object-oriented design principles such as 'Single Responsibility' and 'Encapsulation', but I'm always keen to do better.
Thanks
Mark
N.B. Doesn't allow Zip files, so you'll need to rename the attached '.doc' file to '.zip' before unzipping

Answer 1

Hi Mark,
I think I have 3 improvements for you:
1. The time you print,is a calculated time, not the actual time when the printing occurs. I mean: You create a Calendar instance when you start your program, and then add 300000 ms (= 5 minutes in ms precision) every time the loop is executed. If for some reason, there is some delay somewhere, you will not easily notice, because your program prints what it calculated as the current time, which is not necessarily the current time.
What I did in my solution, was creating a new Calendar instance every time I need to print the current time, and then get the time from this instance.
When I made my 1st solution to this homework, using Threads, I used a sleep for 5 minutes, expecting that I would receive a printout every 5 minutes. Running this program for an entire night, I noticed that my printouts showed a few seconds past the 5 minutes. I guess this was caused by the time the statements were using every during every loop. Imagine the error when the program would be running for weeks, or even months. If I would have printed a calculated time, I would probably not have noticed this error.
Bottom line of this improvement: I think it is better to print the contents of the system clock, rather than calculating what you think is the time.
2. When calculating the start time for your 5 minute Timer, yous use only second precision. After that, you use millisecond precision to calculate the next 5 minute time. What you don't take into account is that your startCalendar also has a millisecond field. Ideally, this has the value 0, but in the worst case, it has the value 999, causing your start time to be 1 second too late.
My solution for this homework uses the epoch value of the current time (the milliseconds since midnight of jan 1, 1970) to calculate the start time. You can read this value from a Calendar instance using the method getTimeInMillis().
The algorithm I use:
- Divide the current epoch value by 300000 (= 5 minutes).
- Increase the result by 1, and multiply again with 300000. This gives me the epoch value for the next 5 minute period, with millisecond precision.
- The difference between this calculated epoch, and the current epoch, is the number of milliseconds delay I need to be (almost) exactly at the next multiple of 5 minutes.
- Finally, I use the method scheduleAtFixedRate(task, initialDelay, 300000), whereas you use scheduleAtFixedRate(task, startDate, 300000)
I used the same procedure to calculate the start time of the 30 second intervals during the uneven 5minute periods. I ran this program for more then a day, and it always printed exactly at multiples of 5 minutes or 30 seconds (printing the system clock, not a calculated value :-) )
As a test, I also printed the delay that I calculated at the start of the 30 second task. It appeared that the delay that was calculated, was always around 29960 milliseconds (+/- 10). Therefore, I believe that my printouts are made with a millisecond value close to 0, every time.
Bottom line of this remark: Using epoch to calculate the start time is more accurate than making calculations with minute and second  values.
3. In the method startReading in class Homework1, you trust that you receive the method call at an exact multiple of 5 minutes. If for some reason, the method was received with a delay, all your 30 second printouts will suffer from this delay. If on the other hand you calculate the delay until the next multiple of 30 seconds (same calculation as in point 2, but divide / multiply by 30000 instead of 300000°) then the first 30 second printout will suffer from the delay, but all other printouts will come (almost) at multiples of 30 seconds with millisecond precision. I believe this makes the solution a bit more robust.
Bottom line of this remark: Never trust that you get what you expect, always verify what you get.