More fun with Application Packages – Instances

In my last post I had made this statement:

Instance variables are like Static variables in Java.

Hat tip to Helena who provided insight:

One comment though – instance variables are not static variables (in terms of scoping rules, one the same private instance variable is not shared by multiple instances of the class); they are in fact instantiated for each instance/object of the class.

So if I have a class definition ClassDef, with 1 private instance variable &InstanceVar, and I instantiate 2 objects of type ClassDef, I will have 2 instances of &InstanceVar in memory, not just 1.

This contrasts with static member variables in Java, where the variable is shared and in the example above, only 1 instance of &InstanceVar would have been allocated in memory.

Good point – so lets dig into this a bit – as others have here and here.

Since I made the statement like Static variables in Java let’s look at what those are.  From Oracle’s Java Tutorials on Understanding Instance and Class Members:

When a number of objects are created from the same class blueprint, they each have their own distinct copies of instance variables. In the case of the Bicycle class, the instance variables are cadence, gear, and speed. Each Bicycle object has its own values for these variables, stored in different memory locations.

Sometimes, you want to have variables that are common to all objects. This is accomplished with the static modifier. Fields that have the static modifier in their declaration are called static fields or class variables. They are associated with the class, rather than with any object. Every instance of the class shares a class variable, which is in one fixed location in memory. Any object can change the value of a class variable, but class variables can also be manipulated without creating an instance of the class.

I added the bolding and underlining in the above.  So as Helena pointed out, in Java the same memory location is used by every instance of the class having a variable defined as static.  Each instance of a class gets a reference (having been weaned with C I would say pointer but a Java purist would start throwing acorns at me) to the location in memory where the value actually resides.  Which falls in line with how memory allocation works in Java.  Java stores objects on the heap, variables sit on the stack.  But variables are ‘merely’ pointers/references to the objects sitting on the stack.  Enough teasing – I also know there are differences between a pointer and a reference – but that is a C++ convention, not C.  In any event, it’s efficient for Java to have Static variables work this way.

PeopleBooks provides this tidbit in Declaring Private Instance Variables:

A private instance variable is private to the class, not just to the object instance. For example, consider a linked-list class where one instance needs to update the pointer in another instance. Another example is the following class declaration:

class Example private instance number &Num; end-class;

A method of Example could reference another instance of the Example &Num instance variable as:

&X = &SomeOtherExample.Num;

Avoid making every instance-scoped variable a public property. You should consider each variable individually and decide if it belongs in the public interface or not. If it does, decide if the variable warrants get or set modifiers and therefore should be a public property. If the variable only serves internal purposes to the class, it should be declared as a private instance variable.

Again, I added bolding and underline.  But note the word pointer – a double plus unJava word.  So lets look at a language that does use pointers.

I’m a pack rat.  I don’t throw books away.  So I looked in my collection and grabbed my copy of Deitel & Deitel C++ How To Program:

Each object of a class has its own copy of all the data members in the class.  In certain cases only one copy of a variable should be shared by all objects of a class…  A static class variable represents “class-wide” information. 

Let us motivate the need for static class-wide data with a video game example.  Suppose we have a video game with Martians and other space creatures.  Each Martian needs to be brave and willing to attack other space creatures when the Martian is aware that there are at least 5 Martians present.  If there are fewer than 5 Martians present, each Martian becomes cowardly.  So each Martian needs to know the martianCount.  We could endow class Martian with martianCount as a data member.  If we do this, then every Martian will have a separate copy of the data member and every time we create a new Martian we will have to update the data member martianCount in every Martian.  This wastes space with the redundant copies and wastes time in updating the separate copies.  Instead, we declare martianCount to be static.  This makes martianCount class-wide data.  Every Martian can see the martianCount as if it were a data member of the Martian, but only one copy of the static martianCount is maintained by C++  This saves space.  We save time by having the Martian constructor increment the static martianCount.  Because there is only one copy, we do not have to increment separate copies of martianCount for each Martian object.

Hmmm.  Something fishy here.  Both C++ and Java are using static variables the same way.  Let’s look at PeopleSoft some more.  There is some code here that bolsters what Helena had pointed out.  The instance in an App Package class gets instantiated as its own distinct block of memory – so it breaks the notion and value of having a C++/Java type static variable.  However it’s able to be referenced and changed by another instance of the same class.   So take the less efficient part of the Deitel explanation and there you have it.

To my mind this is bordering on an architectural bad smell of connector-envy, and can lead to some code smells on the part of development.

About these ads

About Lee Greffin
Just another programmer...

5 Responses to More fun with Application Packages – Instances

  1. Jim Marion says:

    Interesting post. The part that I find especially interesting is the private instance variable text from PeopleBooks. I don’t like the idea that two separate instances of an app class can update private members of “siblings.” I suppose if you define the language, you can interpret meaning. Perhaps their is a use case for this “feature”? I’m not sure I buy the LinkedList reason.

    Now comparing this to statics… I think this is where there is some confusion. With a static each instance gets a pointer (reference ;)) to the single variable owned by the class definition. All instances point to the same memory block. PeopleCode does not have this static notion. Each instance gets its own address. According to PeopleBooks, one instance can access the private values of another instance. This is very different from statics because it means that each instance has its own heap/stack/address.

    I am going to test that private instance access “feature.”

    • Lee Greffin says:

      Hmm. Your discussion of memory is bringing more to bear than I originally thought about when I wrote this.

      I had figured PeopleCode was following more along the Java model – but this almost sounds closer to the the C++ idea of a reference vs. a pointer.

      Pointers and references are different beasties – one reason Java branded pointers as evil is they are a very good reason a C/C++ program blows up – so Java only permits references. Once initialized a reference can’t be re-pointed – using pointer arithmetic – keeping them safe. AND can’t be re-cast so they are type safe.

      And only having references allows the JVM to take care of garbage handling – something that has to be taken care of by the developer in C/C++.

      I’m going to guess here – PCode specification followed the already existing model from Java. Which does make a lot of sense.

      I’d be interested in the results of your tests!

      • Jim Marion says:

        Yes, tested. Two private instances can in fact update each other. They are completely different references so each has its own version, but they are accessible. So I think the key here is visibility rather than memory: private instance members are visible (read and write) to siblings, but share absolutely nothing (like statics). Here is my test case: http://jjmpsj.blogspot.com/2014/07/private-app-class-members.html

        In regards to pointer versus reference, I have no idea and I’m not sure PeopleBooks wants to give us that much detail. I think the point is that the two instances don’t share anything but reference, point, etc to their own versions.

  2. Qian says:

    I believe PeopleSoft instance variable is the opposite of Java static.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: