A while back we were talking about variables and how "Not all Variables are created equal". However do you know what all variables have in common? They are all TYPES. Mind you being a variable is what they ARE - being a type is what they DO.

And they do it with a vengeance!

Being a variable is not as easy as it looks. To the casual observer it looks like they just sit there and hold some tiny bit of information, like a primitive value or the location that one can find the object that they reference. NOT SO! In fact variables have one of the hardest jobs in JVMLand. It doesn't matter if they are local variables, static variables or fields in an object - they all are assigned the task of being the "enforcer" for some type.

When a variable is created there is a little ceremony called "The Declaration" - something like being dubbed a knight. It is during this event that the variable declares it's eternal allegiance to a particular class or interface, or sometimes to a primitive. And from then on it spends the rest of it's life insuring that every activity that it performs conforms to the rules and regulations as declared in the Classfile Castle of it's liege lord. (Yes! Even interfaces have Classfiles that are built out at the edges of the Heap). Of course those variables that declare themselves to primitives have rules and regulations declared at even a higher level in the Commandments for JVMLand itself!

So what exactly is it that a they DO? Well their job has several aspects. These are divided into three major areas: Customs Inspections, Insuring that the correct Orders are issued from the proper Method Decrees, and Getting information from the Field.

A job well done
First there are the Customs Inspections at initialization. You can be assured that a variable will NOT allow anything but one of it's OWN to use it's services. Each time that a variable takes on a new value it demands to see the passport for the guy that wants in. Then the variable goes to that guy's Classfile and looks in it's Royal Listing. Here is maintained a List of all of the Types and SuperTypes and Interfaces and SuperInterfaces that are allies. The variable also checks all of the Supertypes of the Supertypes etc. If the variables does not find HIS type on this list of allies - then you can expect the variable to call in the Justice Department at compile time. It will NOT get past inspection.

Of course this complete Inspection is necessary so that the variable can rest assured that this guy will be able to do all the things that might be requested of the variable. When a call comes in to perform some method, then the variable knows that this guy will be able to do it, so the variable goes to his Classfile and looks up that method. If the method is marked as one of the Royal Static Decrees, then the variable requests that the method from his own Classfile is used. If the method is not marked static, then variable goes to the method area and hands over the passport for the guy that he is representing and waits while polymorphism is performed.

Polymorphism is sort of a "sorting ceremony" where all of the potential methods meeting the naming requirements that are related to types in the hierarchy of this guy are organized, and the one that is closest in the hierarchy to this guy wins. What a farce! Let me tell you this is ALL politics. It is ALL about keeping the little guy on the heap happy. This way he believes that he has some power or control over his destiny. Sheesh. Variables really HATE polymorphism, but they have to put up with it.

At any rate, in addition to having to figure out which Method decree to use, the variable has to figure out which field value from this guy to use. If the variable goes to his Classsfile and sees that the requested field is Static, then it is fairly straightforward. He just uses the Static field from his Classfile. He may have to run up to his SuperClassfile to find the thing, but it is clear which to use.

However, some of the guys that come to use his service have fields with the EXACT same name as those that variables type has. So they may have more than one field with the same name. Luckily each of these other fields are branded with the type that they were inherited from. These guys like to pretend that they only have ONE version by hiding the other fields with the same name. So if you ask this guy for that field, he will always pretend that you must mean his branded version of the field, but in fact the hidden ones really ARE physically there - inside that object. This requires extra special caution, because of course variables are much too loyal to use anything but the fields branded with their own type. So the variable ALWAYS checks the brand of the field and makes SURE that it is the one that came from HIS type definition.

So you can see that the job of a variable is VERY demanding. It is IMPERITIVE that you assign correct variable to the job to get it done right.

Before selecting the one you decide to use you must understand what is to be expected of this variable, and then select the type that provides all of that functionality. On the other hand if you select a type that has MORE than what you envision using then you can be sure that someone else out there is going to notice that and use that ability incorrectly. Therefore it is best to stick with something that provides what you need and not much more. That is why interfaces are such popular types for variables. They define just a certain set of job responsibilities and not more. NO matter what other type with MORE capabilities lands in that variable - they will be limited to only those things that the type allows.

So choose your variable with care - it MAY fit awfully tight when you actually try to USE it.