Anaphylaxis

Not sure if I mentioned it already, but I don't really like the taste of honey.  I keep bees because they are fascinating creatures with highly complex behavior, both individually and as a colony.  The mixture of practical and theoretical skills required to keep honeybees well appeals to me.

Of course, when you say "bees" people immediately think "stings", probably before they even think of "honey".  I have all the protective gear, but inevitably as a beekeeper you will get stung now and again.  I find that autumn is the worst time of year; understandably perhaps as the bees are protecting their stores built up over summer with little prospect of replacing them before going into winter.

Most stings are harmless enough.  Full coverage clothing means that the bee's stinger does go in far, and if it is far enough for me to notice I can take it out easily.  However, recently I had two different episodes where the reaction was a bit more dramatic.

In one case I was carrying a hive full of bees to move it to another apiary.  The entrance was sealed-up, but a couple of bees were hanging underneath looking for the way in, and took exception to my hand being there nearly squashing them.  I got a full dose of venom in my finger, which was un-gloved as the bees were sealed in, right?  Rather than drop the hive with 50,000 more bees inside I just had to grin and bear it.

The normal response to a bee sting is short intense pain followed by localized swelling, redness and swelling, and a wheal around the sting site lasting about a week.  The reaction is localized to within ~10cm of the sting site.

My reaction was a bit different.  Within ten minutes I had a severe pounding sensation in my head, dizzyness, itchy rash (ironically called "hives") over my whole body, swelling in my armpits and groin, and a feeling of pressure on my chest.  Bugger!  I had to lie down, took a triple dose of anti-histamines, and waited about six uncomfortable hours for it to pass.

The second time I was mowing the lawn quite close to the hives, and I guess one bee took exception, and without warning stung me on my temple.  Bees usually will give you a warning by "head-butting" you a few times, and irately buzzing round you -- this one just went for it!  The result was a similar whole-body reaction.

I'm not big on medications, but the thought has crossed my mind about what would happen if I was careless enough to get multiple stings simultaneously.  So I've now got an epinephrine autoinjector next to the other bits and pieces in my bee kit.

The best description of the recognition and treatment of anaphylaxis I have found is published by the Resuscitation Council (UK).

Provided you watch and listen to what the bees are telling you, then with proper handling and the right protective equipment, getting stung should be a rare occurrence for a beekeeper.  I'm still learning.

IBM and OpenJDK

IBM and Oracle are going to bring their combined resources together to collaborate in OpenJDK. The natural question arises about what this means for the Apache Harmony project.

Apache Harmony has always been clear about the goal of innovating on a compliant and compatible implementation of Java SE. It's also common knowledge that Apache have been requesting a compatibility test kit license for a number of years, and that a suitable license has not been forthcoming. There's little prospect of that situation changing.

So what's best for the Java ecosystem? I believe that compatibility is vital, and rather than risk divergence the right thing is to bring the key platform development groups together on a common codebase. Lessons learned on Project Harmony will be of value to OpenJDK, and I know there is immense mutual respect between the IBM and Oracle engineers.

Java trap not yet disarmed

There is already plenty of opinion written about the Oracle vs. Google action. As a member of the Apache Harmony project I'm an interested bystander in this story, since Android's runtime core libraries come from Apache Harmony. To date, Apache Harmony have not been notified of any involvement in the lawsuit.

Carlo concludes in his blog entry "the open source credibility of Oracle, already damaged by the OpenSolaris affair, is now destroyed" -- and that is the real shame here. Oracle's use of patents in this manner is not good news for anyone in the Java ecosystem who is promoting or using Java as a free and open runtime platform.

Having multiple competing implementations of a specification, that are ultimately held to account for claiming compatibility to the specification by a rigorous test suite, is a good thing.

As is widely known, Apache Harmony has been denied access to the Java SE compatibility test suite in a long running dispute. That situation did not change with Oracle's acquisition of "the most important software [Oracle has] ever acquired". This new action, coming less than six months since the acquisition completed gives me concern for the future of OpenJDK as being the place where Oracle openly and freely advances the most important managed runtime commons.

Contributors to the OpenJDK project have already assigned joint ownership rights to Oracle via the Sun Contributor Agreement. Oracle alone has ownership of the entire OpenJDK codebase.

Apache projects are structured differently. There is no such grant of joint ownership to a single entity, and therefore it would be impossible for a single entity to take control. Apache Harmony is a patchwork of contributions, owned by the community and available to consumers under a liberal open source license. Furthermore, the Apache license has terms that explicitly handle Patent rights (see Section 3), and so it is clear to consumers that they have a license to use any Patented contributions.

I hope Mark is wrong when he says that Oracle are on a "quest to destroy the free Java world" because the only conceivable Java world is one where you can get Java wherever you want it under the freedoms of an open source license. However, it would appear that the trap is not yet fully disarmed, and at least one implementation may be starting to move in the wrong direction.

Oracle += Sun

Well, it took its time coming, but reports are that the acquisition has been approved by the EU today.

I expect a number of Sun employees will be opening their mailer with trepidation when they get into work this morning. Its the end of an era for a big name in the industry, but a great opportunity for a new era in the Java ecosystem.

Congratulations and good luck to all those involved.

Sunset photo by Paul Moody

Dear Santa ...

Thanks for the socks and all that, but my G1 is nearly 18 months old now and I was thinking about getting a Nexus One.

The first problem was that trying to go through the order process using FireFox doesn't seem to work.

Every path after the 'Continue' button results in:I had assumed that the system was busy, but the problem lasted a long time, so I tried with IE, and hey presto it works.

The next 'problem' is that the phone is sold via the US, and as Google are right to point out, that means the sale incurs an import duty when it comes into the UK.

Rather than stumping up the $529 (~=£330) our American friends pay for the phone, delivery included, I was now looking at...

$529 for the phone
+ $19.99 for a UK charger
+ $29.65 shipping

with UK Sales Tax on the total at 17.5% and a 6.5% import duty on all that, which makes it ~$725 (i.e. ~=£453). Ouch.

For the difference I can almost fly to the US and pick it up myself!

Lucky New Year

I went to the Google home page today, and clicked on the "I'm Feeling Lucky" button without anything in the search box.

The result was a page with countdown in seconds,


a quick arithmetic shows it's counting down to the New Year. So somebody is expecting 2010 to be lucky!

UPDATE:

Now the New Year has arrived, the same empty Lucky Button press gives some 'fireworks'!

Programming sockets using temporary ports

In an earlier posting, I showed where there was code in Apache Harmony that had some unsafe parameter checking logic, and I gave a pattern for how to do it right.

Another "anti-pattern" that I see recurring in the Harmony test cases is around client-server socket programming. The typical scenario is that the tester wants to exercise some socket code, so they spin up a new Thread to act as the server, and run the tests on the main thread. The tester either picks a port that they assume will be free, or use some horrible code that tries to find a free port:

   /*
    * Returns a different port number every 6 seconds or so. The port number
    * should be about += 100 at each 6 second interval
    */
  private static int somewhatRandomPort() {
      Calendar c = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
      int minutes = c.get(Calendar.MINUTE);
      int seconds = c.get(Calendar.SECOND);

      return 6000 + (1000 * minutes) + ((seconds / 6) * 100);
  }

Guessing port numbers like this is simply awful and hopeless. Once the port has been established, the poorly written test case opens a server socket to accept connections in the server Thread, while to get the timing right the client goes into a sleep for a while to give the server time to start up. Apart from the fact that the code is going to fail intermittently, it means the test case always takes a minimum length of time to execute as it spends time sleeping.

There is no need for guessing ports or separate threads. In Java, just like other programming languages that expose the underlying platform's TCP/IP stack behaviour, binding to port zero instructs the stack to allocate an ephemeral port.

Furthermore, server sockets have a listen backlog queue capable of remembering 50 outstanding connect requests by default. Here is a example of simple client-server code using an ephemeral port and a single thread to exchange a simple message over TCP/IP sockets.

      // Set-up
      ServerSocket server = new ServerSocket(0);

      Socket client = new Socket();
      client.connect(server.getLocalSocketAddress());

      Socket worker = server.accept();

      // Do some stuff
      client.getOutputStream().write("Hello world!".getBytes("UTF-8"));
      byte[] buffer = new byte[1024];
      int length = worker.getInputStream().read(buffer);

      // Tidy-up
      client.close();
      worker.close();
      server.close();

      System.out.println(new String(buffer, 0, length, "UTF-8"));

Hopefully the code is simple enough to understand without further comment. I'll just point out that the server socket is created with an argument of "0" to mean the listening socket should be opened on any network adapter, with a stack allocated port number, and supporting up to fifty pending connections. Then the client connects to the actual interface and port that was used using getLocalSocketAddress().

The same simple example can also be written using the NIO APIs, which requires passing null to the bind() method, like this:

      // Set-up
      ServerSocketChannel server = ServerSocketChannel.open();
      server.socket().bind(null);

      SocketChannel client = SocketChannel.open();
      client.connect(server.socket().getLocalSocketAddress());

      SocketChannel worker = server.accept();

      // Do some stuff
      client.write(ByteBuffer.wrap("Hello world!".getBytes("UTF-8")));

      ByteBuffer readBuffer = ByteBuffer.allocate(1024);
      worker.read(readBuffer);
      readBuffer.flip();

      // Tidy-up
      worker.close();
      client.close();
      server.close();

      System.out.println(Charset.forName("UTF-8").decode(readBuffer));

Of course, the simple examples still ignore a few return codes and exceptions that should be considered to make the code safer, but the purpose here is to show the structure for tests and applications that need to use sockets to exchange information.