OSGi in the Enterprise

A new site for OSGi enterprise users (not just members of the OSGi Alliance) appeared the other day. More background on EclipseZone.

The art of OSGi programming

Neil Bartlett recently published the first of a series of EclipseZone articles on OSGi programming.

Since most OSGi users I've talked to are implementers of the bowels of Eclipse, I'll enjoy seeing how Neil uses OSGi.

If you don't use Eclipse, don't be put off. Implementing and running the bundles in these articles will require only an editor and a command line shell (or two).

Nuxeo EP based on OSGi

The recent announcement of Nuxeo Enterprise Platform v5 on Freshmeat hinted that they had adopted an Eclipse-like extension mechanism based on OSGi. The Nuxeo homepage made me wonder if this was just buzzword compliance. But it seems not.

Eric Barroca's blog describes the use of OSGi in a little more detail. Nuxeo exploits OSGi when it is available and mimics it otherwise. I wonder why they didn't bundle an existing OSGi framework?

It'll be interesting to see whether JBoss decides to bundle an existing framework...

Java 7 Content

There's increasing interest in what might go into Java 7. The spec. lead has given some hints in his blog and a recent presentation.

However, Alex Miller's Java 7 page seems to be the definitive collection of candidate items.

I'm particularly interested in:

• JSR 277 Java Module System
• Java kernel
• BigDecimal syntax improvements
• JSR 203 in relation to async. I/O and UNIX file permissions.

Knopflerfish OSGi tutorial

Thanks to some Australian OSGi users for providing a nice link to a Knopflerfish OSGi tutorial.

My example of how to create an OSGi bundle in under 10 minutes still takes some beating for simplicity (or triviality, if you prefer), but I do believe in giving beginners a really easy way in. If they're smart, they'll soon catch on.

Osxa OSGi

Pierro's excellent summary of open source OSGi implementations includes the three long-standing projects, but also mentions Osxa.

Osxa seems to have started recently given its relative incompleteness and also the state of its web site. If you know about the objectives of Osxa, I'd love to hear from you.

BigDecimal operator support in Java 7

One of the candidate items for Java 7 helpfully listed by Alex Miller is BigDecimal operator support. I'm keen to see this go in as it would really help customers who use decimals.

Mike Cowlishaw's General Decimal Arithmetic page is a rich source of information on this subject. It contains an example 'telco' benchmark coded in Java and C# which provide a helpful comparison when thinking about syntax support for BigDecimal.

Take the following sequence (massaged a little for display here) from the Java version:

  b = p.multiply(basetax);
  b = b.setScale(2, BigDecimal.ROUND_DOWN);
  sumB = sumB.add(b);
  t = p.add(b);

  if (calltype != 0) {
    d = p.multiply(disttax);
    d = d.setScale(2, BigDecimal.ROUND_DOWN);
    sumD = sumD.add(d);
    t = t.add(d);
  }

and compare the C# version for readability:

  b = p * basetax * 100;
  b = Decimal.Truncate(b) / 100;
  sumB = sumB + b;
  t = p + b;

  if (calltype != 0) {
    d = p * disttax * 100;
    d = Decimal.Truncate(d) / 100;
    sumD = sumD + d;
    t = t + d;
  }

Enough said?

OSGi Enterprise Expert Group Kick-Off

I'm grateful to Eric Newcomer for an encouraging summary of the recent OSGi Enterprise Expert Group kick-off meeting. I toyed with going and decided my attendance wasn't essential. But it certainly sounded like a lot of fun.

JRockit-powered Harmony

Excellent news! BEA have made available a binary version of the JRockit VM for use with the Apache Harmony class libraries. See their post on harmony-dev.

As Geir notes, Harmony now has two decent VMs to choose from. Anyone planning to hack Hotspot to run with Harmony?

Vista - the "Pain" starts now

Good to know Microsoft are ahead of the game. They shipped the first, and hopefully the last, critical security update a good two weeks ahead of yesterday's worldwide release of Vista.

Good job they rewrote the code from the ground up...

Writing partial designs

I recently kicked off a piece of development work and then handed over leadership of the small team to someone else. The new leader is keen and thorough, but I don't think I've really persuaded the rest of the team of the value of writing down partial, incomplete designs.

The developers in the team seem to have the impression that doing design involves solving all the problems and then writing up a solution. But it's much better, as I've mentioned before, to use a design document as a work in progress which records the solution so far and has placeholders for all the known problems. Such a 'live' document can be shared with other people and used to stimulate new ideas and solutions.

Rock climbing provides a good analogy. A team can climb up a rock face without pausing to bang in pegs. But then one person's achievement in reaching a particular point of the climb can't be shared by those following behind. Also the effects of a fall can be catastrophic.



In a similar way, writing down partial designs enables a team to build on each other's progress. If a major design problem turns up, it is often possible to reconstruct a solution from the remains.

This sharing of design information can be done verbally, but this lacks the precision of a written document and doesn't force out so many issues.

What's the point of JSR 291?

It seemed time to re-iterate the reasoning behind JSR 291. For example, Sun's recent voting comment showed they apparently still don't understand what the JSR's there for.

Adoption
There's a ton¹ of software already built on top of OSGi and it keeps increasing. Since this is mostly Java code, the JCP ought to take notice, and sooner rather than later.

Familiarity
As Sun point out, the specification and its expert group already exist thanks to the OSGi Alliance, so what could standardisation in the JCP possibly add?

Well, there are benefits to the JCP and to OSGi. The Java community gets access to the specification, RI, and TCK in the familiar, JCP-standard way. OSGi gets another source of requirements, continuing its tradition of engaging with current and potential users.

Compatibility with Java ME
JSR 232 does a similar job to JSR 291, but for Java ME. Having a consistent, compatible dynamic component system across Java SE and Java ME is a no-brainer.

Footnote:
1. Although good project managers use KLOCs only in joking terms these days, no better metric has gained universal acceptance. The 'ton' is a strong contender as it refers to the mass of software, rather than its volume. 'kiloton' and 'megaton' are useful for larger software projects, especially in the defence sector.

Work-life balance

In a recent IBM telecon, a senior manager mentioned that a 60 hour week felt about right for her. This was in the context of a discussion about work-life balance among the more senior techies in her organisation. There was no implication that everyone should work those kind of hours, although I guess a fair number of those on the call do.

A few days ago I heard a speaker on technical leadership say that no-one should expect to become a senior technical leader by working a 37 hour week.

But a 37 hour week feels about right for me. Maybe the promotion process is broken because it doesn't take into account working hours. I don't think so. Results are what counts rather than being physically present. And, of course, no-one should expect to be promoted unless they produce results.

I used to work longer hours and I know this makes me ineffective. I lose most of my creative spark. You know the kind of thing: you're struggling with a seemingly intractable problem and then a solution pops into your head when you're thinking about something else (or not thinking about anything in particular). The trick seems to be to load the problem up in your brain and, if you can't make progress, switch to doing something completely different, like going home or taking some exercise.

Some people can work long hours and still be creative. Others seem to enjoy spending most of their waking hours at work. Each to his or her own, but the crucial thing is to make a choice that you won't regret later, which I hope I've done.

Is full interoperation realistic?

Wouldn't it be useful if applications could communicate over a network using a standard message format and protocol? Wouldn't this solve a lot of real-world problems, especially if the whole thing could be kept simple?

Sure, but before long you'd have to address the 'full interoperation' requirements: distributed transactions (so application programmers don't spend most of their time writing error handling logic), security (for sensitive data), a directory server (so distributed applications can find each other; ideally secure and transactional), load balancing, distributed debugging, etc.

And since real world systems don't all run on a single vendor's hardware or software, most of these features would need standardising so applications running in different environments could communicate with each other.

Now if the probability of each feature interoperating correctly was, say, 99.9% and there were, say, six features, then the probability of all six features interoperating correctly would only be about 99.4% (0.999⁶).

You'd end up with a system that would be much more complex than was originally envisaged and the interoperation wouldn't be great.

But, hey, what if you stepped back and came up with a standard message format and protocol so that applications could communicate over a network? Wouldn't this solve a lot of real-world problems, especially if the whole thing could be kept simple? Indeed it would ... if.

Many vendors are following the full interop. model with the likes of CORBA (e.g. via Java EE) and SOAP. Others, notably Microsoft, support full interop. but would much prefer a homogeneous (software) network also viewed as 'single vendor lock in' (or world domination).

I don't think there's a perfect, multi-vendor solution, desirable as this would be. The most flexible approaches that I've seen work in practice are distributed systems consisting of homogeneous 'islands' loosely connected with relatively simple protocols (such as MQ Series messaging, IIOP, or vanilla SOAP).

JSR 291 and weird stuff

Google's blog search is cool, but it sometimes turns up weird stuff. Take ocean's recent thinking on the curse of specifications in general and JSR 291 in particular.

Actually 'thinking' may be an exaggeration, but the blog does raise some questions:

1. Why does it link back to the JSR review ballot of March 2006? Things have moved on.
2. If specifications are so divisive, are there any non-divisive alternatives?
3. Is rolling your own module system from class loaders really better than using an existing module system that others have taken the time to hone? Presumably ocean codes in assembler on principle.

But I should lighten up, as our American cousins are fond of saying, ignore the weird stuff, and enjoy the blog's link to WS-DeathStar.

IBM Java 6 /.'d

A post on Slashdot about the early release of IBM's Java 6 is generating some interesting discussion. But, from the wording, I don't think IndioMan has ever worn a blue suit. ;-)

JSR 291 passes public review ballot

In the last hour, JSR 291 passed its Public Review ballot with 9 "yes" votes, 2 "no" votes, 1 abstention, and 4 non voters (including Google and Red Hat who voted "no" in the initial JSR approval ballot). Details here.

Is hyper-threading hot stuff?

My home machine recently exceeded the processor temperature threshold when one of my sons was thrashing the CPU with a game. I tried various things like hoovering out the dust and increasing the fan speed, to no avail.

But disabling hyper-threading in the BIOS did the trick, with no perceptable decrease in performance. I was expecting Windows startup to be slower, but I guess it's mainly gated by disk access.

An old ZDNet article claimed that hyper-threading "increases power consumption and thus heat dissipation" which fits my experience.

I could try forcing the game to use a single logical processor, but why bother as I don't seem to need hyper-threading anyway?

Silly Java rules?

Kevin Barnes observes that some pretty silly rules have developed around the use of Java.

I should declare my interest at this point: I work on Java standards and IBM's Java runtimes. That said, I think some rules of thumb are useful for beginners provided that skilled programmers break the rules as necessary.

I dislike classes with numerous getter and setter methods as this is a pretty strong hint that a class is badly designed, or that the programmer would have preferred a C struct ;-). Some consider these methods inherently evil, but I wouldn't go that far.

The use of final is more interesting. In C++, const is useful in defining good interfaces and final may play a similar role in Java. But the use of final on local declarations doesn't seem to be worth the syntactic clutter.

One of the proponents (thanks for the link, Kevin) of the use of final seems more concerned about controlling subclassing. That's a more interesting point to argue as it comes back to good interface design. But I don't think there's a general rule - it depends on the circumstances. Anyone designing a Java interface needs to understand the trade-off.

Since Java enshrines 'non-final' as the default (and it's too late to change that!), beginners risk coding Java interfaces that will behave unexpectedly when subclassed. But changing the language default wouldn't enable beginners to design good interfaces. As they say "there's no substitute for understanding".

Scrapping designs

When should you start writing down a design of a piece of software?

Some programmers put this off as long as possible. Once you commit yourself to paper, you start to become locked in to a particular direction. The more you write, the more you become wedded to a particular approach.

Others might advise skipping the design stage and getting on with coding. But the design lock in is even stronger once you have a swathe of code and a decent test suite. Refactoring is fun in small doses, but you'd have to be a masochist to want to spend a lot of time on it.

On the other hand, until I start writing down and organising my thoughts, I can't flush out most of the issues. Putting ideas on 'paper' forces me to define terms and helps me notice inconsistencies and omissions. Maybe I'm just a frustrated mathematician who can't solve a problem without a pencil in my hand?

No, seriously, writing a design down can be really helpful. Once you've done it, you can let the document go 'cold' for a while and then come back to it with a critical eye. It's hard to be objective when ideas are confined to your head. Also, dumping issues in a document helps me stop worrying about them - especially important when I'm trying to sleep.

The best compromise seems to be to start writing things down fairly early but to scrap a design and start again to free yourself from 'lock in'. If you use a decent version control system, you can always retrieve deleted versions.