Showing posts with label java 7. Show all posts
Showing posts with label java 7. Show all posts

Tuesday, May 29, 2012

Java 7: Multi-catch block


I wrote a blog about using multiple exceptions catch statement long before Java 7 was released. That time, multi-catch block and better re-throw was part of Project coin, small language enhancements. Now Java7 being out, we can see it action. This is how it works.

First of all, to get multi-catch working, we need to set '-source 7' as commond line parameter during compilation.
We can write multi-catch statement as -

        try {
            newCatchBlock.methodWithMultipleExceptions();
        } catch (MyException1 | MyException2 exception) {
            ...
        }

This can be useful in few cases and can save few lines of code. The type of exception caught will be the closest common base class. If there is no common class, the type of object will be Exception, which is the base class for all exceptions. However, that means you will not be able to invoke methods from MyExcepetion1 or MyExcepetion2, as the object will be of type Exception. The parameter in catch block is final. Trying to reassign value to it will result in error "Multi catch exception may not be assigned".

Another important point to note is that exceptions in multi-catch statement can not have parent-child relationship. You can not have catch block like (IOException | FileNotFoundException exception) as FileNotFound is subclass of IOException.

When I looked for how this feature is implemented in language, I found that there is no magic here. The generated bytecode will just have a plane old catch block which catches exception of closest common base class. That explains the type of caught exception as well.

This feature adds a bit of syntactic sugar. As I mentioned in my previous blog on this topic, I don't see this as being very useful in day to day programming. I don't remember last time when I wanted to catch multiple exceptions and have the same code to handle them. However, this does make Java a little bit better than before.

Thursday, June 17, 2010

Public defender methods - yet another Java 7 proposal

Support of lambdas and closures is the most important language feature that is proposed to ship with Java 7. With lambdas, it will be possible to implement some interesting methods into the old collection classes. Methods like find, select, reject, forEach, include can take a lambda and perform relevant operations on the collection object. However, adding these methods into existing collection interfaces would be a problem as it will break the existing implementations. To address this issue, the proposal of defender method is suggested.

Inherently static nature of Java restricts the developer from extending the functionality without affecting the existing usages. The current implementation of interfaces doesn't allow us to add a new method to interface without breaking all its implementation. Sometimes, there is a strong case for adding new behaviour in the interface so that its applicable to all the implementations. Currently the only way to do this is to change interface into an abstract class and change the code to extend this abstract class. However, we need to change at all the places where this interface is implemented and anyway, this change is not always possible because a class might already have a superclass. The proposal of public defender method suggests a solution.

This proposal allows to provide a default implementation for interface methods. This default implementation will be a static method on helper class and it will be invoked if the class implementing this interface does not provide any custom implementation.

The proposed syntax is -

public interface List {
extension public List select(#boolean(Object)) default ListHelper.select
// other list methods
}

Here, select method from the List interface takes a lambda (which is again a proposal) as argument. The 'extension' keyword signifies an extension method. It must have a default implementation which is provided by static select method from ListHelper class. This method has the same signature as the extension method and it will receive the the extended interface object (list) as the first argument. If the class implementing this List interface does not provide implementation, the select method from the ListHelper class will be used. This method from the helper class which provides the default implementation is called as public defender method, as it defends the classes that does not implement extension method.

Obviously, the specific implementations of the interface class can provide an optimised implementation for extension method.

As mentioned in the Baptiste Wicht's blog, with this approach, it is possible to include the static methods in Collections class to the List interface. This will allow us to invoke methods like reverse() on the list object itself, rather than passing the object to the static method in Collections class. Also, it will allow us to override these methods.

In general, this proposal will allow us to add the relevant methods to interfaces and be dependant on the classes with static utility methods.
so we will be able to do -

list.select(..)

instead of

ListHelper.select(list, ..)

The helper class will still hold the implementation, but objects need not be aware of them.

Along with the ability to extend the already existing interfaces, this proposal will have more profound effect on the programming style. It will be possible to create a interface in which, all the methods are extension methods with default implementation. Then, it will be possible to use this interface as 'mixin' and use it to achieve the effect of multiple inheritence. Also, abstract classes may not be required as the same functionality can be achieved by interfaces with few defender methods.

We can compare this proposal with the extension methods introduced in C# 3.0. Although not exactly same, conceptually both are same. C# extension methods allows us to add methods in the existing classes by defining the static methods in another static class. However, The visibility of C# extension methods is much more controller as the these methods are available only in the classes that import the static class with extension method. This is different from defender methods where extension methods will be available to all the implementations of the interface.

At the moment, defender methods is only a proposal for Java 7 and just like other proposals, we are not whether it will come up with Java 7. but nevertheless, this interesting language feature will improve the extendibility of dying Java language and will allow us to extend the existing library.