January 20, 2010 at 11:17 am (Java, Optimization, Spring)
The application I’m currently working on is built around Spring. A couple of weeks ago, as I waited for it to start up for the 27th time that day, I began wondering if there was any way to get it to start faster. Coincidentally, our whole development team had just received upgraded laptops, so the fact that numbers are stagnating in the “Megahertz” department (but not in the “CPU cores” department) had been recently emphasized.
Further, I had just read a series of articles by Cédric Beust regarding recent improvements to the TestNG threading engine. In short, TestNG allows you to run tests on multiple threads in order to shorten the test suite run time. However, when you start creating tests with dependencies on other tests, TestNG punts and runs all of these groups of dependent tests serially, on a single thread. Cédric wanted to remove this limitation, and approached the enhancement as a topological sort problem, viewing the tests as nodes in a directed acyclic graph.
Most of the startup time in Spring-centric applications involves the initialization of singleton beans. It wasn’t too much of a mental leap to wonder if the same graph/sort approach could be applied to the application startup optimization question — with the Spring beans acting as the nodes in the graph, instead of the tests.
It turns out to be (sort of) possible, and (sort of) worth the time. I’ve posted the details, including the source, here. Feel free to check it out and make suggestions. The Spring framework does contain a very coarse lock that required a pretty horrible hack in order to get any performance gains out of the experiment, but once this is worked out I don’t see why an implementation of this approach couldn’t make it into real applications. Again, see the project page for more details.
On a side note, this is the first time that I’ve used GitHub to host any code, and I have to say that I really like the fact that the README file serves the dual purposes of local project documentation and homepage markup!
Leave a Comment
January 10, 2009 at 9:47 pm (Java, Spring)
If you tell Spring 2.5.6 to scan the classpath for application context XML files and you’re deploying to JBoss 5, you may run into this bug; something to do with JBoss’ new Virtual File System (VFS) and its non-standard URLs. It looks like this issue was caught in time to be fixed for 2.5.6, but I guess the SpringSource guys didn’t have time to test it before releasing — the fix doesn’t really work.
It appears there will be a 2.5.7 release within the next couple of months (see slide 14), but it’s probably going to be the first of the commercial-only Spring releases. However, Spring 3.0 is also due within the next couple of months (see slide 5); let’s hope for a fix then. Otherwise, they may have to take JBoss off of the deploy graph on slide 4 
3 Comments
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
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
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:
- 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.
- 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
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
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
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
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
April 24, 2008 at 12:45 am (HtmlUnit, Java, Optimization)
I just cut HtmlUnit’s build time by about 20% by changing four lines of code. How? HtmlUnit keeps a small cache of web requests in a HashMap, keyed on the request URL. The problem with this is twofold:
- The URL.hashCode() method is synchronized.
- The URL.hashCode() method triggers DNS lookups for the URL hosts.
The impact of item 2 was magnified by the fact that some of the HtmlUnit unit tests use a mock web connection to connect to fake URLs. DNS (non)resolution of these fake URLs took an especially long time.
The fix was to key the map entries on the value of URL.toString() instead. Apparently I’m not the first person to stumble across this problem. So think twice before coding your next HashMap<URL, XXX>
6 Comments
