Sunday May 20, 2012

Unauthorized Solaris Eclipse Viewing

Definitely don't try this at home. Even if you do have the correct CD.

Photo of a partially eclipsed sun visible through a Solaris 2.6 Intel Platform CD-ROM

Monday Dec 19, 2011

Solaris goes to 11

I've been using Solaris Express for about the last three years with the Shelley autonomous vehicle project. We've been using the 2009.05 version very successfully for the Java Realtime systems having previously upgraded from Solaris 10u5. Solaris Express, now Solaris 11, is a lot more convenient and comfortable to use. We'll be upgrading to Solaris 11 GA in the next couple of months. Solaris 11 is a whole new Solaris and has been modernized in nearly every way possible. For Solaris oldsters, yes it's different than what you're used to. But it's better. Really. Yes, really! Get over it and get on with it. You'll be happier in the long run. I know that I am!

Wednesday Oct 26, 2011

Generics Return Type Trick

I've been using Java generics for almost five years, since about a year after Java 6 was released. There is a generics feature that I've been using for most of that time that it turns out I didn't fully understand. Consider the following:
Surprising Java Generics
public class Surprising {

    public static <A extends Collection<String>> A foo(A input) {
        return input;
    public static void main(String[] args) {
        ArrayList<String> array = new ArrayList<String>();
        List<String> list = array;
        Collection<String> collection = list;
        ArrayList<String> assignArray;
        List<String> assignList;
        Collection<String> assignCollection;
        assignArray = foo(array);
        assignArray = foo(list);
        assignArray = foo(collection);
        assignList = foo(array);
        assignList = foo(list);        
        assignList = foo(collection);

        assignCollection = foo(array);
        assignCollection = foo(list);        
        assignCollection = foo(collection);

Several lines of this program are rejected by the compiler due to "incompatible type" errors. The incompatible type error occurs because the statement is attempting to assign a less specific type, such as Collection, to a more specific type, such as ArrayList. The compiler is right to complain!

The tricky bit here is that the other assignments all work. Consider the very first assignment, "assignArray = foo(array);". The foo() method is declared as returning the generic type variable A which is declared as A extends Collection<String>. Wait a second, if A only specifies that it extends Collection<String> how is it that we are assigning a result of foo() to assignArray which is more specific than Collection? You shouldn't be able to assign a Collection<String> result to a ArrayList<String> variable.

The answer is that the exact return type of foo() is not determined solely by the declaration of A. Instead, the compiler looks at all the usages of A in the expression and determines a single type for all of the As in the expression. If a single type for A can't be determined then the compiler will also produce an error. Usually though it is more common that one of the parameters isn't an A.

For our assignment statement, "assignArray = foo(array);", the type of A is being determined by the type of the parameter "input". Once the actual type of A for this expression is determined to be "ArrayList<String>" then the return type of foo() is compatible with assignArray.

Not all of the assignments in this program need this magic. Most of them work by virtue that the assignment type is less specific than the return type of foo() for that particular invocation.

This property of how a generic type such as A interpreted in Java is extremely useful. It's very commonly used with collections where the collection you get back from a method is the same type as the collection you pass in. You probably use this all the time and, like me, didn't think about it.

Looking back over my old code where I used generics I found a number of cases where I used two type variables, one for return type and one for a parameter, in cases where, because of this magic, only one type variable was needed. If you have code which has a separate type variable for a return type, check carefully, you may not need it and it may actually be less safe than with one type variable and this trick.

Thursday Oct 06, 2011

JavaOne 2011 : Parallel Data for Java Slides

Despite having a bad cold I made it through my JavaOne presentation on the parallel library extensions that are being developed for Java 8. As I said following one coughing bout "DayQuil--unofficial sponsor of this session". Hopefully it was intelligible and coherent for those who had to listen to my coughing and sniffling throughout.

Here's the slides for the presentation 25066 : Bulk Hauling -- Parallel Data for Java. Session audio may be available on the Java Channel in a few days.

Wednesday Oct 05, 2011

JavaOne 2011 : Collections BOF Slides

The annual JavaOne Collections Birds-of-a-Feather gathering was on Monday night. It was extremely well attended and I hope was useful to everyone who participated. Here are the slides for the presentation part of the session. The audio should be up on the JavaOne site in a few days.

2011 Collections Gathering Slides

My other session "Bulk Hauling : Parallel Data for Java" is on Thursday @ 11 in Hilton Yosemite. It will cover the lambda based parallel extensions to Collections we are building for Java 8. See you there!

Update:I've corrected the broken link to my slides. Slides are also up for the Parallel Data talk.




« August 2016