Synthetic bridge method annotations

Update regarding "walls and bridges": Sun has kindly opened an enhancement request on my behalf for the issue. Please vote if you are affected by it too.

Java properties links

Since I am trying to keep up to date with what's going on in "Java Properties" land, I started with Alex Miller's collection and have been adding things that I find either relevant or influential. Another idea I nicked from Alex was to put them on Tumblog.

A disclaimer: this is a personal collection, so if something looks irrelevant, it means that I think it is influential :-)

I'll be more than glad to hear suggestions for more links or feeds.

My OO My

No, I don't mean the song, but it's to do with Scandinavia. Mads Torgersen mentioned this during interview with Joe Armstrong (highly recommended, there is also a part II), and later I saw another reference in a paper: apparently there is "Scandinavian school of object orientation", sometimes compared to "American school".

Here are some insights on the difference between the two. The point is that the former is about concepts and philosophy, and the latter is about pragmatic aspects like software reuse and organization. I am not gonna pretend that I'm smart - all I know about it comes from searching Google, so you can go there and find out for yourself.

* On a side note, since I am linking to MSDN here, I want to say that even though my last post wasn't very favorable to Microsoft, to be fair - the company plays an important role in renaissance and democratization of functional programming (LINQ, F#, etc.), with guys like Mads Torgersen and Erik Meijer largely responsible.

Open the source, sesame

About a month ago a big shot from Microsoft came to speak at the university - looks like he's on some kind of a tour, and his mission is to convince universities to teach Windows operating system aside Unix/Linux. He waved at the audience with a free license and tried very hard to prove that some aspects of Windows design are better than Unix, mainly because it is "newer" design and better suited for nowadays computers.

Long story short, one of the things he said, was that open source is bad, because engineer who looks at the source of a library will design his application assuming particular implementation, which is now tightly coupled to library internals - bad. Obviously a discussion erupted - design by contract and Eiffel were thrown in the air, relation between programming language and operating systems..., but frankly all I could think of is my distant past as a VB developer and those 1000 pages "Windows *** Unleashed" books. They were written by hackers who used trial-and-error against Windows DLLs trying to make some sense of the APIs - the formal documentation was either sloppy or intentionally incorrect to misguide us, Windows application creators outside Microsoft, since we were potential competitors. Things were so different when I moved to Java. (Though my first Swing experience made me - believe it or not - miss VB, but that's another story.)

Anyway, statement like this coming out of the mouth of a Microsoft employee, even if he has an impressive Unix record, was easy for me to dismiss. But here is a respected Smalltalker saying

"I think people should have the source ...not to get miss quoted saying I'm against open source, but I think it's important class libraries should be viewed like caves."

(Ah, wait, he is from IBM - he can be ignored too... just kidding)

I mean, seriously look at this puzzler for example - it's pretty cool, but the solution heavily relies on a particular implementation, I would even say this is actually a hack. And sometimes a hack is necessary... or is it? Is there or will there ever be a perfect environment where we can program without hacking?

P.S. The reference to Ali Baba tale in the title is intentional. Open source is good, very good, it's a treasure and in the world dominated by large corporations - almost a miracle. But IMO we should resist the temptation to exploit it to the last bit, because we might find ourselves locked in the cave.

Static methods as function objects

In one of the earlier posts I described a policy object created by "functional style programming" in Java. The basic idea is to make methods into Function and Predicate objects and then composite the logic from these building blocks. The problem though was that the policy implementation looked alien to Java. To re-cap: I wanted to invoke a different function based on the class of the object - classical multi-dispatch with a single argument.

So inspired by extension methods idea I added a new mechanism to define properties (and functions in general) - via static methods. You define a bunch of static methods with the same name (or appropriately annotated) like this:

static int size(Collection c) {
 return c.size();
}
static int size(Map map) {
 return map.size();
}
static int size(Object obj) {
 return (obj.getClass().isArray() ?
   Array.getLength(obj) : 1);
}

Now assuming I have a property declaration

Property<Object,Integer> size =
 new Property<Object,Integer>(0) {};

The underlying implementation of the size.of(object) would be a "policy" (composite function) dispatching to one of the static methods according to run-time type of the object. So that size.of("foo") is 1, size.of(Arrays.asList("a","b","c")) is 3 and size.of(null) is 0.

There are couple of issues though.

Issue #1: automatically ordering the rules. Now when rules are not added manually, I should be careful to test for more specific class first. The solution is to calculate a distance between two classes and always look for a best match - basically same algorithm javac uses when choosing methods at compile-time. This isn't fully unambiguous though: if class C implements 2 interfaces A and B, having different implementations of size(A) and size(B) would put me into a dilemma which one to choose for size(C). Javac in such a case reports an error - thanks to Java being statically typed. But once I make it a run-time decision the only logical solution is to report an error at run-time. To make the problem less acute, I could add an annotation that controls ordering of the methods.

Issue #2: this is less generic than a general predicate-based policy - it is limited to "instanceof" predicate. One of the policies I use internally in the properties project is reflectively invoke getFoo() if the class has a "getFoo" method. This isn't possible with static methods.

Issue #3: reflection. It's not really a problem, but rather an enhancement I want to make: instead of using reflection I could generate the functions at compile-time with APT, like Bruce Chapman does here. This is one of my next adventures, which I will hopefully describe in a future post.

Digg a pony

Here is another post with no helpful information, sorry, I meant to write a meaningful piece but I am on vacation and in fun spirits :-)

Anyway, I just got reminded of something that crossed my mind before and is now more relevant than ever - the term John Lennon invented almost 40 years ago: "bagism". It's amazing that at the time everybody laughed - a person giving an interview in a bag. You can look this up, or even better watch the video (fast-forward about 2 and a half minutes). Here's a short re-cap:

"if everybody had to go in a bag for a job (interview) there would be no prejudice, you see, you'd have to judge people on their quality within, you know, we call it total communication..."

I think this is really the web: blogging, mash-ups, syndications, and social networks, and why all this is a lot of fun - you really know nothing about the one you are talking to, except what he (she? it?) tells you.

Dig a pony lyrics mention

"penetrate any place you go" (...internet?...)
"radiate everything you are" (...wireless?...)
"imitate everyone you know" (...blogging? syndication?...)
"indicate everything you see" (...search? google?...)
"syndicate any boat you row" (...social networks?...)

Cheers to total communication!

P.S. A tribute to Passover holiday (the reason for my vacation): there were once four boys (ארבעה בנים) - the wise and wicked one, the cute one, the quite one, and the one that can't sing... and they were fab.

Java and closures

My reaction to the likely postponing of closures till Java 8.