a) The file is valid. You've just used the maximum length of the field by padding with spaces and I should do the same. i.e. You are are trying to simulate typical semi-clueless customers, who says one thing but actually means something else.
b) The wrong file has been distributed for this assignment (either by mistake or deliberately) and I just have to document the fact and deal with it.
c) I should realise there is a problem with the file and negotiate a spec change with you.
d) The file and spec are perfectly correct and I should be able to deal with records padded with whitespace, but when I write records I should always write null terminated Strings.
Note that I think (d) was also pretty true, up to the point where you said "when I write records I should always write null terminated Strings." I still think you should be able to deal with null terminated strings (if some other program writes them) but your own program should write space-padded strings for easier compatibility with the existing file. But this option wasn't asked about, so (a) is closest.
I currently pad field values with nulls, according to the specs, but as I don't trim() field values before writing them, I implicitly accept that a Data client stores values padded with spaces. So am I worry with that [a] answer from Sun. And I wonder if I shouldn't add some padWithSpaces boolean property to Data to explicitly support both ways of padding. After all, it's also a good way too handle those typical semi-clueless customers ... Regards, Phil.
Hi Philippe, I like your idea of having both, with some option to define which mode is being used. If this were real life, I would consider having an option in the properties file. I would document the fact that there was ambiguity and my chosen method of handling that, along with a comment saying that if the user did intend the alternate, they could manually edit the properties file. I know - we cannot force the examiner to edit the files. But in this case they dont have to They would only have to if they wanted to change to the null terminated processing. But back to the assignment: I think it may be easier to just convert your code to handle spaces and ignore nulls. Otherwise you may end up writing additional code (for example: if they choose to really use nulls, does that mean that you have to consider the spaces that are already there as part of the values?) You may end up doubling your code just to handle both cases consistently. Regards, Andrew
Hi All I also padded with nulls after the last coversation, but now I intend to follow the advice given by SUN and pad with whitespace. I asked for advice and was given it, so it seems sensible to follow it. Also, my code will be easier for a "junior programmer" to understand (as requested in the spec). HTH Gareth.
Philippe Maquet
Bartender
Joined: Jun 02, 2003
Posts: 1872
posted
0
Hi Andrew, My instructions say that "all configuration must be done via a GUI", so I would handle that property through a GUI.
I think it may be easier to just convert your code to handle spaces and ignore nulls. Otherwise you may end up writing additional code (for example: if they choose to really use nulls, does that mean that you have to consider the spaces that are already there as part of the values?) You may end up doubling your code just to handle both cases consistently.
If they change their mind and want the whole file to be consistent, they should write some conversion program which would trim() all existing values. I don't think that Data itself should enforce that consistency. Cheers, Phil.
Hi Gareth, I think all ideas are correct. I beleive padding it with spaces , but been able to decode null-string is the safest way. It is strage, but I beleived that the goal of the assignement is to check our skills in Java, but not playing "Try to understand what we mean" game with Sun... Vlad
In real world it's quite possible that You would never get sample db file, sou You would never discover what's the content of the file.
What's most important ? To adhere to project specification. I do not care that Strings are padded with spaces, that's up to client what data is stored. All I care is db specification. So i check if '\0' character exist \in this String (that's null char according to java.lang.Character javadoc', if it exist I substring accordingly.
When writing to file, String is build in byte [] table, since 0 is default value i do not need to care about terminating String.
One more thing about trim(), please keep in mind that it also removes spaces from the beginning of the string... You can argument this by "What's the sense of keeping spaces at the beginning or end?" ... well it's up to client what data is stored.
It's up to You how it'll be implemented, You must have arguments why it's implemented in specific way [ September 15, 2008: Message edited by: Sebastian ]
Andrew Monkhouse
author and jackaroo
Marshal Commander
0
They would only have to if they wanted to change to the null terminated processing.
