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.

JSR 291 public review ballot

The Public Review of JSR 291 lasts just a few more days and the Executive Committee ballot starts today.

The JSR review ballot, just under year ago, passed with eleven EC members in favour, four against, and one abstaining, so it will be interesting to see if any positions have shifted.

Red Hat have recently joined the Expert Group because of the interest of JBoss (a division of Red Hat) in using OSGi, so I'm hoping Red Hat are now comfortable with the rationale for the JSR and will vote in favour.

Some EC members were worried that the JSR would be a rubber-stamping exercise, but since the Expert Group have raised a number of requirements which resulted in spec. changes, these fears should have been allayed.

Harmful distractions

Matthew Stibbe discussed distraction-free text editors from an author's perspective. Geir Magnusson made a similar point about WriteRoom. Windows users have DarkRoom. But, heck, anyone can set their IM to 'busy' and maximise the window of their favourite editor.

The point is: writers are easily distracted. Anything in their field of view is likely to entice them away from the task of writing. The same is true for software developers. Coding is sufficiently addictive for this not to be an issue, but writing specifications or other design documents is like any other kind of writing, with many of the same pit-falls.

A more insidious source of distractions is multi-tasking. Supposed scientific studies that show interruptions are worse for IQ than smoking dope or coding in VB need taking with a pinch of salt, but I know the effect rapid multi-tasking has on me (and it's not good).

So, in 2007, I plan to use my time more effectively. I already block out two days per week in my calendar to avoid 'death by meetings'. But I need to set aside chunks of time for important work and try to resist the temptation to check email, etc. every few minutes. And maybe setting my IM to 'busy' and maximising the current window will help.

Creating an OSGi bundle

Newcomers to OSGi may like a simple guide to developing a bundle. Peter Kriens has provided an extensive tutorial (December 2008: currently offline pending an overhaul) which is a must for anyone serious about learning OSGi. However, it has a long introduction and assumes you are happy to run Eclipse. So I thought I would provide a trival example that people could get going using only a Java SDK and their favourite text editor.

Here are instructions to create and run a trivial bundle, hopefully in about 10 minutes.

1. Download an OSGi framework (I used Equinox v3.2.1).

2. Paste the following code into the file org/foo/example/Example.java:

package org.foo.example;

import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;

public class Example implements BundleActivator {
public void start(BundleContext bc) {
System.out.println("Hello world");
}
public void stop(BundleContext bc) {
System.out.println("Goodbye world");  
}
}

3. Compile the code:

> javac -cp org.eclipse.osgi_3.2.1.R32x_v20060919.jar org/foo/example/Example.java

4. Paste the following bundle manifest into the file MANIFEST.MF:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.foo.example.Example
Bundle-Version: 1
Bundle-Activator: org.foo.example.Example
Import-Package: org.osgi.framework;version="1.3.0"

Make sure you have a carriage return and/or newline character at the end of the last line as this is required (see manifest specification in the JAR specification).

5. Package the manifest and code into a bundle:

> jar cvfm example.jar MANIFEST.MF org

Note that the order of the flags is important - the f and m options need to appear in the same order as the jar file and manifest file parameters.

6. Run the resultant bundle example.jar interactively using the Equinox console, e.g.:

> java -jar org.eclipse.osgi_3.2.1.R32x_v20060919.jar -console

osgi> install file:///osgi/blog/example/example.jar
Bundle id is 6

osgi> start 6
Hello world

osgi> stop 6
Goodbye world

osgi> close

(close exits the framework).

That's it! Anyone care to comment how long it took them?

OSGi non-assert agreements

In a comment on Niclas Hedman's blog, Dalibor Topic wrote:

What weirds me out about OSGi is the licensing of the real specs:

"You are not authorized to create any derivative work of the Specification. The OSGi Alliance also grants you a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, limited license (without the right to sublicense) under any applicable copyrights, to create and/or distribute an implementation of the Specification that: (i) fully implements the Specification including all its required interfaces and functionality; (ii) does not modify, subset, superset or otherwise extend the OSGi Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the OSGi Name Space other than those required and authorized by the Specification. An implementation that does not satisfy limitations (i)-(ii) is not considered an implementation of the Specification, does not receive the benefits of this license, and must not be described as an implementation of the Specification. An implementation of the Specification must not claim to be a compliant implementation of the Specification unless it passes the OSGi Alliance Compliance Tests for the Specification in accordance with OSGi Alliance processes."

The silly talk about subsetting in that license makes Equinox, Felix and all the other OSGi implementations developed open to patent attacks from OSGi patent holders, since they are naturally going to be subsets until they implement whatever the current full specification is.

Are those compliance tests freely available somewhere, so that re-distributors can limit their liability to being attacked via software patents on OSGi, by checking which implementations actually conform to the tests?

His fears should be addressed, at least for OSGi R4, by OSGi's non-assert agreements which provide royalty free access to patents for implementers of OSGi. Implementations, in this sense, do not need to pass the TCK, although they must be "intended to accurately implement the normative portions of [the OSGi R4] specification (subject to normal, inadvertent programming errors)" and must not "intentionally introduce incompatibilities that hinder interoperability".

Implementers that want to claim OSGi compliance may obtain the OSGi R4 TCK in three ways:

• Pay to join the OSGi Alliance.


• Pay for the TCK as part of JSR 232.


• I believe the JSR 232 TCK is available at no cost to qualifying open source projects and not-for-profit organisations.

I expect the same to be true of the OSGi R4 V4.1 TCK for JSR 291.

Application servers based on OSGi

An increasing number of Java application servers are being based on OSGi along the lines shown in the figure. An OSGi framework provides a runtime environment for the application server's modules. As the application server initialises, its modules are started and can communicate between themselves either using services or by importing classes from each other.

Applications running inside container modules provided by the application server need not be aware of the OSGi framework. This provides a low-cost migration path for existing applications.

The following application servers are based on OSGi, or are thinking about it:

• IBM WebSphere Application Server
• BEA microService Architecture
• JOnAS 5 (being developed)
• JBoss (being discussed)

I've heard of some others but couldn't find reasonable links.

Modularity in proprietary and open source projects

In successful proprietary software projects components are carefully owned and managed. A component owner’s perspective is that there is a set of responsibilities which are the remit of that component and no other. So the owner takes care to encapsulate the data and function of the component. Ideally, and to a large extent in practice, when a new requirement needs to be satisfied, component owners negotiate and divide up the responsibilities necessary to satisfy the requirement. Responsibilities are assigned according to the remit of each component, although these remits may be extended or refined over time.

Accessing another component’s implementation detail is frowned upon and known to impact reliability, serviceability, and maintainability. Since each component’s objectives are ultimately subservient to those of the project, component owners try hard to hide implementation detail from other components. In particular, component owners are motivated to reduce the cost of servicing old releases.

The motivation of developers on open source projects is markedly different. Of course, they too are concerned to deliver components with useful function which are in themselves reliable and which can be evolved in the future. However, they have limited resources and each component has a potentially large set of users who will not necessarily agree about the precise remit or objectives of a component. So it is in the interest of an open source project to keep components sufficiently open that they may be extended by other projects to produce variants.

A common experience in open source is that, as soon as some implementation detail is in any way declared ‘private’, a developer from a related project will complain and argue persuasively why they need special access to the implementation detail. Since there is no overriding set of objectives and open source projects are not responsible for each other’s code, the path of least resistance is usually taken and the ‘private’ declaration is removed. If the implementation detail later changes and projects depending on that detail are impacted, then no blame is attached to the project that made the change. The attitude is that the other project got what it deserved. The onus is therefore on ‘consumers’ from other projects to select the type of dependencies they wish to create and to manage these dependencies appropriately.

The Eclipse open source project faced similar resistance to declaring implementation details private. So they added an Eclipse-specific convention of using a ‘x-internal’ directive to plugin manifests to flag certain implementation packages as ‘internal’ to the module that exports the package. These packages may still be used by other modules, but the fact the packages are internal is explicitly acknowledged.