Happy Christmas!

OK, so it's a bit belated, but I've just got around to uploading my latest Xmas 2009 post. It's also an opportunity to look back at the last decade to see what's changed, including how connected we all are. After all, you're reading this on my blog (which has just rolled over its 400th post), and anyone can reach out to me via @AlBlue at Twitter; and whilst the Xmas letter used to actually be, well, a letter that got posted, it's been electronic for the last decade. Now it's simply a case of posting an updated status message and anyone can reach out and read it at their convenience.

Here's to a happy 2010!

JSR294 Fantasy Version Series - Irrational

Following on from yesterday's Planets episode, today introduces the final instalment, the irrational versioning scheme.

An irrational number is one which can't be expressed as a division of two whole numbers. So, whilst ½ and ¼ are rational, numbers like π and √2 are irrational.

A nice property of an irrational number is that (a) the digits go on for ever (if they didn't, there would be some number b which is a power of 10 that n/b would be a whole number), and (b) that they don't repeat digits. In other words, our version numbering entropy is infinitely available provided that we operate on a digit basis rather than a strict numerical comparison. Of course, this doesn't permit us to say anything about the importance of changes between subsequent digits; but then, the elegance and beauty of a version numbering system is often not taken into account when dealing with mundane requirements like being able to denote a breaking change.

There are many, some would say infinitely, available irrational numbers for us to choose from; processors SHOULD be able to handle some of them, but not necessarily all of them. In addition, versioning systems MAY have real constraints, such as the ability to represent the version number in an approximating IEEE 754 float or double (depending on bit-width of the operating system). However, they SHOULD try to represent those numbers as an infinite string in order to permit more precision.

The versioning system uses ever more accurate representations of the irrational number. For example, a product whose notional version is based on √2 would start off as version 1, then the next version would be version 1.4, then 1.4.1, and so on. As a result, a product may asymptotically approach the golden version.

Examples of this in use are TeX (the engine underneath LaTeX and others) and METAFONT. TeX is based on the digits of π whilst METAFONT is based on the digits of e. As these both asymptotically approach their mathematical counterparts, their stability will increase, until such a time as they reach π and e respectively.

We may use this to define module requirements, as in the following non-normative example

module IrrationalVersioningSystem @ ∞ {
 requires TeX @ [3.14159,π),
 requires METAFONT @ [2.718,e),
 permits Historic @ √66,
}

I hope you've enjoyed the last few posts on Planetary version system, Linux version system, and the Roman version system. Let's look forward to what other possibilities open up when JSR 294 is finally released!

Bonus: here's how to calculate &pi to an increasing approximation of accuracy using just random numbers. Pick a random number between 0.0 and 1.0, and multiply it by itself. Pick another random number between 0.0 and 1.0, and multiply it by itself. Add them together, and if it's less than 1, increment p by one. If it's less than 2, increment i by one. Repeat until the desired accuracy is found, approximately 10^d iterations where d is the desired number of digits. The answer 4p/i ≈ &pi.

New InfoQ article on Declarative Modularity

I'm pleased to announce that my latest article on Declarative Modularity has been published on InfoQ. This brings the total in the series (so far) to four:

1. Modular Java: What Is It?
2. Modular Java: Static Modularity
3. Modular Java: Dynamic Modularity
4. Modular Java: Declarative Modularity

Please let me know by Twitter @AlBlue or comments to this post what you'd like to see in future versions.

JSR294 Fantasy Version Series - Planets

Following on from yesterday's Linux versioning, today introduces the Solar versioning system (not to be confused with the Sun versioning system).

For simple versioning requirements, especially where numbers are not required (or too complicated for the user to understand), the Solar versioning system can help. These are names based on planetary bodies, ordered by distance from the Sun. (No, not that Sun. Nor that one.)

It therefore follows that this versioning system is one which consists of one of a fixed-size enumeration. The ordering of this enumeration is defined in advance, and suits internal product development, since often they are thrown away and redeveloped under a new project name after a few releases. It also has the nice property that version 2 corresponds to Earth (assuming a zero-indexed comparison), and given that most products only start to become habitable after version 2 has nice symmetry with our place in the Universe. Not only that, but the application branding practically writes itself, with many high-quality images and music available.

The versioning format is therefore represented by a regular expression: (Mercury | Venus | Earth | Mars | Jupiter | Saturn | Uranus | Neptune). The ordering is fixed, with the order:

1. Mercury
2. Venus
3. Earth
4. Mars
5. Jupiter
6. Saturn
7. Uranus
8. Neptune

Note that Pluto is not a valid version number, having been declassified as a planet owing to failing to clear out surrounding orbits, which would have made version comparisons difficult. Note also that planetary moons cannot used for proper version numbers either, since these can't be comparable to orbits around other bodies accurately.

We may use this to define module requirements, as in the following non-normative example:

module Home @ Earth {
	requires InnerSystem @ [Mercury,Earth)
	requires OuterSystem @ (Earth,Neptune]
	permits Asteroids @ (Mars,Jupiter)
}

JSR294 Fantasy Version Series - Linux

Following on from yesterday's Roman Numeral episode, today introduces the Linux versioning scheme. (The kernel; not to be confused with GNU/Linux in case there's some bearded hippie reading this. The next in the series is now available.)

Linux version numbering begins with a 2, and then uses even/odd digits to denote development releases and stable releases. For example, 2.3 reflected a developmental kernel whilst 2.4 was a stable kernel.

After that, there is one (or more) digits that are numerically incremented. For marketing reasons, if a version isn't considered to be 'big enough', then a fourth (or more) digits can be randomly added to the end. This holds true for largely backward compatible changes as well as slightly not backward compatible ones as well.

The versioning format is therefore represented by a regular expressions: for stable releases, the format is 2\.[0-9]*[02468]\.[0-9]+(\.[0-9]+)*, whilst for development releases it is 2\.[0-9]*[13579]\.[0-9]+(\.[0-9]+)*. Users MUST randomly add new digits if, in their belief, it's not really that big a change. Note that this system is infinitely flexible, reaching an epsilon state, so bug fixes involving documentation changes might be represented as 2.4.6.1.1.1.1.1.1.1. After all, it worked for LDAP OIDs.

Fields are decomposed (separated by ., escaped as \. in the regex above) and compared numerically. If digits are missing, they are assumed to be zero. Fields are compared in order; if all one is a proper prefix of the other (i.e. one is a full subset of another, but the other is longer) then length wins, as with other areas of life.

Note that because there are two, overlaid, versioning schemes, whilst it is possible to compare developmental releases to developmental releases (c.f. stable), it is not possible to compare developmental and stable releases. In other words, the comparison function is a partial function over the version namespace; comparisions between developmental and stable are expressly prohibited. Furthermore, version ranges are therefore not considered continuous; the version line of a stable system might be [2.0,3.0) but this is to be interpreted as the union [2.0,2.1),[2.2,2,3), [2.4,2.5) etc. This represents a great advantage over more limited versioning systems which only have three digits and do not consider discontinuous ranges.

We may use this to define module requirements, as in the following non-normative example

module Lenny @ 2.4 {
 requires SMTP @ [2.2,2.5), // But not 2.3, because that's a dev release
 requires MacOSX @ 2.10.*.2+, // Who uses Mac OS X before .2 comes out?
 permits Desmond @ 2.2,
}

Note: this is not to be confused with "vaguely Debian-like syntax." Debian is a Linux Distribution, not a Linux Kernel, and uses a different versioning scheme.

JSR294 Fantasy Version Series - Roman Numerals

To paraphrase Mark Twain, “The reports of JSR 294's death are greatly exaggerated.” Alex Buckley confirmed that JSR 294 is alive and well, and automated bureaucratic processes were to blame for the reported inactivation. Or, as Dave Savage would have it, #jsr294isUndead.

With that in mind, and in the anticipation of the new JSR 294 EDR due RSN, I thought I'd take the time to explore a few fantasy version schemes which will all be possible under the new implementation. The first in the series is Roman Numerals. (The next in the series is now available.)

Roman Numerals are a way of encoding numbers with a handful of characters, with the following meaning:

• M 1000
• D 500
• C 100
• L 50
• X 10
• V 5
• I 1

Conventionally, a maximum of 3 repeated characters can be used and a smaller number prior to a bigger number results in subtraction of that smaller number. So VIII is 8, whilst IX is 9. Technically, IIX is also 8, but if it can be written in non-subtraction form, then it should be. Various on-line converters exist to aid you with the encoding.

This allows us to define a version system which uses Roman Numerals as their encoding, with MUST, SHOULD etc. taken from RFC 2119. Note that because Roman Numerals have no decimal point, there are no sub-version ranges in this specification.

Specification

An version number is represented as a construction from the following regular expression: “(MDCLXVI)+”. Clients SHOULD only generate valid Roman Numerals; parsers MUST accept invalid constructions as well. For example, IM is a degenerate form of CMXCIX, which is CLEARLY easier to understand.

Case is significant; encodings exist where i has a different meaning than I so clients MUST use the correct capitalisation. In the absence of systems without capitalisation (where the shift key is broken, or if it's known that it comes from mainframe-based systems), then the server MAY assume that the it was supposed to be in upper case.

Versions are compared with their decoded Roman Numeral versions. Version numbers MUST be positive, non-zero integers, since there is no way of representing zero (constructs like IIIIIV are disallowed as above). Following that each letter may be repeated a maximum of three times, the longest version number that can be represented is 3888 (MMMDCCCLXXXVIII) although the largest value is represented at 3999 (MMMCMXCIX) without going into the upper region (not defined or used here).

We may use this to define module requirements as in the following non-normative example:

module Nodule @ I {
	requires Copyright @ MMIX,
	provides Fox @ MCMI,
	permits Henry @ VIII,
}

Update: The next in the series, Linux is now available.

JSR294 is dead, long live OSGi!

Update: Alex Buckley has posted on the modularity observer mailing list that any JSR which doesn't post an EDR is automatically filed as inactive. We await a new EDR to celebrate its resurrection. Below is the original post.

As my Bundle.update: OSGi in Java EE and JSR 294 marked inactive post on InfoQ noted, JSR 294 is now marked as 'inactive' on the JCP. This brings both Sun-sponsored efforts on Java modularity to a formal close, leaving JSR 291, aka OSGi 4.1, as the current officially approved spec for Java modularity.

There hasn't been much traffic on the JSR 294 mailing list for a while; the Simple Module System proposal was a last ditch effort by members of the JSR 294 Expert Group to bring some kind of sanity to the module process, even offering olive branches to try and overcome the (perceived) problems.

There were really two main sticking points that prevented a common modularity story happening:

• The format (and semantics) of the version number were inconsistent between the de-facto standard OSGi and the proposed “Vaguely Debian-like versions” – despite everyone in the industry using three digits or less for component versions (and not marketing versions, as I've noted before). Stanley Ho's notable Minor version number should be incremented for making medium or minor changes where the software remains largely backward-compatible sums up the approach nicely here; specifically, that there's no understanding of how to do versioning properly.
• Confusion about bundles vs JARs vs split packages; OSGi supports all of these, despite fears to the contrary. And although there are a number of (somewhat hairy) inter-dependency problems between Java's packages, Apache Harmony shows that not only can it be done, it can be done under the same OSGi semantics. It's worth explicitly noting that Harmony doesn't need (or provide) an OSGi runtime; yet it adopts the same semantics in the individual modules manifests with a custom (non-OSGi) checker to verify that the constraints hold.

The Simple Module System was really the last ditch attempt by the expert group to save compatibility between Sun's JDK modularisation attempt Jigsaw and the de-facto modularisation standard that everybody uses. Even if Jigsaw is a resounding success, it still won't be available until after Summer 2011, and that's assuming that a JSR for Java 7 ever materialises – which according to sources, is unlikely to happen any time soon.

Q Why not start a closures JSR now and let its Expert Group do the work of formulating a new proposal?

A For the same reason that there's not yet a JSR for Project Coin, namely that no new Java SE JSR is likely to be approved until the present dispute in the JCP Executive Committee is resolved.

The final message to the JSR 294 group directed all Jigsaw-related traffic to the project Jigsaw mailing list. It appears that rather than trying to build consensus amongst the expert group, they're leaving it to the implementation of Jigsaw to drive the standard – and presumably, whatever “Vaguely Debian-like semantics” actually means. Still, whatever happens, we can agree that modularisation of the JDK is still a laudable goal, and that Jigsaw, as a Sun-specific JVM implementation detail, is likely to be well honed for that purpose; but nothing else.

Meanwhile, OSGi goes from strength to strength (see my state of OSGi posts at InfoQ columns in December and October 2009), with all major JEE vendors using or providing OSGi runtimes, including Sun's recently released GlassFish v3. The ongoing work of the OSGi Enterprise Expert Group is likely to make the future JEE specifications irrelevant in any case; adopters will simply be able to assemble their own runtimes based on OSGi and however large or small the components are to support their needs. It's unlikely that we're ever going to see a new JEE JSR, although it's likely that individual specifications (Servlet, JSP, etc.) will continue to evolve independently as now.

At the moment, there's very few developers who aren't aware of OSGi; and aside from a few disgruntled NetBeans users, who insist on believing OSGi == Eclipse == IBM (here's a hint; the developers of the Apache Felix OSGi runtime – which includes Sun employees – all use NetBeans), developer tools (Eclipse, IntelliJ) and build environments (Maven/Tycho, PAX Construct) are already here. And even though Maven 3 is just around the corner, the next version will be based on an OSGi runtime and adopt OSGi version number semantics.

So, compatibility between Jigsaw and OSGi is not going to happen. The choice is simple; if you're writing the JDK, use Jigsaw. For everything else, there's OSGi.

JavaScript 5 standard released

I've just written up on InfoQ about the new ECMAScript 5 standard (also known as JavaScript™). It brings about several new changes to the language and runtime; it's only a matter of time before the features are implemented in up-to-date browsers like WebKit and Chrome.

whatever reason. So that's the purpose of this blog entry, short and sweet though it is.

JEE 6 Approved, but licensing issues remain

JEE 6 (JSR 316) has been approved by the SE/EE committee. However, it's telling that the JCP itself is under more fire rather than the technical content of what the JSRs are aiming to provide.

There has been a long-standing dispute between the Apache foundation and Sun, spurred on by the licensing constraints relating to the Java TCK (testing compatibility kit). This has been going on since April 10, 2007 and still doesn't seem to have been resolved satisfactorily.

As a result, the Apache foundation voted against the JCP, with the following:

The Apache Software Foundation's vote is based on the point of view that this spec lead - Sun - is in violation of the JSPA

http://www.apache.org/jcp/sunopenletter.html

and therefore shouldn't be allowed to lead other JSRs until the above matter is resolved.

This vote is not a comment on the technical merits of the JSR. If not for the issue of the spec lead, the ASF would have otherwise voted "yes".

This makes the first JSR that has had a negative vote - the last one for JEE 5 was approved by all. And, despite Apache's stance, there are others voicing their concern as well. SAP abstained with the vote with:

SAP had welcomed the changes made to the Java Community Process where "Spec Leads must provide complete copies of the licenses that they intend to use, not simply a summary of some of the terms" (quote from the JCP Process document http://www.jcp.org/en/procedures/jcp2). This change to the process had promised to create transparency about the licensing of Java in order to prevent that Java is used for unfair business advantage against any particular party in the marketplace.

However, we are disappointed that Sun Microsystems as the Spec Lead of the Java EE 6 specification has not managed to produce the promised "full license terms" of the Java EE 6 TCK until the begin of the two week voting window for Java EE 6. Given the complexity of this license, we are unfortunately not in a position to complete a thorough legal review. At a minimum, we would expect that the TCK is not used to prevent access to the Java marketplace, including open source implementations. This JSR has been filed in July 2007; we believe there would have been ample time to share and discuss the proposed full license terms with the community.

Regrettable [sic], we will therefore have to abstain from the Java EE 6 vote. This is not a statement about the technical merits of the underlying JSRs on which we have voted separately, but rather a reflection on the transparency and efficiency of the licensing process managed by Sun as the owner of the Java Community Process related to intellectual property critical for today’s IT landscapes.

IBM also chose to use this opportunity to comment on the licensing issues; having said that, it made much the same comment for JEE 5 as well:

With the exception of the JSR 330 and JSR 299 injection support defined by the EE 6 platform, we believe that this new specification brings value to the industry. We remain concerned that the injection support defined by the platform will create unnecessary difficulties for the community. IBM will continue to support both expert groups in the development of a single integrated and extensible injection programming model.

IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.

Intel also observed that the JSR wasn't well handled, although it didn't have an issue with the technical spec.

It remains to be seen whether Oracle can salvage any respect for the JCP, or whether it will replace the process with something more open. Indeed, this has already been done for Project Jigsaw, which notionally has JSR 294 associated with it but that in fact, all the work is being done externally with little to no discussion on the expert mailing list group. Maybe the JCP has made itself irrelevant?