The thread model of Java is pretty good and works well for many use cases, but every now and then you need a separate process for better isolation of certain computations. For example in Apache Tika we’re looking for a way to avoid OutOfMemoryErrors or JVM crashes caused by faulty libraries or troublesome input data.
In C and many other programming languages the straightforward way to achieve this is to fork separate processes for such tasks. Unfortunately Java doesn’t support the concept of a fork (i.e. creating a copy of a running process). Instead, all you can do is to start up a completely new process. To create a mirror copy of your current process you’d need to start a new JVM instance with a recreated classpath and make sure that the new process reaches a state where you can get useful results from it. This is quite complicated and typically depends on predefined knowledge of what your classpath looks like. Certainly not something for a simple library to do when deployed somewhere inside a complex application server.
But there’s another way! The latest Tika trunk now contains an early version of a fork feature that allows you to start a new JVM for running computations with the classes and data that you have in your current JVM instance. This is achieved by copying a few supporting class files to a temporary directory and starting the “child JVM” with only those classes. Once started, the supporting code in the child JVM establishes a simple communication protocol with the parent JVM using the standard input and output streams. You can then send serialized data and processing agents to the child JVM, where they will be deserialized using a special class loader that uses the communication link to access classes and other resources from the parent JVM.
My code is still far from production-ready, but I believe I’ve already solved all the tricky parts and everything seems to work as expected. Perhaps this code should go into an Apache Commons component, since it seems like it would be useful also to other projects beyond Tika. Initial searching didn’t bring up other implementations of the same idea, but I wouldn’t be surprised if there are some out there. Pointers welcome.
The punchcard graphs at Github are a nice way to quickly detect the rough geographical distribution (or nighttime coding habits) of the key contributors of an open source project. Here’s a few selected examples from the ASF.
Apache HTTP Server
Apache Maven (core)
A few days late, here’s a quick report on what I managed to do this Monday here at the ApacheCon EU. As mentioned earlier, I arrived at the conference hotel on Monday evening and headed straight for the Maven meetup.
The meetup was already in progress when I arrived, but I managed to catch a part of a presentation about the Eclipse integration that just keeps getting better. Nowadays it’s so easy to import and manage Maven projects in Eclipse, that I get really annoyed every time I need to do manually set things up for projects with Ant builds.
Other interesting topics covered were Maven archetypes and the release plugin. I’ve for a long time been thinking about doing some archetypes to help setting up new JCR client applications. We should probably also do something similar for setting up new Sling bundles.
The release plugin demo was interesting, though I’m not so sure if I agree with all the conventions and assumptions that the plugin makes. On a related note, we should configure the GPG plugin for the Maven build in Jackrabbit.
We talked a bit about Maven 2.1.0 and the upcoming 3.0 release. I’m already pretty happy with the recent Maven 2.0.x releases, so we’ll probably take a while before upgrading, but it’s good to hear that things are progressing on multiple fronts. We also briefly touched on the differences between the Maven and OSGi dependency models and the ways to better bridge the two worlds.
In summary the meetup was really interesting and served well in giving me a better idea of what’s up in the Maven land. Thanks for everyone involved!
Chops, ribs and beer
After the meetup a few of us headed out to Amsterdam city center for some food and drinks. Monday evening wasn’t perhaps the best time to go out as we needed to wander around looking for places that would be open long enough. Anyway, we found some “interesting” places to visit before returning to the hotel in the early hours. Good times.
It’s ApacheCon time again. I’ll be flying to Amsterdam later today, and will probably be pretty busy for the entire week. Some highlights:
- Maven meetup. I’ll probably arrive at the conference hotel just in time for the Maven meetup, where I’m hoping to catch up with the latest news from the Maven land.
- Git hacking. During the Hackathon on Tuesday I hope to get together with Grzegorz and anyone else interested in setting up git.apache.org.
- Commons Compress. There’s some useful code in the Commons Compress component that I hope to use in Apache Tika. If I have time during the Hackathon I want to help push the component towards its first release.
- CMIS / Chemistry update. I’ve been meaning to check out the CMIS code that Florent Guillaume has been working on recently. I’d love to get the effort better integrated into Jackrabbit.
- Commons XML. I’ve been gathering some JAXP utility code to a new XML library in the Commons sandbox. I hope to spend some time pushing more code there and perhaps discussing the concept with some interested people.
- Juuso lab. I have lots of new ideas about RDF processing and Prolog. Hoping to turn those into working code.
- Lucene meetup. Catching up with the latest in Lucene and telling people about Tika and the Lucene integration we have in Jackrabbit. Unfortunately I only have one hour to spend here before the JCR meetup starts.
- JCR meetup. Starting at 8pm, the JCR meetup is one of the key highlights of the conference for me. We’ll be covering stuff related to the Jackrabbit and Sling projects. You’re welcome to join us (sign up here) if you’re interested in the latest news from the content repository world.
And lots of other stuff, too much to keep track of…
The PDFBox project is a well known and widely used Java library for reading and writing documents in the Portable Document Format (PDF). Here’s my perspective on the recent developments of the project.
The project was quite dormant when it entered the Apache Incubator about a year ago after we had discussed the idea first at the ApacheCon US 2007 and then on the Incubator mailing list. For a while it looked like project would remain quiet, but in the past few months we’ve seen a clear increase in project activity. Thanks for that goes especially to the contributions of the two new committers, Andreas Lehmkühler and Brian Carrier.
My main focus in Apache PDFBox has recently been the thorough license review that I’ve been conducting. Before entering the Incubator, the PDFBox library was liberally licensed under a BSD License. However, the copyright or licensing status of many external components included in PDFBox was neither well documented nor well understood by downstream projects. For example, PDFBox used to contain parts of the Java Advanced Imaging (JAI) library that is only available under the Sun Binary Code License, a license that is not compatible with Apache policies.
The license review has taken me through a number of legal issues, put me in contact with the Adobe legal team, and made me solve some followup issues. And we also took care of proper export control notifications needed for the PDF encryption support in PDFBox. Luckily the end is finally in sight, and I’m optimistic about having all the remaining open issues closed within a month or so. Altogether it’s been a very interesting and educational process.
With the license review nearing completion and lots of unreleased fixes and improvements accumulating in the project trunk, it is time to start preparing for the first incubating PDFBox release. This release will be called Apache PDFBox 0.8.0-incubating, and will be a major improvement over the 0.7.3 release from over two years ago. All downstream projects should seriously consider upgrading as soon as the release becomes available. It would be really great if the release was out by the ApacheCon Europe at the end of March.
As a mentor and champion of the project I am really happy with the current status. It seems reasonable to expect PDFBox to graduate from the Incubator sometime later this year.
In the Apache Jackrabbit project we’ve decided to create a new JCR Commons subproject for developing and managing the set of generic JCR tools that has grown over time around the core Jackrabbit content repository implementation.
The JCR Commons subproject will to some extent resemble the Apache Commons project, and I’m hoping to use some of the ideas put forward by Henri in his blog post about a “federated commons”.
I’m hoping to flesh out the details of this new subproject over the next month or two. It would be nice to have releases of all the new JCR Commons components ready to be used as dependencies for the upcoming Jackrabbit 1.6 release.