HtmlUnit 2.4 Released

December 31, 2008 at 12:12 pm (HtmlUnit, Java)

HtmlUnit 2.4 has been released. See the changelog for more information about all of the improvements made since September, when version 2.3 was released. The TSS announcement is probably a good place to comment or ask questions about this release.

It’s exciting to see the steady improvement in JavaScript support. From the HtmlUnit main page:

The unit tests of some well-known JavaScript libraries are included in HtmlUnit’s own unit tests; based on these unit tests, the following libraries are known to work well with HtmlUnit:

  • jQuery 1.2.6: Full support (see unit test here )
  • MochiKit 1.4.1: Full support (see unit tests here )
  • GWT 1.5.3: Full support (see unit test here )
  • Sarissa 0.9.9.3: Full support (see unit test here )
  • Prototype 1.6.0: Very good support (see unit test here )
  • Ext JS 2.2: Very good support (see unit test here )
  • Dojo 1.0.2: Good support (see unit test here )
  • YUI 2.3.0: Good support (see unit test here )

3 Comments

SpringSource Reworks Maintenance Policy

October 7, 2008 at 2:56 pm (Java, Spring)

A couple of weeks ago SpringSource modified their maintenance policy. The change was a significant move in that it stripped non-paying users of certain perks (rights?), to the point of triggering arguments regarding what, exactly, constitutes an “open source” project.

In an attempt to find a balance between their open source roots and their commercial obligations, SpringSource made a mistake. They’ve now admitted it, and they’ve acted upon that knowledge. Kudos to them.

Back to work.

2 Comments

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.

Leave a Comment

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

From the Annals of Leaky Abstractions

August 19, 2008 at 6:33 am (Java)

Last week I created a new Java package named “net.gredler.app.converter” during a bit of refactoring. I know, I know. Pretty impressive stuff. But there’s more.

If you’ve used Eclipse before, you know that it provides feedback as you type, alerting you if your package name is not valid as is. For example, if you type “net.gredler.app.”, Eclipse will helpfully throw up the following error:

Invalid package name. A package name cannot start or end with a dot.

Well, I eventually got to “net.gredler.app.con”, and received the following error message:

Invalid package name. con is an invalid name on this platform.

Weird, no? It turns out that there are some limitations on directory names in Windows: you can’t have directories named “con”, “prn”, “aux” or “nul”, among others.

Apparently these were reserved words in DOS back in the day, and this restriction has propagated to the latest versions of Windows in the name of backward compatibility.

So if you’re coding in Linux or Mac OS X and want to ensure that your Java web application isn’t deployable on Windows, adding a package named “con” ought to do the trick (assuming your servlet container explodes WARs) ;-)

3 Comments

Maven Enhancements to Keep an Eye On

August 5, 2008 at 1:17 pm (Java, Maven)

MNG-3397: More concise POM syntax (more info here).
MNG-3379: Concurrent artifact resolution (more info here).
MNG-2315: Easy mass transitive dependency exclusions.
MNG-1977: Global transitive dependency exclusions.

Have I missed any?

Leave a Comment

HtmlUnit 2.2 Released

July 30, 2008 at 11:57 am (HtmlUnit, Java)

A new version of HtmlUnit, the Java headless browser, has been released. The main purpose of this library is to enable scalable, performant pure-Java integration testing of web applications. HtmlUnit can also be used to scrape the web, and drives a number of other open source libraries, including Canoo WebTest, WebDriver, Celerity, Schnell, and JSFUnit.

Highlights of changes incorporated in version 2.2 include:

- Better handling of ill-formed HTML.
- Enhancements in the areas of performance and memory usage.
- Enhanced API for dealing with attachments.
- Enhanced API for dealing with proxies.
- Use of a (temporary) forked version of Rhino to fix many JavaScript bugs.
- More than 80 bugfixes and enhancements overall.

Please see the changelog for more information.

HtmlUnit 2.2 is available via the central Maven repository, or may be downloaded directly here.

1 Comment

JavaScript Isn’t a Toy Language (Anymore)!

July 26, 2008 at 4:01 am (JavaScript, Software)

So… JavaScript. When did one begin to feel that this crufty, popup-enabling, slightly-better-than-VB programming language for the unwashed masses might actually merit a second look?

Was it the first time you used Google Maps and realized you were moving the map without reloading the entire page?

Was it when Sun decided to include Rhino in the JDK?

Or when you browsed the Dojo codebase and realized that Java doesn’t have a monopoly on obtuse, enterprisey, over-architected design?

No? Maybe you figured it out when 60+ companies got together and decided it was worth the effort to start the OpenAjax Alliance in order to formalize common sense best practices for JavaScript libraries.

I know! It was when you (and your mother, and your coworkers, and all of their extended families) read Steve Yegge’s NBL blog post.

Actually, maybe it was when you decided to add John Resig to your blogroll.

Me?

The other week I read this article by John, in which he mentions the big O performance characteristics of a certain JavaScript benchmark. It doesn’t matter what benchmark, just focus on the important part here: big O. In an article on JavaScript. Big O. And JavaScript. Big O. JavaScript. And nary a raised eyebrow among the comments; almost the complete opposite, actually!

It’s almost like it’s respectable, or som’n.

Leave a Comment

« Older entries Newer entries »