As long as you do not violate the requirements. Read specs again and verify your plans. I'm convinced that Sun is using automated tool that uses Data.java as a starting point. You can use more creative solution in addition with Data.java, but your solution must follow the assignment.
Original task is carefully planned to make any sensible developer mad - they have succeeded well. String array is just one example. Same goes for locking.
I've chosen to use a general class for implementing db record behaviour in my 'backend' code. On top of this I have created URLYBIRD db record which has its own distinct set of features. For me Data.java is acting as a bridge between the specs and my own internal representation. For me GUI and rmi are both using Sun-format but as soon as backend-code is entered into, format is changed.
Song Jing Lim
Joined: Feb 11, 2003
U means at RMI and GUI, you use string to represent record and only at back end conver it to javabean object and for processing?
I through for difference approach... at RMI and GUI, I use javabean object and only at back end conver back to string for add, edit and delete.
Could be a valid solution, but not the only valid solution. I have made my database server rather generic, so it knows nothing about the actual data it is serving (except field types and lengths, and the number of fields per record, which are stored in metadata for the specific implementation). It takes and yields String arrays, which are converted into data objects clientside.
Joined: Dec 30, 2006
Yep, my solution seems to follow same tracks. I have a db which currently uses 'filestorage' for persisting the data. DB knows nothing about underlying schema. I also have a kind of metadata object for disconnecting physical and logical data layout. After implementing this I got a bit lazy. I think I've proved my point to get the developer title.