Prototype Virgo charm

In the previous post, I mentioned a use case for the Virgo buildpack of running Virgo as an Ubuntu Juju charm. With some advice from the guys at Canonical, for which I'm grateful, a first prototype is now working.

The purpose of a charm is to instantiate a service in a cloud. I'm testing on Amazon EC2, although the charm should run without change on other clouds. The crucial contents of a charm are a simple metadata description and a series of hooks to control the lifecycle of the service associated with the charm and its relationships with other entities in the cloud.

So far, I've implemented two simple hooks. An install hook downloads and installs a JRE and Virgo as well as a test application. It does this by installing the test application and then running the Virgo buildpack compile operation against the application, which in turn downloads and installs a suitable JRE and Virgo (actually, Virgo Server for Apache Tomcat). A start hook starts Virgo using a command similar to that output by running the Virgo buildpack release operation against the test application.

The following pieces of work are necessary to tidy up the prototype:

• Make the start hook reuse the output of the release operation which is a piece YAML containing the basic shell command necessary to start Virgo. It will probably be simplest to rewrite the start script in Ruby so that parsing the YAML file will be trivial.
  
• Somehow synchronise the termination of the start script with the completion of starting Virgo. Currently, the start hook "fires and forgets" using an asynchronous invocation of the Virgo start script. The result is that the start hook returns before Virgo has started, which gives the wrong impression of the state of the charm, especially if Virgo startup fails for any reason.
  
• Implement any other hooks which are required as a bare minimum, including, presumably, a stop hook.
  
• Provide a mechanism to deploy a specified application to Virgo in place of the test application.

Please see the list of issues on github for all known bugs and restrictions.

There is also the small matter of the charm being checked into git. It is currently necessary to delete the .git directories of the charm itself and of the Virgo buildpack submodule since Juju uses git to version the uploaded charm and .git directories cause the install hook to fail. Canonical have some better support for git in mind, so this may just be a question of waiting.

If you want to try out the charm, you can clone it from github (tagged at the time of writing as v0.1). I've put some simple management scripts (which could also do with a bit of tidying up) in the scripts subdirectory which allow me to refresh a copy of the charm without .git directories, start up the Juju environment, deploy the charm, and tear down the Juju environment (currently the only way to stop the Virgo without using the EC2 console).

I've licensed the code under the Apache v2 license and would be delighted to accept contributions if anyone would like to raise issues, make some of the changes mentioned above, or otherwise improve the charm.

Virgo Buildpack Refreshed

I'm no longer leading the Virgo project, but I am still fond of Virgo, so I thought I would update the Virgo buildpack (previously mentioned in this blog) in my own time to re-base it on the current Java buildpack.

It now inherits all the benefits of the Java buildpack (more here):

• Ability to upgrade Virgo without changing the buildpack or the application - great when a security fix needs to be applied.
• Automatic calculation of JVM memory settings.
• Clean separation of components - Virgo is a new container (described here) and the other components including OpenJDK support are inherited for free.
• Helpful diagnostics including automatic JVM destruction on "out of memory" and debug logging of the buildpack's operations.

I decided to stick to the most general style of application layout that the previous version of the Virgo buildpack used. This consists of a pickup directory containing zero or more applications and, optionally, a repository/usr directory containing any additional dependencies of the application which are not provided by Virgo. This has the advantage that the detection criterion for Virgo (existence of the pickup directory) does not overlap with the detection criteria of the other containers inherited from the Java buildpack (Groovy, Play, Java Main, Spring Boot CLI, Tomcat) and so the Virgo buildpack is a functional superset of the Java buildpack.

There are two use cases that interest me. One is running Virgo on Cloud Foundry. The other is running Virgo as an Ubuntu Juju Charm - but more of that on another occasion.

Restore Windows pop-up from Java on Mac OS X

I kept seeing the following pop-up during Java based builds on Mac OS X:

There was no obvious cause, but this was annoying as it paused the build until I dismissed the pop-up, although it never seemed to have any side-effect in the build.

I finally seem to have found the solution, which was to delete the Java related files in the directory ~/Library/Saved Application State:


$ rm -rf ~/Library/Saved\ Application\ State/com.apple.javajdk16.cmd.savedState/
$ rm -rf ~/Library/Saved\ Application\ State/net.java.openjdk.cmd.savedState/

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.

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. ;-)

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".