CodeFeed

I haven’t blogged for ages for a few reasons. Mainly I have been working on some new developments at Cortex and not a lot of time to spare for other things.

This project is a J2EE project and surprisingly it is actually a long while since I really had a lot to do with a J2EE system. I’ve been doing lots of other systems around J2EE systems. Anyway, this is an EJB based system. I don’t really mind EJBs. They do have lots of issues but I understand those and overall they work OK for me. One thing for sure is that the advent of usable CMP and xdoclet cut down the amount of boring boilerplate code you need to produce.

I modified a few of the xdoclet templates in the area of value objects to suit my preferences. I can now mark some properties as readonly so they still appear in the value object but are not rewritten when the value object is set. Also, rather than aggregating related value objects, I can choose to just aggregate their primary keys. I find that often that is all I need.

Modifying xdoclet templates is a bit hairy but not impossible. The XML templating is a little cumbersome but the results are effective. I shouldn’t complain, xdoclet is writing more code than I am.

For the webapp famework, I am using a few OpenSymphony technologies. WebWork2/XWork is working out well. I’ve found a few bugs most of which I have worked around. OSUser provides a nice and simple method of defining users and groups. Finally we are using Sitemesh to add a lot of common UI stuff to the pages. I have to say that Sitemesh really rocks. It means that I can ignore most of the HTML fiddling on most of my pages.

I’m having fun getting back into J2EE development. It really has come a long way since we started at Cortex with Weblogic 4.5.1

A while ago Duncan published a Blog entry quoting somebody saying that in Ant we’d forgotten some old Unix lessons such as the stringing together of simple filter operations in pipes. I can’t find the entry now since Duncan has rebuilt his blog on a new server. At the time I had a quick think about it and was not sure how we could provide the concept of a pipe in Ant. I didn’t get very far and let it go. Nevertheless, that thought has been jangling around in my head since then.

I recently saw a bug report in Ant about sorting the output of <echoproperties>. The normal approach would be to bung in a new attribute to control sorting of the output and just do that. But that does not make the functionality available to other Ant tasks. The idea of a pipe appealed

So, I wonder if a pipe could be created, something like this

<pipe>
  <echoproperties/>
  <sort/>
</pipe>

The pipe would route the log output of one task to an input method on the subsequent task for additional processing. Anyway, I’m at something of a low ebb right now and not in the mood to code so I thought I’d throw these thoughts out there for some feedback.

Matt and I were talking this week about whether ++ is an atomic operation in Java.. He’s written it up in his Blog so I thought I would add my 2c here. I hadn’t really thought about it before and my initial reaction was to think it would be implemented with an iinc bytecode instruction. As Matt points out that’s only true for local variables for which atomicity isn’t a big deal.

Nevertheless, I had to take exception with a statement in Bruce Eckel’s original article:

“… and if you’re coming from C++ or some other low-level background, you would expect the increment to be an atomic operation, because increment is usually implemented as a microprocessor instruction”

C/C++ don’t really address thread interactions and the above statement is certainly not true on a RISC processor. It is just as prone as the Java code to thread interactions. I guess Bruce was thinking in CISC. It certainly is a single instruction on a x86 CISC processor but even there that could fail on a multiprocessor system.

So, lock up your variables …