Charles Miller

Mark, your point that I am certified is well taken, however, for Sun to grade people on their ability to follow 'standards' - especially in the way code looks, is completely ridiculous. All it takes is one look at the source code that Sun distributes to realize that Sun doesn't have a standard at all.
As for the combo boxes, I don't recall seeing any requirement that the searching functionality use combo boxes. While my choice of presenting a textbox my not have been the most efficient, it was within the scope of the project. If efficiency were of such high importance, the database would not have been a binary flat file and locking would have had timeouts.
And lastly, as was pointed out by another person, right-click menus offer a fast way to select a record in the JTable AND act on it to book / cancel seats. It wasn't a requirement, but as far as GUIs go, right-click behavior is pretty much the standard.
It would be nice if Sun were to be more explicit in sharing how they intend to grade the project and then to provide detailed feedback as to where the deficiencies were. As it is now (though I hear that there is a new developer project out now), it seems rather subjective. Just for my own peace of mind, I'd like to see a project that got 150+ so that I could see what Sun considers top-notch.
This 'rant' is definitely not directed at anyone on JavaRanch - just a public venting of how I feel about the developer certification grading process.

As for my GUI, I stuck with what I considered to be standard parts... I had a static menu at the top, a toolbar beneath that, then the JTable, and finally, a status bar. The JTable had right-click menus.
I deviated from the 'Sun' standards in the following areas (but I documented these deviations in a way that I felt would be acceptable)...
1. Line length - not all of my code lines were less than 80 characters. Justified by the use of larger monitors and IDEs that allow for viewing longer lines.
2. Variable naming - I prefix all of my data elements with an 'f' indicating a 'field' level element; all of my parameters with a 'p', and all of my local variables with a 'w' for working. This allows me to instantly see the scope of the variable / data elements and helps in debugging.
Not sure why I lost the points that I did. Here is the actual scoring data.
General Considerations (maximum = 58): 44 Documentation (maximum = 20): 20
GUI (maximum = 24): 17
Server (maximum = 53): 51
Sorry about the earlier post (1st one) that states that I didn't lose any points in server - I see here that I actually lost 2 points there.
If you have any insight, or perhaps can share why points are / might be deducted in the listed areas, that would be helpful.
Regardless though, I passed and learned a little bit on the way.

Only got a 132 and I wish that they had provided information as to why points were deducted. Lost all in General and GUI. Got full marks in docs and server.

I also wondered about whether to apply leasing to the locks (ie, have them timeout) to handle the potential client crash. However, I did not implement that in my code because the instructions on the lock() method indicate that there is no timeout and that the call blocks until it can achieve the lock. I figure it is better to follow the directions and make a note of the issue in the design doc than it is to not follow the directions.

I prefer the 'localhost' way since it avoids 2 method calls (thereby improving performance), though either way gets the job done.

For the server when you are binding the object, you can specify 'localhost', you don't have to use the machine name or an IP.
When the client needs to make the remote connection, you will either need to specify the machine name (NOT localhost) or the IP of the server machine.
IE. when I start my server, I use 'localhost' in the URL string to bind the remote object.
When I start the client, I specify 192.168.1.210 as the server machine (since I use a local network).

I think that you will need to give us some more information before we can point you in the right direction. The only thing that I can safely say is that something was null that shouldn't have been. Have you debugged the application to see what line fails?

I've been working on mine since mid-February but since I have a full-time job, a family, and other interests, I can only put in about 10-20 hours a week on average. How soon you get done will greatly depend on how much dedicated time you can devote to the assignment and also how much time you have to spend researching any part of the project that you don't have a ready answer for.

Just specify this for the URL...
rmi://localhost:XXXX/RemoteDataImpl
where XXXX is the port number that you want to use
and RemoteDataImpl is changed to whatever you want to register as the RMI name.

I am also providing a server with a GUI. It is not required based on the instructions, but I like the idea of a controlled server shutdown and the GUI is a nice way to do it.

My design allows the user to select the mode from inside the application (GUI). There are NO command line parameters for starting the GUI (other than some -D parameters for the java executable).
Once the user is in the GUI, he must open a connection. If a 'Local' connection is chosen, the user is allowed to browse (FileChooser) for the database file. If the user chooses a 'Remote' connection, a dialog gathers the RMI host and port and connects that way.
To accomplish that, the GUI relies on a DataBroker (interface) and a DataBrokerFactory (which provides either a LocalDataBroker or RemoteDataBroker).

That's a valid point and, as you have probably figured out, the instructions don't cover that. For my submission, I made note of that in the user documentation... that if a connection to a particular database is in local mode, that no other connections should be made to that database (local or remote). Hopefully my solution is sufficient.

I allow filtering on any combination of the field names. My filter dialog gets a list of the valid field names and creates a dialog (grid) with the names of the fields on the left and an entry field on the right. On exit, a collection is created that has the field names as keys and the filtering criteria as the value (only fields with data entered are included). A helper method converts the collection to a string and passes that to the criteriaFind() method.

I'm not sure what the policy is on the Architect parts, but I distinctly remember a non-dislcosure statement in the Java Programmer Test and I'm pretty sure that there is one for the developer project as well (though I can't put my hands on it right now). Regardless, if the answers to the projects are discussed openly in the forums (ie, taken directly from the actual project) then the certification itself will begin to be diluted and will have less and less meaning in the market. Frankly, I'd rather not see that happen. Right now, those certifications mean that the holder actually knows the material. If the answers to the projects are just handed out in forums, having a certification will basically mean that the holder knows how to surf the web and copy answers... then those of us who have legitimately earned our certificate will be facing employers who will no lenger respect it.
I'm all for sharing knowledge, but there is a difference in sharing knowledge and sharing answers. I've been looking through the developer cert forums and the questions there (for the most part) are generic questions. Those that are specific are often answered with a generic answer or not answered at all.
And finally, there are plenty of free resources on the internet for getting the information that is needed. I studied for and passed my Programmer test using free internet info and 1 book that was less that $40. That same book covers the Developer cert as well and I have invested nothing further to get that one finished (submitting in a day or so as soon as I finish the docs). The certs can be earned without spending money for professional classes or attending Java One. All it takes is some initiative and some hard work.

I created a subclass of AbstractAction and used that as a base class for all the actions that appeared on toolbars and menus (buttons were handled in-line). The base class holds all the convenience methods for setting / getting the various attributes. Each concrete class set the various instance specific data such as name, icon, description, etc. So far, that's pretty simple, but... I also added the ability to add multiple listeners to each concrete action class.
In my mind, this allows for Action reuse and it separates the behavior from the appearance. Actions can be defined with a set appearance and then reused in many different places in an application AND in other completely different applications. Yes, this is a little beyond the simple scope of the project, however, I work full time as an application architect and in my mind, reuse is one of the least-realized benefits of OO development and one of the items that I really stress to developers that I work with.
I added an action factory that retrieves the proper action based on a simple naming convention. It caches the Actions that it creates so that when the application asks the factory for a specific action, it always gets the same one.