Bridging the gap to Java: We chat with Louis Zuckerman about bringing GlusterFS to the platform

We met with a whole bunch of people at the recent DevNation Gluster hackathon, but Louis was the only one wearing a fedora. After awarding him bonus points, we sat down and talked about his project to bridge Gluster with Java.

Louis Zuckerman at DevNation’s Gluster Hackathon

Who are you?

I’m Louis Zuckerman, CTO of Picture Marketing, and GlusterFS board member and package maintainer.

What are you working on?

My project is to bridge Gluster with Java. Gluster 3.4, a recent release, introduced a new client API where programs can link directly to Gluster. What I’m working on is building bindings in Java for the Gluster client API, which allows any program running on the Java platform to use Gluster directly.

What’s the benefit of your project?

Before libgfapi – the Gluster client library – was available, the only way to access GlusterFS was through a FUSE mount that limited performance and required system level support. So one benefit of linking to Java is that high-performance apps don’t need to go through FUSE, which increases performance.

There are other benefits too. When you’re working with FUSE, you’re going through the file system on Linux, and you need system support. The system has to be set up for it: root access, a mount set up in the system. But if you link directly with Gluster, you can just run your application like a normal user, and you don’t need special support from the system.

OpenShift, Heroku, Google App Engine, Amazon Elastic Beanstalk, these are platform as a service (PaaS) cloud providers. You can deploy your app but you can’t make demands on the underlying system. You can’t say, “I need a mount at this directory.” When apps can communicate directly with Gluster they can be deployed on a wider variety of platforms, such as PaaS clouds.

Here’s another benefit: There are a lot of languages that can run on the JVM, and they can all use my library since it’s all just code on the JVM.  Two popular languages with native C bindings to Gluster are Python and Ruby.  My library provides support for Gluster through their JVM counterparts, JRuby and Jython.  There are many more languages that run on Java Virtual Machine, like Scala, Clojure, and Groovy to name just a few, and all of these languages can make use of my library.  I should clarify that I’m not only building a low level C to Java binding (through JNI) but also a high level Java Filesystem Provider implementation (through NIO.2) which is very easy to use – far easier than the low level libgfapi C bindings in other language runtimes.

Any parting words?

I’m also the maintainer of the Debian and Ubuntu packages for the Gluster community. Anybody using Gluster on Ubuntu is using my packages. I’m active in IRC on Freenode, in the #gluster channel, with the username Semiosis.

Anyone interested should please drop in to IRC, and of course check out the project on Github: https://github.com/semiosis/glusterfs-java-filesystem