I am personally convinced that invokedynamic (the new BA op-code for Java 7) is not just for dynamic language support. Patterns like the one in this post _will_ let people develop dynamic approaches to Java. This will effect aspect oriented programming, all reflection based system and so on. I can see applications in server environments where objects/beans etc can use invokedynamic to tight bind initially loosely associated business logic.

In short - I believe invokedynamic is a game changer for Java and everything that interoprates with or competes with Java.

totally agree!

You mean - when you linked it! I seem to remember writing it myself.

Thanks - but it really is not that complex. You cannot define the state of two distant points simultaneously when the speed of information transfer in space/time is finite. So all transactions collapse to being controlled from one point, not distributed. The reality of distributed transactions is that they make fail over to the single transactional arbitrator less common; but the need for that single arbitration point never goes away.

Just ask a question and I am happy to take a look. I found this an interesting area because the approach 'under the hood' seems a bit 'hacky' but it does work. Java generics are even more strange... http://nerds-central.blogspot.com/2011/04/java-type-erasure-...

Billions of lines of COBOL will 10s or even 100s of millions of lines written every year. Each time someone makes a mobile phone call, uses a credit card, books an airline ticket - 99% chance COBOL will handle part of that transaction.

That is the sort of thing COBOL does well :)

The point is that there is a lot of COBOL already out there, so someone has to maintained it and add to it. What is more, C# is not a perfect language for business its self, neither is Ruby. With good tooling the difference are small. Actually, in my case I would never recommend using Ruby for a commercial project - but that is another discussion for another time :)

There's been a lot of ruby code written on commercial projects, I think the developers (and customers) would disagree with that.

I also think you're way off on the amount of difference between C# and COBOL. The fact that COBOL requires good tooling to be usable is telling in and of itself.

How is Clipper doing these days? COBOL is making a resurgence as people realise it works!

I love that site. They way it flickers and has screen burn effects are so kitch :)