Anonymous parameters

Introduction

The simple idea is to allow the absence of parameter identifiers when these are not really needed. Currently, the Java compiler insists that you assign a parameter an identifier explicitly, even if there are a bunch of scenarios where a little more leniency would be nice.

Interface definitions

When defining a contract in Java you are also required to assign it an identifier even though you would never be able to use it. Anonymous parameters allows you to skip this exercise in Java verbosity, and only type the actual signature, akin to function prototypes of C/C++ header files:

        interface MouseListener extends EventListener
        {
            void mouseClicked(MouseEvent);
            void mouseEntered(MouseEvent);
            void mouseExited(MouseEvent);
            void mousePressed(MouseEvent);
            void mouseReleased(MouseEvent);
        }

It was pointed out to me (thanks to Paul Benedict) that without the parameter name, the clarity of intent is diminished, and interfaces are all about intent of design. We can not rely on JavaDoc's for this, since it's optional and not always available. Last, but not least, current IDE's very much rely on named parameters being present in order to support their auto-completion mechanism.

For these reasons, anonymous parameters in method declarations of interfaces are no longer permitted as per rev. 99 of this branch.

Event callbacks

The Java event mechanism which revolves solely around interface callbacks often requires you to (unless using an AWT adaptor) not only acknowledge all callbacks defined by the interface, but also to explicitly assign parameter identifiers. This may be skipped with anonymous parameters:

        class SomeClass implements MouseListener
        {
            void mouseClicked(MouseEvent evt)
            {
                // This is the only event we're interested in, do something with it.
            };
           
            // The remaining ones are of no interest, we do not need to explicitly assign identifiers.
            void mouseEntered(MouseEvent){};
            void mouseExited(MouseEvent){};
            void mousePressed(MouseEvent){};
            void mouseReleased(MouseEvent){};
       }

Catching exceptions

Often you have no need for accessing the exception object in a catch block, yet once again you are always forced to assign it an identifier regardless of whether you need it or not. This is particular annoying in the case of certain checked exceptions when working with JDBC or doing file IO:

        InputStream is = null;
        String fileName = "test.properties";
        try
        {
            is = new FileInputStream(fileName);
        }
        catch (FileNotFoundException)
        {
            // We already know the file was not found, the exception object is rarely needed!
        }
        finally
        {
            try
            {
                is.close();
            }
            catch (IOException)
            {
                // What would you possibly use the exception object for here?
            }
        }

IDE "unused" flagging

In an effort to assist the developer in catching unused variables, IDE's like NetBeans will often flag these visually in the scenarios mentioned above. Most people have learned to squint to not see this, but it's noise we could easily be without:
Which, with anonymous parameters, could be made to look like this:

Conclusion

It is a minor change to the parser consisting of simply adding one more production rule and a few lines of code to create an "autoIdentifier" to be placed in the symbol table just as if the developer had assigned one himself. Anonymous parameters should be 100% backwards compatible - it serves only for developer convenience, to allow for a bit more lenient syntax and less visual noise. The only critique I can think of would be that you might loose some kind of documentation aspect by not requiring an identifier. Then again, identifiers aren't really meant for this (@param javadoc is) and their existence alone doesn't automatically guarantee a good identifier name has been chosen (arg0 etc).

This experimental feature is part of the Kijaro sandbox. Feel free to comment on the developer mailinglist or email me directly at casper.bang@acm.org