There were lots of great sessions this year, as always. I tried to get outside my comfort zone a little bit and take in some new content. I thought over the next few posts I’d shine a little bit of light on a few of the sessions that were notable to me.
Fixing What’s Broken in the Essbase JAPI and Reaching New Heights with Groovy
As a programmer, this was right up my alley, naturally. This session was presented by Joe Aultman. Joe is using Groovy to do some automation that would otherwise be done with the venerable Java API. Joe, if you’re reading this, super cool presentation. In my mind I saw this presentation as being about two things: issues with a particular API and issues with a language – namely a lot of “boilerplate” Java code.
As an aside, there is something of a renaissance happening in the Java world with respect to the JVM. As a computer science guy (go Dawgs!) and general purpose programming nerd I have been keeping abreast of this language and several others, particularly Clojure. In a nutshell, what’s going on is this: Sun (now Oracle, of course) created Java many years ago. Java runs inside the JVM, or Java Virtual Machine. Whereas with a language like C or C++ you might compile your C source code into an executable meant to run on a particular system, in Java you just always compile down to the same code that in turn runs on a JVM. In other words, in theory, as long as you have a JVM available for a platform (Windows, Linux, OS X, etc), then you should be able to run the same old byte code. Hence the original notion, “Write once, run everywhere.” In practice there were and are many quirks to this, but by and large the statement is true – which is why generally speaking you are able to download Java JAR and class files that work irrespective of the underlying operating system (rather than separate downloads for Linux, OS X, and so on).
As it turns out, the JVM is useful for more than just Java. New languages that are able to compile down to code than runs on the JVM are able to stand on the shoulders of giants and leverage an incredible amount of infrastructure that has already been written and battle tested. Some of the more notable languages running in the JVM are Groovy, Scala (kind of a streamlined Java), Clojure (a “Lisp” dialect), and Jython (Python running inside of a JVM).
Getting back to Joe’s presentation, I think it’s fair to say that Joe is enamored with what’s called “syntactic sugar” in the programming world. This essentially means that a language provides features or inherent abilities that reduce the need for verbose boilerplate code. Groovy more or less delivers the goods in this regard. Furthermore, Joe has created some idiomatic Groovy enhancements specifically for the Essbase Java API that reduce the need to include some “clutter code”.
I definitely liked what I saw, although as an apparently diehard Essbase Java API guy I don’t think I’ll be switching anytime soon (you’ll convert me yet, Joe!). If you didn’t make the presentation then definitely give his slides a look. Joe is working through the red tape in his legal department to be able to post his code under an open source license. Joe, if you haven’t picked a license yet, give me a call and I’ll help point you in the right direction if I can.
In any case, nice job on the presentation, man.
In other news, I have been working a little bit on the side on a wrapper for the Essbase Java API that repents for some of its sins and modernizes the usage a bit more. This is tentatively called Java Essbase Antikythera Layer (JEAL). If you use the Essbase Java API at all you might really like how this simplifies your life. It’s unfortunately a labor of love that I can’t dedicate a lot of time to so if you want to help please drop me a line!