Object-Oriented Programming With Java: Using Objects in Java. Now that we understand the basic format of a Java source code file containing, for example, a class with attributes and methods, we're going to take just a little bit more time looking at how we invoke constructors and how those objects might be stored and managed by a Java virtual machine. Objects are going to be created using the new keyword followed by essentially the reference to the constructor. Here's our continued example using Car. We have a reference to a Car, racerX; racerX is not a car, it is a reference to a car, and there is the keyword new and there is a reference to the no-argument constructor for the Car class. Now, creating an object is a multi-step process: First, we have declared a reference that will hold a reference to an instance, at such point is we have one. Here we have Car racerX with just a semicolon. We have the notion of that we're going to have a Car reference and its name will be racerX, but we haven't actually put anything there yet. Now, here's the first of multiple references in this unit to the notion of reference table; there may not be such a thing, just consider this conceptual. As you'll find in one of the readings, the Java Virtual Machine does not mandate anything like this, it's left up in details to the implementer of the JVM, so this is simply a conceptual approach that someone might take to tracking object references and linking them to the information they need. The next step here actually says, ''Okay, new Car constructor, no-argument, go ahead and do that." Now, this is also going to be a multi-step process one of which is going to be making sure the Car class is loaded in memory if we've never talked about it before, another thing that'll be important is allocating the storage. Do I have room? Make sure I have storage for this. Then after we have allocated the storage and initialized it all the zeros, and then we can talk about calling the constructor to set it up the way that we actually want it. New will be responsible for going through the process under the covers with the VM of allocating memory, which will be initialized, and then we'll invoke on with the Car constructor giving it a reference to that newly allocated location. This is sort of like what we talked about with a couple of our pictures before. Here is the idea of having a class and from the class when we say new on that particular thing, we'll get an instance, and if we do it again, we'll get another instance. We also looked at the idea here of having a reference to an array, and when we said new to get the string array, we had an array and each element in that is also a reference, and then when we put an actual string into the array, well, each one it's really just a reference so we're pointing at a string object. Then we talked about how even inside the string object, was a pointer to essentially an allocated array of characters to actually hold the character data. What happens when we construct an object? Well, first, every object of the same type, and we just looked at the diagram, for example, with a name and the ID, every object of that class gets its own storage which is sufficient to hold all of its data, all of its attributes, all of its primitive. Remember data is only stored in primitives in Java, you just have to remember that object reference is one of those primitive types. So data is only stored in primitives in Java. All objects of the same type, and here we're saying point to the same set of methods. In other words, every instance, every object knows its class, and its class may be where we get the link to the references or as they'll show you in this particular diagram, maybe we skip the double indirect and go directly to a block. Again, those are aspects where the JVM implementers have latitude, there is no mandated way in which this must be done. The JRE consists of the Java Virtual Machine and the libraries. Within the JVM, we're supposing there might be a data structure that we're calling a reference table that some hypothetical implementation of the JVM might be using to keep track of the objects. In this approach, when a constructor for a class is called, we're looking to see if the class has already been loaded into memory, the class itself, not even any instances. If not, the class will undergo a loading process. Part of that class loading process, we've set up the block of memory to hold the class, and that's going to be shared for all the instances. Next, let's go and try to allocate storage for this instance of the class, and for our example, we'll store both of those memory blocks in a reference table along with the address of the object itself. The next time we need to create an instance, well, we've already loaded the class, so all that we need to do is set up the new record in the reference table for the new instance. That might look something like this. The first time we create a Car, we'll have to go ahead and load the Car class; part of doing that will be loading up its code into what we're referring to here as this method block. The first car that we've set up, there we go, there's racerX, the attribute block is pointing to racerX's own storage, that's it as an instance and then the method block is pointing here at the code block. Essentially, think of that as the class. Here's racerZ, well, we've already created, the method block that's shared, so now we just need another instance for racerZ and down here, racerA, and again, all three of them are using the same method block, what's different is they each have their own instance blocks, their own data. The class itself is shared, but the instances all have their own storage for the attributes. Likewise for planes and trucks, were just not looking at all that data, it would be similar to the car example that we've given here.
