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.
The locking was hidden from the clients because it makes the application simpler and thus easier to understand for a junior programmer.
Checkstyle configuration that checks the sun coding conventions from:
- the Java Language Specification at
http://java.sun.com/docs/books/jls/second_edition/html/index.html
- the Sun Code Conventions at http://java.sun.com/docs/codeconv/
- the Javadoc guidelines at
http://java.sun.com/j2se/javadoc/writingdoccomments/index.html
- the JDK Api documentation http://java.sun.com/j2se/docs/api/index.html
- some best practices
<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"/>
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 Data.java 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.
The logical record locking and having thread safe access to the data file serve two totally different purposes.
Originally posted by Dieskun Koper:
Hi Peter & Stephen,
My instructions said:
<quote>
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.
</quote>
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.
Regards,
Dies
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.
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.
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.
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 suncertify.properties 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!
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)
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.
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 suncertify.properties". What's the meaning of "suncertify"? Is "suncertify" a directory or others?
Originally posted by Vince Cheung:
But Mike says "Current working directory is just where your runme.jar is."
I can't understand.
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.