What is Open Session in View?

The Java Persistence API (JPA) allows an object oriented model to be mapped to a relational database. JPA is a standard specification for Java based Object Relational Mapping frameworks – in order to use JPA an underlying implementation must be available; the most common choice being Hibernate.

Both JPA an Hibernate support lazy loading of data to restrict the number of queries fired off to the database. In general this means that data will be loaded on demand when methods are called, on a loaded object, that require more data to be loaded. In order for this to work, the object that the method is called on must have been loaded by JPA and be part of the current running transaction.

In a Spring application, calls to demarcate transactions are generally handled by the Spring interceptors.Transactions are normally started when a method call is made on a Spring managed object and committed once that method call ends. This means that if a JSP page requests data by calling a transactional method on a Spring managed bean, then it can only access the data in that bean that has already been loaded within that call. Any calls for data that might be loaded lazily will fail because the object is no longer attached to a JPA transaction after that method call has returned.

Hibernate developers solved this problem using the Open Session in View design, which associates the active session (and hence it’s transaction) with the thread that makes the call. In this design, the transaction will be committed when the thread completed processing the request, rather than when a method call completes. This allows lazily loaded data to be loaded within the JSP page not just within Spring managed objects.

Providing Request Scoped Transactions

A standard way to intercept requests in any Java Web application is to use a web filter. Spring provide an out-of-the-box Web filters that implement the Open Session in View design for both Hibernate and JPA. We will see the JPA version here, but the Hibernate one works in just the same way; just change the class name in the configuration file.

In web.xml:

<filter>
    <filter-name>oemInViewFilter</filter-name>
    <filter-class>
        org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter
    </filter-class>
    <init-param>
        <param-name>entityManagerFactoryBeanName</param-name>
        <param-value>reportsEntityManagerFactory</param-value>
    </init-param>
</filter>

<filter-mapping>
    <filter-name>oemInViewFilter</filter-name>
    <url-pattern>*.jsp</url-pattern>
</filter-mapping>

The filter class is from the Spring framework libraries. The filter mapping, in this example, applies this filter to all URLs ending with ‘.jsp’; this means that all JSPs that retrieve a lazily loaded object form the service tier of the application are now free to read any data members from it – any unloaded data will be loaded from the database when calls are made to access it.

Be aware that the filter turns off the auto-flush behaviour of the standard entity manager. This means that any changes that are made to the data in the JSP will not be persisted. The filter can be configured to flush these if requested.

Finally, the init-param that’s provided to the filter is optional and can be used to explicitly name the entity manager factory that will be used. The example shows how to use an entity manager named ‘reportsEntityManagerFactory’ in the Spring configuration files; the default value for this is ‘entityManagerFactory’.

One common problem faced when unit testing is how to test one object when it is dependant on another object. You could create instances of both the object under test and the dependent object and test them both together, however testing aggregated objects is not what unit testing is about – unit tests should test individual objects for their correct behaviour, not aggregations of objects! Moreover, this approach just won’t work if the dependent object hasn’t even been implemented yet.

A common technique for handling dependencies in unit tests is to provide a surrogate, or “mock” object, for the dependent object instead of a real one. The mock object will implement a simplified version of the real objects methods that return predictable results and can be used for testing purposes.

The drawback of this approach is that in a complex application, you could find yourself creating a lot of mock objects. This is where frameworks like Mockito can save you a lot of time and effort.

A Test Scenario

To demonstrate what you can do with Mockito, we’ll examine how we might test an Account object that is dependant on a data access object (AccountDAO).  The account object can calculate the charges applicable in the current month by using the DAO to count the number of days overdrawn and then performing a simple calculation on the value obtained from that call. The method names on the classes we’ll use are self-explanatory:

To test this thoroughly, we should test two things:

1. that the account obtains the number of overdrawn days by calling the correct method on the DAO,
2. that the account calculates the correct fees based upon the value it gets back from the call.

Testing that the account calls the correct method on the DAO

Using JUnit to run the test case, we could write something like this:

import static org.mockito.Mockito.*;

public class TestAccount {
    @Test
    public void checkAccountCallsDaoMethods() {
        //create the object under test
        Account account = new Account();

        //create a mock DAO
        AccountDAO mockedDao = mock(AccountDAO.class);	

        //associate the mocked DAO with the object under test
        account.setDAO(dao);

        //call the method under test
        long charge = account.calculateCharges();

        //verify that the 'countOverdrawnDaysThisMonth' was called
        verify(mockedDao).countOverdrawnDaysThisMonth();
    }
}

Taking centre stage in all this is the Mockito class which has a bunch of static methods that are used within the unit test (note the static import on line 1).

The call to the ‘mock’ method (line 10) creates a mock object that can be used in place of a real AccountDAO. The call to ‘verify’ (line 19), will throw an exception if the ‘countOverdrawnDaysThisMonth’ method was not called on the mock object.

It is worth noting here that this is a simple example which just demonstrates the basic principle of verification, it is also possible to use the verify method to check for parameter values and ranges in the method call too.

Testing that the account performs its calculations correctly

In the above example, we mocked the DAO but didn’t specify what any of the mocked methods should do. In this case, all methods will return sensible default values of: null, zero or false. More commonly we need to specify something other than these defaults when writing our tests:

import static org.mockito.Mockito.*;
import static junit.framework.Assert.*;
import org.junit.*;

public class TestAccount {
    private Account account;

    @Before
    public void setup() {
        AccountDAO mockedDao = mock(AccountDAO.class);

    	//specify that this method on the mock object should return 8
        when(mockedDao.countOverdrawnDaysThisMonth()).thenReturn(8);

        account = new Account();
        account.setDAO(dao);
    }

    @Test
    public void checkChargesWhenOverdrawn() {
        //call the method under test
        long charge = account.calculateCharges();

        //assert that the charge was £2 per day overdrawn
        assertEquals(charge, 16);
    }
}

The statement on line 18 specifies that whenever the ‘countOverdrawnDaysThisMonth’ is called it should return a value of 8; overriding the default of zero.

Given that the correct charge is two pounds (or dollars) per day overdrawn, then the assertion on line 25 will pass if the account performed the correct calculation (8 x 2 = 16 right).

Comments

There’s loads more to Mockito than we’ve looked at here. It’s a neat testing tool that works great with JUnit or TestNG. I’ve found that it’s small enough to learn quickly and capable enough to be really useful. Give it a go and write a comment below to let me know what you think of it.

It’s not often that changes to MySQL configuration need to be made. This post is, therefore, more a reminder to myself than anything else.

First locate the configuration file. On my Mac I found this empty configuration file had been created as part of the installation process:

/etc/my.cnf

You’ll need super-user privileges to update it. I used:

sudo vi /etc/my.cnf

Enter the configuration settings you require. I wanted to update the maximum packet size so I entered:

[mysqld]
max_allowed_packet=16000000


Then you should be able to stop MySql with:

mysqladmin -u root -p shutdown


Restart it using whatever start script you prefer. To make sure that your changes have taken effect you can print the server variables to the console with:

mysqladmin -u root -p variables


The assert keyword was introduced in Java 1.4 and has since been a sadly under-used language feature. Assertions offer developers a neat way to implement error detecting statements that are only active during development and can be turned off in production environments.

For example you might want to check that appropriate values are passed to a method during development to ensure that it is being called correctly:

private void onlyPositiveNumbersPlease(int i) {
    assert i > 0;

    //rest of method implementation...

}

If the assertion fails, then an AssertionError is thrown. If you have a lot of assertions in your code, then its useful to be able to specify a value that will be used in the error message:

private void onlyPositiveNumbersPlease(int i) {
    assert i > 0 : "only positive numbers are allowed";

    //rest of method implementation...

}

The value that is specified can also be any primitive type, for example:

File f = loadFile();
assert f != null : 404;

In all cases, the value is converted to a String and set as the detail message of the AssertionException.

When the Java source is compiled, assertions instructions are included in the bytecode that is generated. However, by default, the assertions are not executed at runtime.

In order to activate all of the assertions, a command line flag must be passed to the JVM:

$ java -ea co.uk.smartkey.ui.MainClass


it is also possible to specify that assertions should only be activated for classes within a certain package. For example to run the same application as before, but only activate assertions for classes in the util package of our application, you could use something like:

$ java -ea:co.uk.smartkey.util co.uk.smartkey.ui.MainClass


if you just wanted to turn on assertions for a single class, you can specify the class name instead of the package name. Finally, if you really feel the need to, you can turn on assertions in the Java system classes with this:

$ java -esa co.uk.smartkey.ui.MainClass


Personally, I like using assertions as they can help to iron out problems during development that are unlikely to need checking for in production. Language level support for them means that the statements are only used if the JVM is launched with them activated; this ensures that there is no performance overhead associated with them when they are not in use.

Some things in Java seem to be a whole lot trickier than they need be, and working with dates is a good example of this. The Date class’ primary purpose is storing date values. For date oriented calculations the Calendar class should be used. The calendars will handle tricky problems like leap years but the methods for doing this operate at a low level and in many cases you still need to do some of the calculations for yourself. In addition to the standard classes, there’s some great support for working with dates provided in the Apache commons libraries; these libraries don’t provide a method for counting days between two dates though.

Anyway, to cut to the chase, here’s the solution I came up with:

public class DateTools {
    private static final int MILLISECONDS_IN_DAY = 1000 * 60 * 60 * 24;

    /**
     * Calculates the number of days between start and end dates, taking
     * into consideration leap years, year boundaries etc.
     *
     * @param start the start date
     * @param end the end date, must be later than the start date
     * @return the number of days between the start and end dates
     */
    public static long countDaysBetween(Date start, Date end) {
        if (end.before(start)) {
            throw new IllegalArgumentException("The end date must be later than the start date");
        }

        //reset all hours mins and secs to zero on start date
        Calendar startCal = GregorianCalendar.getInstance();
        startCal.setTime(start);
        startCal.set(Calendar.HOUR_OF_DAY, 0);
        startCal.set(Calendar.MINUTE, 0);
        startCal.set(Calendar.SECOND, 0);
        long startTime = startCal.getTimeInMillis();

        //reset all hours mins and secs to zero on end date
        Calendar endCal = GregorianCalendar.getInstance();
        endCal.setTime(end);
        endCal.set(Calendar.HOUR_OF_DAY, 0);
        endCal.set(Calendar.MINUTE, 0);
        endCal.set(Calendar.SECOND, 0);
        long endTime = endCal.getTimeInMillis();

        return (endTime - startTime) / MILLISECONDS_IN_DAY;
    }
}

As you can see each of the dates passed to this method are converted into milliseconds and the number of days between them is calculated based upon the number of days this equates to.

In order to ensure that the times are not relevant in the dates, these are set to zero. This means that if the start date is at 11:00 PM, and the end date is at 1:00 AM the next day, you’ll still get one day returned from this method call, rather than zero.

There are two ways to ignore files in svn: global settings and local. Global settings configure the users environment with some rules for ignoring files, but generally the local ignores are more useful and will be discussed here.

Most projects have files that should be ignored and not included in the version repository. For example, in Java projects, the compiler output shouldn’t be included as these can be regenerated from the source anyway. You might also have temporary cache files being generated, or output from running unit tests that you don’t want to share too.

Ignoring files and directories

Each directory in a svn managed project has a sub-directory called .svn which contains configuration information that svn uses when working in that directory. To make svn ignore certain content within a directory you need to configure an svn:ignore property for it.

To demonstrate this let’s work with the following project directory structure:

myproject/log-2009-12-01.txt
myproject/log-2009-12-02.txt
myproject/build/classes

First let’s tell svn to ignore the log files that have been created. I’m using SVN 1.5.4 on a Mac so I’ll demonstrate this using a command line but you could do much the same using a GUI tool like Tortoise:

$ svn propset svn:ignore 'log-*.txt' myproject

The above command has used the propset command to set the svn:ignore property value to log-*.txt for the myproject directory.

Note that it is possible to use a wild-card ‘*’ as part of the file name. You can also use the ‘?’ symbol to match a single character in a file name but svn does not currently support any more powerful matching features.

Importantly note also that the file name must be quoted in order that the literal value is passed to the svn command; without this the shell will process the wild-card and pass all matching file names instead.

You can inspect the value of this property using the propget command like this:

$ svn propget svn:ignore myproject
log-*.txt

An ignore property can also be applied to directories, causing all files and sub-directories within it to be ignored. To make svn ignore the classes directory and its contents we could use the command:

$ svn propset svn:ignore 'classes' myproject/build

Setting multiple ignore rules within a directory

So far we’ve looked at how we can set an individual ignore rule within a directory using the propset command. Although both of the rules we’ve demonstrated have resulted in multiple files being ignored, either by using a wild card syntax or by specifying a directory whose content will also be ignored, we’ve not yet discussed is how these rules can be combined within a directory; for example: to ignore all log files and also a sub-directory:

/myproject/log-2009-12-01.txt
/myproject/log-2009-12-02.txt
/myproject/classes

The svn:ignore property is actually a list of file name patterns that svn must ignore. The propset command simply overwrites that list with a single line that includes the pattern you specify when you issue the command.

To create a list of file names that will be matched, use the propedit command instead:

$ svn propedit svn:ignore myproject

Your svn editor will then be started and you can edit the list of filenames that must be ignored. For our example it would need to look like this:

log-*.txt
classes

Note that each file name pattern must be on a separate line.

Ignoring versioned files and directories

You must be aware that the svn:ignore properties only apply to any files that are not under version control.

In practical terms this means if you accidentally add a file or directory to your version control, you will need to explicitly issue a svn delete command (rm) in order that svn will ignore the files.

Commands like add and import work recursively in svn, so it’s easy to accidentally add files like those mentioned above to a versioned project. For example if our log files were accidentally added we could issue this command to delete them from svn:

svn rm log*.txt

Note this time that the filename is not quoted as we want the shell to pass all log files to be deleted.

After committing the changes to the project, the files will no longer be managed by svn and the ignore properties will once again work.

After a little experimenting, I figured out the following commands could be combined as illustrated below:

From within the project root folder this command can be used to list all of the .svn directories:

$ find . -type d -name .svn

If your directory names don’t have spaces or quotes in them, then you could just pipe the find command directly into xargs and rm to delete them all:

$ find . -type d -name .svn | xargs rm -rf

If you do have spaces or quotes in your directory names, then you need to change the newlines returned from find into null characters (notice the -print0 flag), and make xargs use this to split the input into individual file names (see the -0 flag) rather than the newlines, spaces and quotes that it normally looks for:

$ find . -type d -name .svn -print0 | xargs -0 rm -fr

The above command will delete all directories named ‘.svn’, regardless of whether they have spaces, or quote characters in their names.

The basics

To define an inner class, just define one class within another:

public class Outer {
    public class Inner {

    }
}

Generally, the outer class will be responsible for creating instances of the inner classes and this could be done in the methods of the outer class, for example here where the outerClassesMethod creates an inner class instance and calls its method (lines 7-8) :

public class Outer {

    private String message = "foo";

    public void outerClassesMethod() {
        //create an inner object to do the work
        Inner ii = new Inner();
        ii.innerClassesMethod();
    }

    private class Inner {
        private void innerClassesMethod() {
            System.out.println(message);
        }
    }
}

Note above that the inner classes method (line 12), although private, can still be called by the outer class. Also note that the private message field on the outer class (line 3) can be accessed from the inner class. A call to the outerClassesMethod will cause the innerClassesMethod to be called and the message ‘foo‘ to be printed to std out.

What about ‘this’ ?

Each object in a Java application can refer to itself using the ‘this’ reference. When an instance of an inner class is created, it is created within the instance that created it; so what effect does this have on ‘this’ reference?

In fact, inner class instances have more than one ‘this’ reference: one that refers to the instance of the inner instance, and one that refers to the outer instance. Consider this simple change to the example:

public class Outer {

    private String message = "foo";

    public void outerClassesMethod() {
        //create an inner object to do the work
        Inner ii = new Inner();
        ii.innerClassesMethod();
    }

    private class Inner {
        private String message = "bar";

        private void innerClassesMethod() {
            System.out.println(message);
        }
    }
}

Now that the inner class also has a field named message, the text ‘bar‘ will be printed out instead of ‘foo’.

The reason for this is that the inner classes message field has shadowed the outer classes one. The inner classes println call (line 15) would have the exact same behaviour if it were written as:

System.out.println(this.message);

if we want to access the message field on the outer class, then we need to use a ‘this’ reference for the outer instance; we do this by pre-pending the class name to ‘this’ as follows:

System.out.println(Outer.this.message);

substituting the println statement with the one shown above, will access the message field on the Outer class and cause ‘foo‘ to be printed out once again.

Creating inner instances from outside the outer class

As noted above, the inner instances will generally be created within the outer class. However, it is possible for inner instances to be created in other places too; for example, a factory class could be used to create the outer objects and also the inner objects that they will contain.

To demonstrate this scenario, we’ll use a slightly revised example where the inner class, and its method, have been made publicly visible. Note also that the outer class now has a constructor (lines 4-6) that will allow us to initialise its private message field (line 3) :

public class Outer {

    private String message;

    public Outer(String message) {
        this.message = message;
    }

    public class Inner {
        public void innerClassesMethod() {
            System.out.println(message);
        }
    }
}

If our factory class is to create the inner class instances, then it must associate them with an outer instance. In order to do this the new keyword must be scoped to a particular outer instance using this somewhat cumbersome syntax:

Outer o = new Outer("foo");
Outer.Inner i = o.new Inner();
i.innerClassesMethod();

Note the use of the new keyword (line 2) is prepended with the outer object reference (i.e. o.new). It is this outer reference that will be accessible within the inner object’s methods using the ‘this’ syntax explained above.

So, when the call to the inner classes method is made (on line 3), the private message field of the outer instance will be printed out – i.e. we’ll see ‘foo‘ appear in std out.

Static inner classes

The static modifier can be applied to member level classes in much the same was as it can with the fields and methods of that class. As with fields and methods, use of the static modifier pretty much turns off OO.

public class Outer {

    private String message;

    static class Inner {
        private String message;

        public void innerClassesMethod() {
            //can access the message field defined on this class:
            System.out.println(this.message);

            //can't access the one from the outer class though:
            System.out.println(Outer.this.message);
        }
    }
}

In much the same way as a static method is not associated with an object instance, objects created from static inner class definitions are not associated with an outer object instance either.

Static inner classes therefore do not have a second this reference, and cannot access the non-static fields of the outer class (line 13 in the above example would produce a compiler error). Effectively, inner classes are just regular classes defined within an outer classes name-space.

The best way I know to explain ‘this’ properly is by taking a look at how object oriented languages actually work and comparing them to their older siblings: structured programming languages.

In a structured programming language (like C or Pascal for example) you store data in a struct or a record and reuse code by creating functions. Moreover, when you call a function you may pass them records to work with.

So before we start looking at Java, let’s consider some pseudo-code in an imaginary structured programming language. First we’ll define an account record structure in this language, and then a simple function that can be used to update them:

//define an account record structure with two fields (balance and overdraft)
record account {
    int balance;
    int overdraft;
}

//now define a function for updating the account's balance
void deposit(account a, int amount) {
    a.balance += amount;
}

So, given an account record ‘a’, we could use our imaginary language to deposit £100 by calling the above function as follows:

//create a new account record
a = new account();

//update the account's balance using the function
deposit(a, 100);

In an Object Oriented language like Java we would more likely define an account class with a deposit method:

public class Account {
    private int balance;

    public void deposit(int amount) {
        balance += amount;
    }
}

and use it like this:

Account a = new Account();
a.deposit(100);

As we know, Object Orientation is just a higher level programming abstraction. Therefore, the code that you’d write in Java is just another way of expressing what you’d write in a procedural language.

In fact, the Java compiler actually produces bytecode that looks more like procedural code. For example, a method call like this:

a.deposit(100)

would actually be compiled as though it were a function call:

deposit(a, 100);

and our deposit method would be treated likewise and compiled as though it were:

void deposit(Account this, int amount) {
    this.balance += amount;
}

Note that the compiler has restructured the statement as a function and introduced an initial parameter called ‘this’ that will be a reference to the object that the method is being invoked on. As you can see then, it is this ‘this’ variable that allows you to refer explicitly to the current object.

The one gotcha here is if you define a method with the static modifier. Static methods don’t require that an object is created before they are called; they are generally just called via the class name, like Math.min(…) for example. In this sense they really are just like a procedural language function so the compiler does not introduce a ‘this’ parameter. Clearly then, this is why you cannot access ‘this’ from within static methods.

Extending the Object Oriented Programming Model

Encapsulation can be regarded as a barrier that an object puts up to protect itself from other objects. Within an object we generally expect there to be fields (that each object will have it’s own instance of) and methods (that can be called to affect that object). Inner classes extend Java’s OO model by also allowing objects to be created within an object, thus making the code within an object truly object oriented.

To demonstrate this, lets start by looking at some less-than-ideal Swing GUI code. The DemoUI class is a simple application frame that uses a WindowCloser object as a listener for its window events. The code for both of these classes is shown here:

public class DemoUI extends JFrame {
    public DemoUI() {
        //add the window closing event listener
        this.addWindowListener(new WindowCloser(this));
    }

    public void shutdown() {
        int answer = JOptionPane.showConfirmDialog(this, "Are you sure?");
        if (answer == JOptionPane.YES_OPTION) {
            System.exit(0);
        }
    }
}

class WindowCloser extends WindowAdapter {
    private DemoUI demoUI;

    public WindowCloser(DemoUI demoUI) {
        this.demoUI = demoUI;
    }

    public void windowClosing(WindowEvent windowEvent) {
        demoUI.shutdown();
    }
}

When the user clicks application frame’s close button (i.e. the cross button on the frame’s title bar), the windowClosing method will be called on the event listener which will, in turn, call the shutdown method of the frame. The shutdown method prompts the user to make sure that they want to quit before calling System.exit(…) to exit the application.

Although a fairly simple example, this code is more complex than it need be. The reason for this complexity stems from the fact that the objects created from these classes are completely separate from one another, we could picture these objects as follows:

Because these objects would otherwise have no association with one another, we must provide a reference from the listener to the frame in order that the frame’s shutdown method may be called by the listener. It also means that the frame’s shutdown method cannot be declared private, thus weakening its encapsulation.

Applying Inner Classes

If we make the listener an inner class of the frame, then it will have access to all members of the frame (even private ones). We do this simply by moving the listener class definition inside the frame class:

public class DemoUI extends JFrame {
    public DemoUI() {
        //add the window closing event listener
        this.addWindowListener(new WindowCloser());
    }

    private void shutdown() {
        int answer = JOptionPane.showConfirmDialog(this, "Are you sure?");
        if (answer == JOptionPane.YES_OPTION) {
            System.exit(0);
        }
    }

    private class WindowCloser extends WindowAdapter {
        public void windowClosing(WindowEvent windowEvent) {
            shutdown();
        }
    }
}

Now that the listener is declared as an inner class of the frame, instances of the listener will be created inside the enclosing frame instance. In contrast to the above example, this can now be pictured as follows:

Note that there is now no need to keep a reference to the frame instance from the listener as the listener object is implicitly associated with it. This means that the shutdown method, although declared as private on the frame, is still available to the listener. Finally, and for good measure, because the listener is only ever used by the frame, we can make its class definition private and prevent any other classes from accessing it.

Method Level Inner Classes

The example above shows an inner class being defined at the same level of scope as the methods and fields (aka the members) of the outer class. This type of inner class is therefore commonly referred to as a member level inner class.

In Java it is common to declare variables where they are first used. It is possible to do this with inner classes too. In this example the inner class has been declared just before it is used; i.e. within the constructor method of the frame:

public class DemoUI extends JFrame {
    public DemoUI() {
        //add the window closing event listener
        class WindowCloser extends WindowAdapter {
            public void windowClosing(WindowEvent windowEvent) {
                shutdown();
            }
        }
        this.addWindowListener(new WindowCloser());
    }

    private void shutdown() {
        int answer = JOptionPane.showConfirmDialog(this, "Are you sure?");
        if (answer == JOptionPane.YES_OPTION) {
            System.exit(0);
        }
    }
}

A method level inner class can only be used in the method it is declared in and it is inherently private to that method. Classes defined at method level also have the additional advantage of being able to access local variables in that method, just so long as they are declared as final.

Anonymous Inner Classes

The next progression from a method level inner class is an anonymous inner class. In the previous example, the class was defined just before it was created and used. The name for the class was therefore only ever used in the definition and then in the subsequent call to create an instance of it. In cases such as this, it is possible to create and define the inner class in a single statement, rendering its name irrelevant:

public class DemoUI extends JFrame {
    public DemoUI() {
        //add the window closing event listener
        this.addWindowListener(new WindowAdapter() {
            public void windowClosing(WindowEvent windowEvent) {
                shutdown();
            }
        });
    }

    private void shutdown() {
        int answer = JOptionPane.showConfirmDialog(this, "Are you sure?");
        if (answer == JOptionPane.YES_OPTION) {
            System.exit(0);
        }
    }
}

You can see from this code that the inner class has now been created using the Java ‘new’ operator but that the name WindowCloser is no longer used; just the supertype WindowAdapter is used instead and the implementation of the windowClosing method is simply specified in the curly braces following the normal constructor call.

This example demonstrates how to create an anonymous subclass of the WindowAdapter class which is an abstract class defined within the Swing APIs. You can create an anonymous subclass of any class though using this syntax; just place the code for the subclass within the curly braces and you’re done.

It is also possible to implement an interface using this syntax. So for example if there were a Quit button in our GUI, then we could implement the ActionListener interface for the event listener that reuses the shutdown method like so:

JButton quitButton = new JButton("Quit");
quitButton.addActionListener(new ActionListener() {
    public void actionPerformed(ActionEvent actionEvent) {
        shutdown();
    }
});

Summary

The discussion I’ve presented above illustrates the most common use of inner classes but there are dozens of other uses; for example, the Spring data abstraction layer uses them to great effect, as does the Wicket web framework.

Fundamentally, inner classes in Java enable objects to be created within objects. This simple principle opens up a whole array of design choices for object aggregation. With careful consideration, inner classes allow your code to be more concise and maintainable than it might otherwise be. A good understanding of inner classes is therefore a key skill for any serious Java developer.