This week's giveaway is in the EJB and other Java EE Technologies forum.
We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Using and accessing variables, constants, and Magic Cookie. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Using and accessing variables, constants, and Magic Cookie." Watch "Using and accessing variables, constants, and Magic Cookie." New topic
Author

Using and accessing variables, constants, and Magic Cookie.

Seid Myadiyev
Ranch Hand

Joined: Jul 02, 2002
Posts: 196
Two questions:
1. There are some variables, which are "constants", to a certain extent, such as:
"start offset" and "number of fields in each record", whose value it is possible to find out only at runtime. But there are also real constants and they are only specified in the specs document and not in the db file, such as: "valid", "deleted", "character encoding";
So my question is about second type of constants: Would it be acceptable to declare them as static constants in the data schema class and reference them as such? Or do I need to obtain their values from the properties file? Example for class constants:
//declare:
public static final int VALID = 00;
public static final int DELETED = 0x8000;
public static final String CHAR_ENCODING = "US-ASCII";

//use:
if(getRecordStatus() == Schema.DELETED) ...

2. How to use Magic Cookie?
Thank you!
Seid
Nathaniel Stoddard
Ranch Hand

Joined: May 29, 2003
Posts: 1258
I think there are several ways to go about it: the MetaData way, and hardcoding everything way. Either way, it appears (in the posts) is just fine for the graders as long as you justify yourself accordingly.
It looks like you have a solid approach.
As for the magic cookie, well that's magic. Mine just sits in my MetaData object. I don't even supply an accessor for it. What does it do? Who knows -- it's magic.


Nathaniel Stodard<br />SCJP, SCJD, SCWCD, SCBCD, SCDJWS, ICAD, ICSD, ICED
Terry Martinson
Ranch Hand

Joined: Oct 18, 2003
Posts: 293
about the magic cookie ----
in some old post I read how you just find out what your magic cookie value is and then hard code it into your class (as mentioned in the prior post).
Then, we you first attempt to read the file, if the magic cookie in the file does not match the one you have hard-coded, it would throw some type of exception.
This makes sure that any file you attempt to read is of the correct format (i.e. has the correct magic cookie value)
That is my 2 cents worth.
TJ


SCJP, SCJD, SCWCD, SCBCD
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
1. As you point out these constants cannot be determined from the database file and therefore it seems reasonable to me that they may be hard-coded. Of course, it makes it more flexible if these constants are stored in something like the suncertify.properties file. I hard-coded these constants. It's a matter of judgment I think. I would have to say it's better to make them configurable, but on the other hand I didn't do it.
2. Again I hard-coded the magic cookie value, but you could make a strong argument for including it as a configurable item in the properties file. As for it's use, I took the position that the DBMain (B&S Contractors) interface should be completely implemented and therefore fully implemented all the methods, even those of no use to the client for this assignment such as create, delete, writeHeader, writeSchema, etc. My routine for writing the database file header makes use of the magic cookie value. My Data class is capable of creating a new database file. Is this necessary? Probably not, but at the time it seemed reasonable to me.
My general advice is to make the simplest decision possible and implement it well. Unfortunately I haven't taken that advice to heart myself, and so have spent a lot of extra time implementing things that in hindsight are probably not needed. It's an interesting aspect of the project that requires the developer to decide what's important and what's not in the absence of any definitive information. You're left with your own judgment and your common sense. Don't be too influenced by other's opinions (including mine, of course), stick to your considered decision and resist equivocation.
-- George


Regards, George
SCJP, SCJD, SCWCD, SCBCD
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Ahh. Terry's post reminds me of why I thought the magic cookie was important enough to be a constant.
Originally posted by Terry Martinson:
Then, we you first attempt to read the file, if the magic cookie in the file does not match the one you have hard-coded, it would throw some type of exception.
This makes sure that any file you attempt to read is of the correct format (i.e. has the correct magic cookie value)

That's what I did. If there was something wrong with the database format I log the problem and throw an exception which is enventually displayed to the user:
"Error reading database file: file.db
The database file is not in the correct format,
it does not contain the required magic cookie value: 515"
Necessary? Probably not, but who knows?
- George
Nathaniel Stoddard
Ranch Hand

Joined: May 29, 2003
Posts: 1258
On the other hand, my specs (URLyBird 1.2.2) doesn't say what the magic cookie actually does. It could be possible that the magic cookie value is not constant. Perhaps it is used to track database files within the system. Who knows ... perhaps just another entry for the choices doc.
Seid Myadiyev
Ranch Hand

Joined: Jul 02, 2002
Posts: 196
George, thanks for the detailed reply.
By hard-coding you and Terry mean reading the cookie from db file at a design phase - displaying its value in console and then declaring a static constant with the same value? Did I understand you correctly?
Thank you!
Seid
Seid Myadiyev
Ranch Hand

Joined: Jul 02, 2002
Posts: 196
Nathaniel, my assignment is also URLyBird Version 1.2.2 and this is what my specs says:
"4 byte numeric, magic cookie value identifies this as a data file"
Do you have the same statement?
Seid
Nathaniel Stoddard
Ranch Hand

Joined: May 29, 2003
Posts: 1258
I suppose so. What does that mean though? Does its presence indicate that its a valid data file, or does it have to be a specific value?
I guess I never came across this issue because I programmed my database package to be able to interface with any database that conformed to the specification. I didn't care what the magic cookie was, other than it was there. As long as the rest of the database format was valid so I could read/write/update records then it was just fine for me.
Seid Myadiyev
Ranch Hand

Joined: Jul 02, 2002
Posts: 196
I am thinking...
Seid Myadiyev
Ranch Hand

Joined: Jul 02, 2002
Posts: 196
Nathaniel, I may be wrong but I guess we need to check against that cookie!
Graders may intentionally try reading "Contractors" db with our code, trying to find out if our program will behave correctly.
My MetaData can be assembled for any db as long as the header reads like it is stated in the specs (just like you mentioned yours does) but I will still require for the cookie value to me modified programmatically since the specs clearly states: "... identifies this as a data file"
"4 byte numeric, magic cookie value identifies this as a data file"
What is your opinion?
Seid
Nathaniel Stoddard
Ranch Hand

Joined: May 29, 2003
Posts: 1258
I'm not sure. I'm also not gonna change anything. I'm sick of this certification. I'm about ready to hop in my car and go hunt down the CertManager developers and hack them into little itsy bitsy tiny pieces.
IMO it sounds like this is just another one of those grey issues that Sun put in there to see how we handle it. Will I lose a few points because of this? Maybe. But only if I can actually UPLOAD MY FRICKIN JAR FILE!!!
(Sorry. I'm still waiting for the help desk to reply to my email.)
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Originally posted by Seid Myadiyev:
By hard-coding you and Terry mean reading the cookie from db file at a design phase - displaying its value in console and then declaring a static constant with the same value? Did I understand you correctly?
Seid

Seid,
You understood me correctly.
Regarding this magic cookie value, my instructions state: "4 byte numeric, magic cookie value. Identifies this as a data file." That got me to thinking, why are they telling me this? That led me to check for this value and assume it is constant and needs to be there. Do I think it has to be checked? I don't know, but given how easy it is to check I do it.
Maybe I'm being rather paranoid about this, but I guess that's just my nature. In thinking about the exception handling I wanted to detect problems at the earliest point so they could be accurately reported to the user. So for instance, I test for the existence of the data file first. If it doesn't exist, I report to the user the path or file name of the database file is incorrect. I then go on to read the file checking for the magic cookie value. If it's not there, then that's an exception and is reported to the user, and so on. The instructions made certain claims about the database file structure. I think the database file that's used to test the application should live up to those claims, and if it doesn't, I detect the variance and report it to the user as a problem. In other words, it seems wrong to me to tell the user "can't read the database file," when in fact, it may be more accurate to say "can't find the database file."
I don't think it's necessarily wrong to omit this kind of checking, and my ideas about error reporting may be a little extreme. I guess this project is an opportunity for me to do things the way I think they should be done rather than the most expedient way. Of course, this whole argument rests on the assumption that because something is mentioned in the instructions that it's important. I think it's perfectly reasonable to read about the magic cookie value and come to the conclusion that it's not necessary to check (or rather not worth the effort). To each his own, but if you think it's relevant remember to mention it in the design choices document.
--George
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Using and accessing variables, constants, and Magic Cookie.
 
Similar Threads
Reading URLyBird data file
NX: UrlyBird data file format question
Code Convention issue
Static Final Variables Query
Magic Cookie checking and deleted flag