Josh Olson's Blog

Static Methods
The keyword static lets a method run without any instance of the class. A static method’s behavior is not dependent on an instance variable, so no instance / object is required. Static methods cannot use non-static (instance) variables, nor can they use non-static methods. Non-static method behavior relies on instance variables, which rely on an instantiated object. Even if a non-static method does not use any instance variables, you still cannot invoke it from within a static method. Think about what might happen if in the future you changed the non-static method to use an instance variable, or if the non-static method was overridden by a sub-class.

If you try to use a non-static method or variable from within a static method, you will receive one of the following errors at compile time.

• non-static variable n cannot be referenced from a static context
• non-static method nMethod() cannot be referenced from a static context

Static Variables
Static variables are variables whose value is shared by all instances of a class. Think of it as one value per class, not one value per instance. Static variables in a class are initialized before any object of that class can be created, and before any static method of the class runs. Static variables are instantiated once (and only once) when the class is loaded. The class is loaded when the JVM sees fit, you can tell the JVM when to load the class, but there is only a few instances where this might be desirable (I have not yet learned about them.) Typically the JVM loads a class because somebody is trying to make a new instance of a class, or use a static method or variable of the class.

When you call an operation on a static method or variable, you use the class name, not a reference. It is legal to call a static method using a reference variable, but the compiler just uses the reference to determine class type, and invokes the appropriate method without knowledge of the referenced object. This makes for less readable code. You can prevent a class from being instantiated by marking the constructor private.

Static Final Variables
Static final variables are constants. Declaring a variable as final means that once it is instantiated, the value cannot change. In the case of a static final variable, once the class is loaded, the variable is instantiated, value is assigned (implicitly to a default value if not explicitly), and is constant. There is no way to declare a variable as a constant, but there is a naming convention you can follow. Constant variables should be declared in all capital letters.

public static final int SECRETN = 7;

When you create a new object, the constructor is called first. One of the very first things the constructor does is call super() (the object’s super-class’s constructor). Then from there, if that super-class isn’t class Object, it follows up the tree until it reached class Object. When that’s done, Object’s constructor stack frame is popped off, and it goes down to Object’s current sub-class. That constructor executes, and gets its stack frame popped off the stack, and follows down all the way down to the final, concrete, sub-class. Now we have an object that holds all of its super-classes in it, and has space for all of the instance variables those objects may contain.

You can call this(); (with arguments, too) from an overloaded constructor to another overloaded constructor that contains the “common” initialization code, which then calls super(); But the call to super(); must be the first statement in the destination constructor (this is true for both this(); and super();)

Also, super(); is implicitly declared in any constructor that doesn’t use this();, you can choose to put it in there, but it better be first. Always remember, before any code can execute within the object, the superclass must first be constructed.

This is valid:

class Dog {
public Dog(int i, String pupName) {
// Note there's no return type allowed in constructors!
this(pupName, i);
}
public Dog() {
// Different argument list (none here, actually),
// so it's ok to overload
this("Moose", 3);
}
public Dog(String pupName, int i) {
// same arguments, different order (VALID!)
}
}


Primitives and references are disposed of after the method returns. A variable that is local holds its state until the method is finished executing. It may hold its state and be “alive”, thus residing on the stack until its frame is popped, but it will be out of scope (and not accessible) until its stack frame is at the top of the stack. Then the count-down begins until its frame is popped. An instance variable is stored with its object, and is in scope, and alive for the duration of the object’s life. All objects live on the heap, even ones referred to solely by a local variable. They have the same lifespan of any other object.

Garbage Collection (GC) is neat, as soon as an object has no valid references, it becomes GC bait. Death to ye non-referenced objects.

How do you know when to create a class, sub-class, abstract class, or interface?

• Create a class when your object no longer passes the IS-A test.
• Create a subclass when you would like to add more granularity and or functionality to a more specific type of the class it will extend.
• Create an abstract class (which can contain both abstract, and non-abstract methods) when you would like to create a template for groups of sub-classes, it’s like updating their “contract”.
• Create an interface when you would like multiple different types to be able to have the ability to play a certain role. Keep in mind that any class can implement an interface. This is great for polymorphism because it allows you to have different types from anywhere in multiple inheritance trees playing well together. Just use the interface as a generic return type, parameter, or reference, and anything that implements it will be able to have its methods run on it. This is important because the compiler will only let you run methods that reside in the reference type, it doesn’t matter what the object is. Think of how not-flexible it would be, if you couldn’t use interfaces? You would have to guarantee that every new object write their code to be identical to your design. The whole point of interfaces and super-classes is to establish a code “contract”, that mandates your code will always play well with others. Interfaces are 100% abstract, and all concrete classes that implement them must create a method body for every method.

Extend once (avoid the Double Diamond of Death), implement multiple times. If you want to override a super-class’s method (or methods), but still use their original functionality, use super.methodName() inside your overriddin method’s body.

When creating an array, the array is defined by the type you use during instantiation. An array is always an object, there is no such thing as a primitive array. An array can hold both primitives, and reference variables, but not at the same time. With the exception of implicit widening, e.g. putting a byte into an int, Java mandates that an array can only hold objects of their declared type. A major downfall of an array is that you can not change its size, since Java is pass by value, you can create a copy of a portion or all of the array.

Introduce java.util.ArrayList

An ArrayList is by definition a resizable-array implementation of the List interface. Basically, it allows us to have an adjustable array of a declared type. To create a new ArrayList, you must fist import java.util.ArrayList, another option is to type out the full path to ArrayList (java.util.ArrayList) every time you would like to use it.


import java.util.ArrayList;
class ArrayTest {
public static void main (String[] args) {
ArrayList<String> test = new ArrayList<String>();
test.add("Hello");
test.add("Blaggers");
for (String member : test) {
System.out.println(member);
}
test.remove(1);
for (String member : test) {
System.out.println(member);
}
}
}

By declaring an ArrayList<String>, you’re asking the compiler to guarantee that you only put objects of type into the ArrayList, and by doing so, the compiler can guarantee that any objects removed from the list are of the specified type. The alternative (and I’m not sure how far back you have to go before casting was implemented) would be to create every array (for polymorphism) as a List (because every class extends java.lang.Object in one way or another), and manually cast objects you would like to pull out of it.

Every object pulled from ArrayList (without declaring a type, or any time you use Object (implied here) as a reference type, return type, or parameter type) will be stored in a reference of type Object, even if it’s a dog. You could manually cast it to a dog:


ArrayList listOfObjects = new ArrayList();
Dog foo = new Dog();
listOfObjects.add(foo);
Dog bar = (Dog) listOfObjects.get(0);


But that’s the awesome in the <type> syntax, you’re basically telling
the compiler:

“Hey compiler, make sure I only put objects of type x into this ArrayList, and if I try to trick you, blow up at compile time (instead of run time, a Class Type Casting exception would be bad), oh, and hey, since you’re going to make sure I only add type x, don’t worry about making me manually cast it back to an x when I want to pull an object out if it.”

You can read more about java.util.ArrayList in the Java API. It appears that Wordpress is having troubles displaying the spaces in my code properly. I will attempt to resolve that issue soon.