A word used to describe something

Announce - Orthodox Type Reflection Library

Tim — Thu, 21 Feb 2008 23:39:00 +1100

Prior to the release of Java 5, the Java library had 1 class that provided access to type information at runtime - java.lang.Class. However, with the introduction of generics in Java 5, this has been extended significantly. Dealing with all these classes, and working with them at runtime, is overly complex, and reduces the power of generics.

Orthodox is a library that makes it easier to work with the Java type system at runtime.

In Java 5, the type system includes the interfaces:

java.lang.reflect.Type
java.lang.reflect.ParameterizedType
java.lang.reflect.WildcardType
java.lang.reflect.TypeVariable
java.lang.reflect.GenericArrayType
java.lang.reflect.GenericDeclaration

Have you ever tried to use those interfaces? It's not straight forward.

Imagine a class com.example.Bean has a method getList() that returns an object of type java.util.List. You want to know what type of object that list will contain. Is it a list of Objects? A list of Strings? Something else?

If we look at the source code, we might see:

List< ? extends CharSequence > getList() { /* ... */ }

But how do we get access to that information at runtime? You might think it's impossible, due to type erasure, but the information is actually there, it's just that it's hard to get to because of all those different ways of representing a type.

Orthodox makes it easy to get at that information (and much more).

At the moment it's a 0.5 release, because it hasn't had enough real world usage to be sure that the API is right. Since the whole point of orthodox is to put a better API on top of java.lang.reflect.Type, getting the API right is important. And I don't want to declare it a 1.0 release until I'm happy that I've achieved that.

However, don't let the 0.5 tag scare you into thinking it's unstable or untested - I've put it through its paces, and it works like a charm.

Java Backwards Compatability

Tim — Thu, 21 Feb 2008 22:10:00 +1100

Ted blogged about the absence of leadership in the direction of Java (the language).

One of the comments there suggested we forget about backward compatibility.

I'm not necessarily for or against that idea, but I do think it's worth thinking about, so we know what it is we're trying to preserve, and what we're willing to give up.

By necessity then, the first step must be to define what we mean be backwards compatibility...

There are a number of possible ways we can be "backwards compatible" and some of them are easier to manage than others.

Since the original post/comment was about Java 7, I'm going to use "Java 6" to mean the "old" version of Java that we're trying to stay compatible with and "Java 7" to refer to the new, perhaps incompatible version. And I'll use closures as an example of a feature in Java 7 that may interfere with compatibility. You can substitute in your own features and version numbers if you wish.

As best I can identify, the various ways to preserve backwards compatibility are:

At the binary level

1. Source written in Java 6 can be recompiled for Java 7 For some people, this may be enough. Ditch any plans to keep running existing class files, throw away your binary jar files (or run them through a Java 7 converter), and recompile everything from source. It's more or less what Android is (although it hasn't added a new alternate syntax). However, it means that the new VM can't run old applets (for the devoted few who still care about applets) and it also means that you can't download a jar file from the internet and use it in your app unless you know whether it's a Java 6 jar file, or a Java 7 jar file. In practice we already have that problem. Java 5 jar files don't run on a Java 4 VM. But this would create the reverse - Java 6 jar files won't run on Java 7 VMs and Java 7 jar files won't run on Java 6 VMs. The only extent to which this can be considered to be "backwards compatible" is that you don't have to throw away your existing source code. You can make it run on the new VM (with a small amount of effort)

2. Old applications run unchanged on new VMs At its simplest, that just means that the Java 7 VM has support for running a pure Java 6 application. It's a bit like the Playstation 2 being compatible with the original Playstation - it had a PS1 embedded in it so it could play PS1 games. However, since JEE deployments are a significant focus on the java landscape, we probably need to extend the definition of an application to include anything packaged as an EAR or WAR file. Which means we need app servers that can run Java 6 applications as well as Java 7 applications. Presumably at the same time. The main complexity in that is the consequences for rt.jar. Does the VM need to expose a single version of rt.jar that is compatible with both Java 6 and Java 7 applications? Would it be possible for an app server running on a Java 7 VM to provide different versions of rt.jar to the different applications? Or would we need to have an rt.jar with a java.util package and a java7.util package? (The latter of which has serious consequences for the other possible definitions of "backwards compatible")

3. Old class files can be used by new class files (written in Java 7) This would mean that your new Java 7 source code would be able to use the existing jar file for your JDBC driver. It means that as far as Java 7 is concerned we need

A VM that can run Java 6 class files alongside Java 7 class files
A calling method from a Java 7 class file to a method in a Java 6 class file

4. Old class files can call methods on Java 7 classes If you want to be able to write a ListModel in Java 7, and then pass that to a swing component written in Java 6, then you need this. To do it properly, it means that the Java 6 code can use reflection on the Java 7 class, and get meaningful data back. The class file format may not need to be anything like the Java 6 class file format, but the reflection APIs and classloaders need to be able to hide the differences. This form of compatibility was one of the requirements that impacted generics.

At the source level

5. The Java 7 version of "javac" knows how to compile both Java 6 and Java 7 code This is easy. The Groovy compiler already does this - you just need a way to work out which syntax is being used in a source file.

6. Source that uses the Java 7 syntax can call methods on Java 6 classes This is pretty simple to do. The new syntax needs a way to invoke a Java 6 method, but the various "new" syntaxes being played with (Groovy, Scala, etc) already support this (although as Gilad Bracha's recent post on static variables points out, it has constrained the design of those languages).

7. Source that uses the old Java 6 syntax can call methods on new Java 7 classes This is fairly straight forward if you're happy to require that it's compiled with the new compiler. You need to decide what to do about classes that use new features. E.g. What if Java 6 code calls a method that returns a closure? If the Java 6 syntax has no way to represent that closure, then we have a problem.

8. Source written in Java 6 can have Java 7 features added to it slowly This would require that every Java 6 source file is also a valid Java 7 source file. It means that I can have a single source file, defining a single class, and one of the methods (that was written years ago) uses the old Java 6 syntax, while another method (that I wrote today) uses the new Java 7 syntax. And they live happily together in the same file.

I think we're likely to find different people care about different definitions for "backwards compatibility", and there will be some people who think we need to support all of them.

My personal opinion is that if you don't have #1, #2, #3, and #6 then it's not Java. Not having #7 (and probably #4 too) will seriously restrict the number of people that are willing to switch. Point #5 is easy to do (as groovy has shown) and useful enough that you'd be stupid not to do it.

So really the point to question is #8. And while it's useful, and I think we'd all like to keep it, the question has to be "Is it important enough to hold back the evolution of the language (and platform) ?"

Dimple - a random Google find

Tim — Sun, 29 Apr 2007 01:43:00 +1000

The dimple framework turned up after I did some (mostly) random searching on Google.

There are two interesting things about dimple

It matches pretty well to 2 libraries I wrote in the last couple of years: uniform and tie
In a previous ~~life~~job I worked on an application called Dimple (which had nothing to do with method interception, and wasn't even written in Java)

Just one of those interesting things that Google led me to.

Announce - Tie Method Interception Library

Tim — Tue, 10 Apr 2007 23:19:00 +1000

I'm pleased to announce that after sitting around for quite a few weeks, I have finally succeeded in pushing out the first release of "tie"

Tie is a method interception toolkit.

It's a simple, zero configuration, library to support dynamic interception at runtime. It doesn't do mixins, it makes no mention of pointcuts or aspects, it simply does method interception.

For projects which already making use of an AOP framework, that's probably not particularly useful - if you're a happy user of Spring-AOP, Guice, AspectWerkz or AspectJ, then Tie probably doesn't offer you anything new. But if (like me) you're not overly into this whole AOP thing, and you just want to use interception to apply the decorator pattern to a mix of different classes, then tie is exactly what you're after.

One of the reasons it took me so long to push the code out (I finished the bulk of the development about 2 month ago) is that I've spent a fair bit of time writing what I hope will be very useful documentation. So I'm going to avoid making this blog entry any longer than it needs to be, and just point you at the docs.

An early autumn rant

Tim — Sat, 31 Mar 2007 23:59:00 +1000

I got an email from sourceforge telling me about a new feature that they "will add to SourceForge.net in late spring/early summer" So that does mean that all the open source developers in South America, Southern Africa and Australia get to the feature 6 months early, or 6 months late?

It may seem petty, but it peeves me.

The world has pretty much come to a consensus that there are 12 months in the year, and they have generally accepted names. Why do companies insist on ignoring that, and use the northern hemisphere seasons to describe periods of the year?

So, what I think SF is trying to say is that they'll be adding the feature in the May-July period. But I may have to wait until November-January before I'm allowed to use it.

Superhero

Tim — Sat, 06 Jan 2007 17:29:00 +1100

It seems these quiz things are the cool thing to do... You are Spider-Man

Spider-Man		75%
Iron Man		65%
Superman		65%
Supergirl		55%
Hulk		55%
Robin		45%
The Flash		45%
Batman		45%
Catwoman		35%
Green Lantern		25%
Wonder Woman		20%

You are intelligent, witty,
a bit geeky and have great
power and responsibility.

Click here to take the "Which Superhero am I?" quiz...

You are Dr. Doom

Dr. Doom		74%
The Joker		70%
Lex Luthor		66%
Green Goblin		58%
Apocalypse		57%
Magneto		53%
Dark Phoenix		50%
Riddler		47%
Two-Face		46%
Mr. Freeze		44%
Venom		38%
Juggernaut		34%
Kingpin		32%
Poison Ivy		32%
Mystique		26%
Catwoman		21%

Blessed with smarts and power but burdened by vanity.

Click here to take the "Which Super Villain am I?" quiz...

Java 7 Language Features

Tim — Wed, 13 Dec 2006 23:53:00 +1100

I wanted to respond to Danny Coward's blog entry on Java 7, but his spam detection seem somewhat too rigourous, so I'm making my comments here My few thoughts:

I'm in favour of having concise property access syntax, but I'm not 100% convinced on the arrow operator. I understand the concern about having the dot operator be ambiguous, and the potential performance penalties that can occur, but I think those fears are being over played. To my thinking the cost of having two different member access operators is worse. Having bean->property and bean.getProperty() mean the same thing segments the development space. Some people will use one, and some people the other. If I'm using an IDE with content assist, then I have to know whether I'm looking for a method or a property before I start typing. If we really need to have a different syntax I'd prefer something like bean.getProperty() and bean.@property or bean.$property - something that makes it clear that the difference is in what sort of member you're accessing rather than what sort of operator you use to get it. (NB: I spent a fair bit of time playing with Sather, so I'm probably more comfortable than most people with transparent property access)
If we are going to get syntactical support for declaring property accessors, then I have 2 requests:
1. readonly
2. It should be a transparent change to clients if I need to convert that from a property accessor to a standard pair of methods (or just a getter method)
Please please please don't give XML special treatment in the language. If we've found that working with arbitrary dynamic object graphs is too difficult then find a way to support them, but please do not make it XML specific. XML is not that important. I've had multiple situations where I've wanted to dynamically access properties from object graphs - I'd love a neat syntax for it. Please don't make this a XML-only solution. As Neal likes to quote Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. (R6RS)
I know others have said this, but I'll repeat them - please make sure JAMs play nicely with OSGi bundles.

A Continuation of another

Tim — Thu, 19 Oct 2006 01:10:00 +1000

Greg has blogged about the ThrottlingFilter I wrote for Jetty. He's covered the situation quite well.

I wrote the filter (with Greg's input) based a situation that was quite similar to what he describes. There are a few other ways you can approach it though.

I've not tried it, but I believe it would be feasible to push the same logic down into the connection pool (or any other pooled resource).

Many pooling implementations (e.g. commons-pool/commons-dbcp) offer configurable behaviour when the pool is full - a common behaviour is to block as Greg describes in his blog entry. What could be useful is to be able to do lost cost waiting - i.e. continuations from within the pool.

The filter is nice in that it stops the unwanted request at the beginning of the chain, before any processing time has been wasted on it, and when the impact of retrying is quite low. The cost to that is that you need to be able to split your application by URL. The filter needs to be able to tell whether to throttle any given request.

Putting that logic into the datasource would mean that some processing would have already been performed before the request is suspended, and you would have to be confident that the application is safe to retry. However it has the advantage of being very precise - requests are only suspended when they attempt to access an exhausted pool.

I'm sure there are a lot of other possible ways to make use of continuations. The use of continuations in the ThrottlingFilter was a suggestion by Greg - I had originally intended to simply reject requests that exceeded the maximum size until he reminded me how useful continutations would be in that context. I'm sure that with a bit of imagination many other uses could also be found.

Achieving closure

Tim — Tue, 17 Oct 2006 21:13:00 +1000

Over the last week or so I've spent some time evaluating the various closure discussions that are floating about.

So, I sat down to write some code. Most of the situations where I've longed for some sort of closure syntax are in iteration contexts - searching lists, filtering lists, etc. - so my first test scenario was just that. I wanted to iterate over a list of integers, and negate each one to produce a new list. Then I wanted to iterate over that list and print out each number.

Here's the code in idiomatic Java5 syntax:

    public void sample( List<Integer> numbers )
    {
        List<Integer> inverse = new ArrayList<Integer>( numbers.size() );
        for( Integer i : numbers )
        {
            inverse.add( -i.intValue() ) ;
        }

        for( Integer i : inverse )
        {
            System.out.println(i);
        }
    }

If we define a couple of interfaces and utility methods:

    public static interface Mapper<FROM,TO>
    {
        public TO map(FROM arg);
    }

    public static interface Acceptor<FROM>
    {
        public void accept(FROM arg);
    }

    public static <FROM,TO> List<TO> map(Iterable<FROM> itr, Mapper<FROM,TO> mapper)
    {
        List<TO> result = new ArrayList<TO>();
        for( FROM el : itr )
        {
            result.add( mapper.map(el) ) ;
        }
        return result;
    }
    
    public static <FROM> void apply(Iterable<FROM> itr, Acceptor<FROM> apply)
    {
        for( FROM el : itr )
        {
            apply.accept(el);
        }
    }

Then we can write that code in Java5 with anonymous inner classes:

    public void sample( List<Integer numbers )
    {
        List<Integer> inverse = map( numbers,
            new Mapper<Integer,Integer>()
            {
                public Integer map(Integer i) { return -i.intValue() ; }
            }
        ) ;

        apply( inverse, 
            new Acceptor<Integer>()
            {
                public void accept(Integer i) { System.out.println(i); }
            }
        );
    }

I would argue that this syntax is significantly uglier, and less clear than the idiomatic java.

Here's what we can do with CICE:

    public void sample( List<Integer numbers )
    {
        List<Integer> inverse = map( numbers, Mapper<Integer,Integer>(Integer i) { return -i.intValue() ; }) ;
        apply( inverse, Acceptor<Integer>(Integer i) { System.out.println(i); });
    }

-- please correct me if I've done something wrong with these samples - none of the proposal authors provided a compiler to test with :)

The CICE example is a lot shorter than either of the Java5 examples (although that's partly due to my choice in code style), but I'm not sure that it's any more readable than the first version. One of the keys to clarity and readability is to make the important bits stand out, and in this example that doesn't really happen. Some of that is due to my choice in the parameter order, and the fact that the apply and map methods are static rather than members of Collection, but a large part of it is that there's a lot of characters that are mostly redundant to my understanding of the code. I don't care that the map method takes a Mapper<Integer,Integer> - I care that it is going to map the elements through the expression "-i.intValue()", and that is hidden at the end of the statement in amongst the noise of the interface and type parameters.

However, the CICE example is pretty easy to understand. I didn't have to keep consulting back to the spec to work out what I needed to write, and there was only 1 syntax to learn (and most of that was syntax I already knew)

My first attempt at a BGGA 0.2 example was:

    public void sample(List<Integer> numbers)
    {
        List<Integer> inverse = map( numbers, (Integer i) { new Integer(-i.intValue()) } ) ;
        apply( inverse, (Integer i) { System.out.println(i) });
    }

It's not a lot different from CICE. There's less noise, but more magic. I don't need to "return" keyword in the map example, and I don't need semicolons in either. However, within this choice of BGGA syntax, I don't think the removal of those syntactical elements has aided the readability in any meaningful way. In fact in both cases I originally had them in the code and then realised they were not needed.

I don't know whether the "new Integer(...)" is required. I suspect not, but I'm really not 100% sure. Without it, the closure would return "int" rather than "Integer" (the CICE example didn't have this confusion because I had specified the return type as a type parameter). However the BGGA refers to "an assignment conversion from the result type of T to the return type of U", which I can only hope includes auto-boxing. But is BGGA smart enough to know that it should handle map<?,?>( List<Integer> int(Integer) ) by setting the 2nd type parameter to Integer and auto-boxing the closure result? I hope so. The fact that I need to stop and think about it is a little worrying - there's enough compiler magic going on that I can't really call this example "straight forward"

BGGA allows an alternate syntax for this sample:

    public void sample(List<Integer> numbers)
    {
        List<Integer> inverse = map( Integer i : numbers) { -i.intValue() } 
        apply( Integer i: inverse ) { System.out.println(i) }
    }

That certainly reads a little more succinctly. It looks a bit like the Java5 foreach syntax, but not quite. It's concise and readable, but it's a little bit foreign.

I'm not sure which proposal I prefer. CICE was easy to write, and easy to understand, but I'm not sure it adds enough syntactical benefit to actually make the language significantly better. If we end up with CICE closures, I suspect a lot of people will keep writing code in the style of the first example. That's OK - the first example is perfectly readable - but it might be a sign that CICE doesn't give quite enough syntactical sugar. I do think CICE will provide some readability benefits for list searching/filtering though.

        List<Integer> positive = select( numbers, Predicate<Integer>(Integer i) { return i >= 0 ; }) ;

is (IMO) more readable than:

        List<Integer> positive = new ArrayList<Integer>( numbers.size() );
        for( Integer i : numbers )
        {
            if(i >= 0 ) 
            {
                positive.add( - i.intValue() ) ;
            }
        }

But the BGGA:

    List<Integer> positive = select( Integer i : numbers) { i >= 0  }

is significantly easier to read. It's clear what the code is trying to do - it's less clear (particularly to less experienced developers) how it accomplishes it.

Ultimately, I see this as an intractable problem. The goal here is to add a concise, neat and elegant syntax for closures to a language which is none of those things. Any closure proposal that meets that goal is going to look out of place in the overly-verbose, staticly-typed world of java. I want closures, I think they're an important part of any modern programming language, but there's a big risk of this turning into a case of lipstick on a pig.

BGGA ends up providing a syntax that is quite similar to the syntax provided by some other languages. The syntax really helps in writing concise, intentional code, but it doesn't really have a "java feel" to it.

Java isn't ruby. Even if we wanted to turn it into ruby, it's too late. So java needs a closure syntax that looks and feels like java. I think BGGA misses the mark on that one. But if we're going to add a closure syntax it at least needs to offer some advantage over what we currently have, and I think CICE falls down there.

Turning to some of the semantic concepts involved, I really like that fact that CICE treats everything as an implementation of a SAM. There's no new types, no new methods on Class/Object, not much new to learn. It also forces library writers to develop against interfaces rather than function types. This has 2 specific advantages that I can think of

Teams who reject the new syntax will not be prevented from using those new APIs.
It opens up some interesting possibilities to use dynamic proxies

But in the end I can't really support CICE for the use cases I've played with here. It simply doesn't improve the clarity of the code sufficiently to warrant a change to the language - even such a simple change. Perhaps when I dig into more complex uses cases its value will show through, but for simple cases, I can't see it.

Neither proposal has yet included any discussion of APIs (or new syntax) for manipulating closures. I haven't seen a nice way to perform currying in either proposal (perhaps I'm just not imaginative enough), and neither proposal seems to allow taking a reference to an existing method (either static or non-static). In my "apply" example above, I see no real reason why I had to write a new closure for System.out.println(i), that's already a void(Integer) method, why can it not be assigned to a function type? In BGGA that syntax is simple enough that the loss is quite small. In CICE that ability is missed.

I didn't need any of the complex BGGA features. No synchronized parameters. No non-local returns. No "Unreachable" types. I still question whether those features are worth adding to the language. There's a lot of complexity there for a fairly uncommon use case.

Partly it's an issue of balance: One of my other concerns with CICE is that it follows the same route the anonymous inner classes took us down the first time - add minimal changes to the language in order to cater for a particular set of use cases. I'm not sure that's what we need. We don't just need to be able to do the same things better, we need to be able to do better things. We all decided quite a long time ago that anonymous inner classes aren't enough to provide the expressiveness developer are after. What happens when we decide that CICE isn't enough either? Do we keep adding little bits of syntax until we get where we want to go? I think BGGA is going the other direction. It's adding a lot of stuff that we haven't tried before, and I don't think we (or they) truly understand the consequences. Do we really need all of that functionality now? Can we be confident that the decisions we make in our current relative ignorance will turn out to be the right ones? Perhaps it is possible to implement part of BGGA in Java 7 and then refine it after that. I'm not really sure how to approach it, but it seems like a lot to through into the language without a good feel for how it will play out.

I'll be very disappointed if Java 7 ends up having either CICE (as it currently stands) or BGGA (any version <= 0.2) because I don't think either of the proposals manages to get the balance of "java-ness", readability, expressiveness, and clarity that we need.

Side Note: I wrote all the samples in vi, and was pleasantly surprised to find I could still write java code without an IDE. I had expected to be cursing at the unnecessary verbosity of java, but it was quite manageable for the small snippets of code I was writing

Pick an action - any action

Tim — Sat, 07 Oct 2006 11:46:00 +1000

Clearly appropriate actions are better than endless talk. But are petty, knee-jerk actions better than name-calling and insults? A lesson from the Queensland government.

There's a certain level of irony in a media release titled "WOORABINDA HOUSING PROBLEMS NEED ACTION, NOT TALK" that consists almost entirely of insults and derision.

I don't think there's much more that needs to be said. It's quite depressing that Queensland funds are being used to produce such rubbish, but I guess you get what you vote for. Disclaimer: I'm in NSW, so they're not my funds or votes

Here's the press release that sparked Schwarten's tirade.

(Found from Andrew Bartlett's blog, I'm just a few days behind in my reading)

Slum Survivor

Tim — Sat, 07 Oct 2006 01:06:00 +1000

Last weekend was a long weekend over here, so myself and 9 people I'd never met set out to to build ourselves a slum...

It was called Slum Survivor, and it helped me change some of my thinking about urban and rural poverty.

For about 70 hours, we inhabited our own little slum town. 1 set of clothes, 1 water source, no showers, 2 meals a day (of rice + daal) , sleeping on wooden pallets and cardboard. That's regular life for about 1 billion people - 1 person in 6 - on this planet. We did it for a few days and then got to go home, but 80,000 people live permanently in a garbage dump in Manila.

The UN estimates that by 2030, 2 billion people will be living in slums. That's 100 times the population of Australia. And today, as I write this, for every man, woman and child in Australia there are 50 people in the world without access to clean drinking water. 3,900 children every day, due to lack of clean drinking water and sanitation.

Before Slum Survivor those were just numbers to me, but after a few days of having to live in our little slum, it means a heck of a lot more to me now.