SpringSource Killing the Golden Goose?

September 19, 2008 at 11:03 am (Java, Spring)

As per this post on TSS, SpringSource have announced a new maintenance policy:

Customers who are using SpringSource Enterprise, available under a subscription, will receive maintenance releases for three years from the general availability of a major new version. These customers receive ongoing, rapid patches as well as regular maintenance releases to address bugs, security vulnerabilities and usability issues, making SpringSource Enterprise the best option for production systems.

After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues. Subsequent maintenance releases will be available to SpringSource Enterprise customers. Bug fixes will be folded into the open source development trunk and will be made available in the next major community release of the software.

Now, there are only two ways I can read this:

  1. After the initial three-month window following a major release, bug fixes will not be available to non-paying customers until the next major release.
  2. After the initial three-month window following a major release, bug fixes will be available to non-paying customers only via public source control — not via real, numbered releases.

If we take the Spring 2.5.x series of releases as an example, we have the following time line:

Spring 2.5.0: 2007-11-19
Spring 2.5.1: 2008-01-09
Spring 2.5.2: 2008-02-29
Spring 2.5.3: 2008-04-06
Spring 2.5.4: 2008-04-28
Spring 2.5.5: 2008-06-23

Applying the three-month rule to these releases, we can see that the community around this open source project would only have access to Spring 2.5.0, 2.5.1 and 2.5.2 (if we’re generous and round up).

I’m not sure whether or not the community would have access via public source control to the bugfixes included in the subsequent releases prior to the next major release, but as far as I can tell the best-case scenario is that we would have to build the subsequent releases ourselves, rather than just download the JARs directly.

Additionally, this policy takes effect immediately. If you’re not paying SpringSource, you may not get access to the upcoming 2.5.6 release…

Somebody tell me I’m misreading this.

UPDATE: Here.

7 Comments

Scriptom Kudos

September 18, 2008 at 12:33 am (Groovy)

I recently had the chance to revisit some Groovy code written last year which makes use of the Scriptom library, a Groovy/COM bridge which allows you to script ActiveX and COM components from Groovy. The code in question was fairly fragile in the worst of ways: it would crash roughly half the time… randomly.

Now, I’m not sure if the crashes were caused by Scriptom or by Jacob, the underlying Java/COM bridge, but after upgrading to the latest version of Scriptom (1.5.4b11, which also uses a newer version of Jacob) all of these crashes have disappeared.

The migration process took a couple of hours, but only because I didn’t read the Migrating from Previous Versions of Scriptom section on this page first; if I had done so, the migration would have been a matter of minutes.

Anyway, kudos to the Scriptom team (which apparently includes Marc Guillemot, a fellow HtmlUnit hacker) on an excellent release of this very useful library!

2 Comments

Maven + log4j 1.2.15 = BOOM!

September 12, 2008 at 1:05 pm (Java, Maven)

Don’t try to use log4j 1.2.15 with Maven 2 — they didn’t mark their optional dependencies optional, forcing you to download and locally install a bunch of JavaMail, JMX and JMS JARs. More info here. Bug report here.

Comments Off

JavaScript Iteration Order

September 10, 2008 at 1:28 am (Chrome, JavaScript, Rhino)

The blogosphere has been flooded with Google Chrome-related posts for the past week or so, especially in the niches catering to web developers, browser developers and JavaScript enthusiasts. I haven’t tried it out yet, but I don’t see why that should keep me from joining the fracas ;-)

The Chrome team’s vision is refreshing. Their technology is intriguing. Their future? Uncertain. However, these topics have been explored in such depth that any effort at original contributions in these areas, at this time, are almost certainly useless.

I did, however, have to smile when I read John Resig’s post on JavaScript in Chrome. In it, he highlights a number of JavaScript issues in this new browser, the third one being for loop ordering:

Currently all major browsers loop over the properties of an object in the order in which they were defined. Chrome does this as well, except for a couple cases… If an object contains a value which is not a primitive… then its properties will be enumerated in a different order from which they were defined.

This is an interesting bug due to one fact: This behavior is explicitly left undefined by the ECMAScript specification… However, specification is quite different from implementation. All modern implementations of ECMAScript iterate through object properties in the order in which they were defined. Because of this the Chrome team has deemed this to be a bug and will be fixing it.

The reason I find this amusing is that the Rhino codebase suffered from the exact same problem, only recently adhering to the de facto standard which in this area subsumes the de jure ECMAScript standard.

We had a number of HtmlUnit users complain about this lapse, and even now the fix is not available in any official Rhino releases — hence HtmlUnit’s Rhino fork.

It appears implementers are doomed to repeat this mistake until such time as this unofficial convention is given official sanction. The recent outbreak of common sense, pragmatism and brotherly love on the ECMAScript committee is cause for optimism.

As John Resig mentions in his post on ECMAScript 3.1, much of the committee’s recent work has focused on standardization of such conventions:

Probably the most important development within all this [ECMAScript Harmony news] is the codification of existing de facto standards. For example, the concept of JavaScript getters and setters (implemented by Mozilla, Apple, and Opera) are going to be quickly fast-tracked into the specification (in the case of getters and setters they already have been). Seeing real-world code quickly make a bee-line for standardization is truly heartwarming. We’ll probably see more of this for topics like ‘let’ and ‘expression closures’ – but which will arrive post-ECMAScript 3.1 (since they require new syntax).

So will definition-order property iteration make it into ECMAScript 3.1? One can only hope, for the sake of the V9, V10 and V11 development teams…

UPDATE: The current (September 1st, 2008) ECMAScript 3.1 spec contains the following comment regarding the text in question:

We considered specifying the enumeration order but there were too many issues with existing implementations that optimize the representation of arrays.

Argh…

1 Comment

Follow

Get every new post delivered to your Inbox.