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:( )