How does software update work?

Question

Ive been reading Liang's Introduction to Java Programming for a couple of weeks, and that question came up when the author said "There is no need for developers to create, and for users to install, major new software versions.".

How does software update work? For example, patches for games, new version of products, and that kind of things. In the book, there's an example that, as long as you keep an interface of a class the same, you dont need to do any changes in any of the classes that are dependent on the one you changed. That's fine, but still a little abstract (for example, how do I create an update patch with only that class?).

Im also interested in books on the subject.

Thank you.

Answer 1

Have a look at the book

Practical API Design - Confessions of a Java Framework Architect (Jaroslav Tulach, Apress, 2008)

I think it covers most of the aspects you are asking about.

For the topic on shipping new software versions or updates, have a look at the technology Java Web Start for example.

Shipping an update to a web application could be considered implicit in the face of the users as the changes made on a centralized server¹ are delivered by the web browser itself.

¹ or a set of servers

Answer 2

I think the concept you're trying to understand is using an interface as a type. In a java program, a variable can be declared to have the type of some defined interface. Classes that implement that interface can then be instantiated for variables of the interface type. However, only methods declared on the interface can be used. At compile time, the interface is used for type checking. At runtime however, the bytecode that actually does the work comes from the interface implementor. An example:

public interface foo {
    public void bar();
}

public class A implements foo {
    public void bar() {
        // some code
    }
}

public class Example {
    public static void main(String[] args) {
        foo aFoo = new A();
        aFoo.bar();
    }
}

In the class Example, a variable named aFoo is declared to be of type foo, the interface. A, which implements the foo interface, will contain the code to do the work of method bar(). In the class Example, the variable aFoo gets an instance of the class A, so whatever code is in the bar() method of A will be executed when aFoo.bar() is called even though aFoo is declared to be of type foo.

So, we've established that all the work is done in class A. The two classes and one interface above can each be defined in their own file. All three resulting .class files can be packaged into a jar and shipped to customers as version 1.0 of the program. Sometime later, a bug might be discovered in the implementation of bar() in class A. Once a fix is developed, assuming the changes are all contained inside the bar() method, just the .class file for A needs to be shipped to customers. The updated A.class can be inserted into the program's .jar file (.jar files are just .zip files after all) overwriting the previous, broken version of A.class. When the program is restarted the JVM will load the new implementation of A.bar() and the class Example will get the new behavior.

As with almost everything, more complicated programs can get, well, more complicated. But the principles are the same.