Tuesday Jan 28, 2014

Duke's Choice Virtual Pilsner

With the release of Java 8 coming soon it seemed like a good time to begin to prepare for the celebrations. In consultation with Duke himself, the following recipe was arrived at and has been brewed. The beer style is hybrid being brewed like a California Common Beer (an ale) but with a Pilsner grain and hops bill.
Duke's Choice Virtual Pilsner
2.5kg / 5.5lb Canadian 2-row barley malt (Rahr Malting)
1.1kg / 2.5lb Pilsen dry malt extract + 60g/2oz for yeast starter
50g   / 1.75oz Hallertau hops (4.5 Alpha)
White Labs WLP080 Cream Ale  or Wyeast 2112 California Lager

Create a 800ml yeast starter with 60g/2oz yeast Pilsner dry malt extract at least
6 hours ahead.

7.5 liter/2 gallon mash of barley @ 65C/150F for 45 minutes. 

Sparge with 7.5 liters/2 gallons 77C/170F water.

Bring to a boil for 60 minutes
At hot break add 28g/1.0oz of hops
At 30 minutes add 15/g/0.5oz of hops
At 45 minutes add Irish moss tablet (Whirlfloc) and 2.5ml/ 1/2tsp yeast nutrition 
At flame out add 7g/0.25oz of hops

Cool to 25C/80F as quickly as possible. Rack and oxygenate to carboy with minimal
boil sludge, and top off to 21 liters/5.5 gallons in 25liter/6.5 gallon

Pitch yeast and add an airlock. Ferment at 15-17C / 59-63F

After 2 or 3 weeks rack to 19 liters/5 gallon secondary with minimal headspace. 
Add airlock. Refrigerate for 1 week.

Rack to keg, purge oxygen and refrigerate for 48-72 hours before carbonation to 
30psi. Or bottle and age for at least two weeks.

Thursday Sep 26, 2013

JavaOne 2013 Collections Performance Fundamentals

Here are the slides from my JavaOne 2013 talk on Collections Performance

Collections Performance Fundamentals [PDF]

When the audio recording of the session is available I will repost with the recording URL.

Thursday Oct 04, 2012

JavaOne JDK 7 In Action Tutorial NIO.2 & Fork/Join Demo Source

Here is the source for the NIO and Fork/Join demo which was presented in the JDK 7 in Action Tutorial.

Java SE 7 Image Thumbnailer Demo

The slides for the presentation are available on Joe Darcy's blog here : JavaOne 2012: Slides for "JDK 7 Action" Posted

JavaOne Collections Talk Slides

Here are the slides from my JavaOne 2012 talk on Java Collections

Field Guide to Java Collections [PDF]

When the audio recording of the session is available I will repost with the recording URL.

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.




« June 2016