New language this year

There has been discussions going on the pragprog about which languages will you learn in new year, some mentioned the languages that I never heard about. I think I'll learn ruby or groovy and C# 3.0. I've heard that C#3.0 has some cool features which deserves attention. Ruby seems to be hyped too much these days, not that its bad, but it certainly is being re-branded like no other language ever! Ruby is around since many years, but the Rails put it in the news, anyway, I tried ruby online and i found it cool, it has lot of utility classes which can be quite productive.

Reuse Pain in Eclipse UI Code

Code Reuse is one of the most interesting, if not alluring, part when you are contributing to Eclipse. In eclipse, many a times I'm tempted to use code of other plugins. Eclipse guys like to keep UI-code 'internal' , still, I try and again to reuse, which ends up in "monkey see/monkey copy+paste" with added disarrays.

This temptation is not just because of my indolence to duplicate development cycles but something which is commonly done (it's all about reuse right?), ofcourse at very clear granular leves (called extensions) which, I, somehow find limiting.

It is too frustrating to figure out sheer context information for some code deep in eclipse dungeons, the more you read code, deeper it takes (and ofcourse how can the temptation of what is inside be controlled?). This results in a tempest of hazardous shortcuts which keeps you away from starting afresh or thinking in different way and you end up in violent mess of yellow signs and incomprehensive code !

Recently one of my collegue ran in similar situation, I looked in to it to see how serious it can get, I too quicky drawn in it. The task involved implementation of preference pages for code/comments etc. in our code generation templates, as well as templates for ADDL( home grown action semantics language). We started looking into JDT UI, which has a preference page with similar functionality named "CodeTemplatePreferencePage" which delegates UI to CodeTemplateBlock which in turn owns inner classes to do "real" stuff. There are hardly any hooks where it can be extended "as is". We started with extending it and ended in copy pasting somewhere around 6-7 java files (and contrived satisfaction that it was looking good to end-user).

It just didn't helped! we finally created UI using Eclipse Visual Editor and programmed widgets/viewers and preferences in less than one forth the time we spent in reading and fumbling in JDT-UI code.

Lessons learned after hours of pairing, never try to reuse what is "internal" and don't ignore it no matter how tantalizing it is!

Some Lost+Found gyan from JMM :)

Findings from an article by Goetz:

“While the JMM specified in chapter 17 of the Java Language Specification was an ambitious attempt to define a consistent, cross-platform memory model, it had some subtle but significant failings. The semantics of synchronized and volatile were quite confusing….

...JSR 133, chartered to fix the JMM...

Most programmers know that the synchronized keyword enforces a mutex (mutual exclusion) …. But synchronization also has another aspect: It enforces certain memory visibility rules as specified by the JMM. It ensures that caches are flushed when exiting a synchronized block and invalidated when entering one, (significant performance degradation on multiprocessors) so that a …. It also ensures that the compiler does not move instructions from inside a synchronized block to outside…. The JMM does not make this guarantee in the absence of synchronization -- which is why synchronization (or its younger sibling, volatile) must be used whenever multiple threads are accessing the same variables.”

I’m not sure if this cache flush is entire cache flush (128k to 2m) or cache-line flushes, but i consider it really bad. All operations are stalled until memory request is complete.

I never knew this behavior of “synchronized”. I always wondered about the bad performance of concurrency primitives, some facts like these makes my understanding clearer, why it's not scalable,

This will give one certain idea of how painful it is to achieve "Platform Independence", apart from being the buzzword.

(and who likes snoopy cache being flushed like dumb one:( )

Story of a Decoupled Visitor

I find visitor pattern mesmerizing. Master Uncle Bob has published great articles on visitor family of patterns (Acyclic Visitor, Visitor Family of Design Patterns) apart from others.

In his articles he illustrates how visitor can be applied to prevent interface bloating by introducing visitation support in the domain model (The Modem Hierarchy in the article) and how easy is to introduce new visitation based behavior without modifying the hierarchy.

So far so good, this approach works for the developments where you have the luxury of initial design. You may add support for visitation based traversal in the domain model or the layer extending it, or your hierarchy code generator, say antlr or JavaCC, may generate cool visitor based code so that its easy for you to compute metrics or do other stuff on the model (any sophisticated AST is a Model, I'll prefer calling class hierarchies a Model here).

Imagine we have a model wherein visitor is disliked alien (ayee! ugly! visitor is an implementation detail, not needed in my platform independent model!!!), in short, I've a "pure" domain model. But our model composition is so complex that normal iteration isn't going to give us big advantages, and we need extensibility as well.

I have faced similar design problem back when I was developing a intra-model transformation framework, where, the model was predefined without visitor supported api. During transformation, every now and then an element search from model was becoming inevitable, every searcher wanted to do something interesting and unique. For example, Let's say I want to find an element from source model and do a shallow copy of it and add it to target model and so on. I tried to fit visitor for this design problem, I wanted the extensibility without bloating the existing model.

I can't add the visitation API in the given model, but I can always create a utility (or add api to context object) which accepts model and visitor and does a generic traversal (as in loop based or recursive) as shown in the diagram figure.

Context holds the actual model and defines utility api to invoke visitor implementation. Leaving other details, each client (*ModemDiagnostic in this example) can create an implementation of Visitor and visit the hierarchy. Context might end up doing a list based iteration for full scan of the model which can be controlled from the visitor. This variant double dispatches for each model item but is totally decoupled from the domain model (there u go, greetings!!).

I've used this pattern repeatedly (BluePrint Foundry Transformation Framework, FileSytem Utilities) but I can't tell it a "regular visitor" or acyclic visitor, but I'll call it a Decoupled Visitor. Its easy to identify that design solution offered by this approach can be replace by iteration and template methods and inheritance, but then there's trade-off between inheritance and composition ans so is the story.

Blogging Inspiration

Posting after a long-long time, it's more than a year that I wrote something on technology, hardly got time for it.

While i read blogs of my Gurus regularly, it never gave me motivation to write one of my own, not that it's boring, but the tooling is not cool enough, and regular mailing list and private yahoo groups served the purpose.

I like expressing tech. thoughts on corporate-mails and groups, but then, they have different reasons as well, while blogging exists for that only. took a time to realize this trivial fact. Although, blogging not being one of the fascinating thing to do.

I hope to write some cool and interesting posts on Java/Relavant Technologies.

Thanks to a friend who inadvertently inspired me to restart writing on it.

Happy reading.