Matt Sheehan.

Ranch Hand
+ Follow
since Oct 08, 2004
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Matt Sheehan.

Originally posted by peter wooster:
There have been a few people who have passed using the "thin" solution, I haven't seen thier choices document, but I suspect it was well written.

I really doubt this is part of the grading criteria. I used the "thin" solution and easily passed with this brief explanation in my choices doc:

The locking was hidden from the clients because it makes the application simpler and thus easier to understand for a junior programmer.

Hi Koen,
I used checkstyle, too. Unfortunately I made the mistake of waiting until I was almost done with the project. The first time I ran it I had 1500 errors! I wrote some code to traverse the directories and fix simple problems like trailing spaces and tabs. But some of the checks I thought were unnecessary so I commented them out. You'll see at the top of sun_checks.xml it says:

Checkstyle configuration that checks the sun coding conventions from:

- the Java Language Specification at

- the Sun Code Conventions at

- the Javadoc guidelines at

- the JDK Api documentation

- some best practices

The modules I commented out were:

<module name="PackageHtml"/>
<module name="Header">
<module name="RegexpHeader"/>
<module name="AvoidStarImport"/>
<module name="HiddenField"/>
<module name="MagicNumber"/>
<module name="DesignForExtension"/>
<module name="HideUtilityClassConstructor"/>
<module name="FinalParameters"/>

I figured these fell under the 'best practices' and probably weren't required. But I didn't look into too much because by this time I was tired of working on the assignment.

Hi Daniel,
I think its best to simply compare the two String arrays without thinking about which field is what. Like in this method:

You could use something like this in your findRecords method. A criteria example for name and location would be {"name", "location", null, null, null, null}. Then if you later decide you want to add search functionality for other fields, you won't have to change this code.

Originally posted by Walter Tang:
Hi Peter,
Thanks for your reply.

Yeah, I agree with you. We have to make sure one client get/modify/update a record at a time. Thus, we need to lock and then unlock that record.

However, as Koen already pointed out, if we synchronize the Data object, which is the class manipulating database file, we do not need to worry about lock and unlock at all. In this case, only one client can use the Data object to manupulate database file at a time.

Therefore, either we can synchronize at level or syncrhonize the record, the effect is the same --- only one thread can access data file at a time.

Not implementing lock and unlock, surely, will result in auto failure. I am not conveincing others to not implements these two. Just because I am sort of confused on this, never mind.

Peter and Frans are right. There is a clear explanation of this near the end of this thread in part of which Andrew says:

The logical record locking and having thread safe access to the data file serve two totally different purposes.

[ January 04, 2005: Message edited by: Matt Sheehan. ]

Originally posted by Dieskun Koper:
Hi Peter & Stephen,

My instructions said:

When you submit your assignment, each part (client and server) must be executable using a command of this exact form:

java -jar <path_and_filename> [<mode>]

Your programs must not require use of command line arguments other than the single mode flag, which must be supported.

Note that it says "programs", not "ONE program". In Charlie's case, each part (client.jar and server.jar) is executable using the command above (that is, java -jar client.jar [<mode>] and java -jar server.jar). If his instructions are like mine, I don't see what requirement he broke.


The spec also says:

The mode flag must be either "server", indicating the server program must run, "alone", indicating standalone mode, or left out entirely, in which case the network client and gui must run.

which definitely implies the use of one jar as well as this item from Packaging of Submissions:

The executable JAR containing the programs. This must be called runme.jar.

You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server.

My doc says the same thing, but I did what Andy did and passed without being penalized for it.

Writing past the file extends the length of the file. Therefore, if you append a new record, it is considered part of the file and can be read without an Exception.
Actually, you can write past the end of the file without problems. From the API:

A random access file behaves like a large array of bytes stored in the file system....Output operations that write past the current end of the implied array cause the array to be extended.

My implementation would seek to a record and write whether or not it was reused or new. If you try to read past the end of the file, though, you will get an Exception.

HTH, Matt

Originally posted by Daniel Simpson:

Now you got me wondering....can someone who has passed the exam please help me with this? Should we assume that the server and client are on the same machine? For instance, say I configure the server when the server launches and it persists the data to the file. If the server and client were on different machines, how would the client know what ip address and port to connect to? This has me absolutely baffled. Someone who has passed the assignment, your help is greatly appreciated and welcomed! Thanks!

  • Server mode - prompt for local db file location and port number
  • Network client mode - prompt for IP address and port number
  • Standalone client mode - prompt for local db file location

  • The persistence is used so that when you run in one of these modes, your last choices from the SAME mode will be present as default choices. Also it is assumed that the client-user will know the port and ip the server is running on.

    HTH, Matt

    Originally posted by Koen Serneels:

    What you are saying is basicly that the cwd is only defined at runtime. When packaging the assignment we cannot possibly know what the cwd is going to be. This comes down to the fact that we must assume that no property file is present and create one first if it isn't.

    So when you launch the gui you load the configuration. The configuration system will first check if there is a property file in the cwd. If there is none, it will create an empty one and popup the configuration panel automatically asking to define the configuration parameters. Upon exit this information is saved to the property file in the cwd.

    When there was a property file present in the cwd, the application starts silently and the configuration information is visible/changeable when the configuration panel is opened on request from the file menu.


    Originally posted by Koen Serneels:

    So the fundamental question is, is the assignment automatically failed when we supply an extra file the root ? (note that the file is not really required, when they delete it it will still work. It is just for convinience when they do start from the assignment root as cwd)

    I would guess not. In my implementation, though, I just hard-coded default values to these fields.

    Originally posted by Koen Serneels:

    Ok, so basicly they mean that you put the properties file in the same directory as the jar file ? Which is in this case the root of the assignment...
    When someone takes out the jar file and places it somewhere else (lets say c:\temp) they als have to copy the properties file beside it.

    Well, if you have a path "dir1/dir2/dir3/", where runme.jar resides in dir3, and you call "java -jar dir2/dir3/runme.jar" from dir1 the CWD is dir1. If you call "java -jar dir3/runme.jar" from dir2 the CWD is dir2.

    To quote this website:

    When a program runs under the UNIX or the Windows NT operating system there is a directory where the program is started. This directory is not necessarily the directory where the executable code is or where the basic program is. Sloppy saying: this is the directory where the user prompt was when the user typed in the command line starting the program. This is called the current working directory.

    Originally posted by Vince Cheung:

    I have a doubt which is "a file called". What's the meaning of "suncertify"? Is "suncertify" a directory or others?

    In this case "suncertify" is the filename and "properties" is the file extension.

    Originally posted by Vince Cheung:

    But Mike says "Current working directory is just where your runme.jar is."
    I can't understand.

    Peter's answer is the correct one. Whatever directory you are in when you call "java -jar <path/>runme.jar <flag>" is your current working directory.
    Hi Leo,
    You may want to cast the cause-Throwable to an IOException before you rethrow it. Then you can catch it normaly in the client layer.

    Originally posted by Daniel Simpson:

    Hey Matt, I'm not sure what assignment version you are using, but if I were to use the code example above, I would be violating an explicit must. My doc says that any exception created by us must have a default contstructor and another constructor that takes a string representing the error.

    Quite right. I omitted those contructors from my earlier post. I actually provided four constructors for each Exception. The two you mentioned and also the other two from the Throwable class. The instructions do require the first two, but they don't forbid the others. Also my instructions (seem to) explicitly single out the Exceptions that are declared in the required interface for those requirements.