Monday, June 04, 2007

Is OpenOffice too late with the Java-bindings ?

I remember my first "important" job at my previous employer was to maintain some in-house Office-based application. Nothing like Excel and VBA to ruin your day ! Well, I was a rookie so I couldn't refuse but it was a depressing experience.

For some time now (I remember I was running some samples last year), OpenOffice has some nice Java bindings (or API). Now, this is all great, but the actual code looks quite arcane.

What troubles me is this: why was OpenOffice so late with this move ? I mean, most programmers don't want to live inside Excel and Visual Basic so if you have a choice, you move a simple dedicated "application" from Excel + VBA to OpenOffice + Java.

I guess it's obvious Java is a better choice (than VB) for most programmers (it would have been for me) and the final product would have been better in so many ways:
  • More happy programmers that they don't have to use VB or (oh, the horror), maintain VBA.
  • A decent codebase for your initial small application in Java, that could, potentially be migrated to a full Swing application (if we just treat OpenOffice Calc or Write as the GUI toolkit). I mean, most code will get thrown away anyhow, but it's quite a waste of time reimplementing the same business logic (with the VB code as a reference). This would be a perfect change to actually use the IDE's refactoring.
  • Possible introduction of OpenOffice in the corporate ! Sure, people would still copy-paste from your "application" into Microsoft Excel but that should be quite pain-less. But the developer won't have to worry about a new Office version or some other Microsoft-specific (DLL) nightmares.
But, today, making desktop applications with OpenOffice (in the same style like Excel + VBA + VB DLLs) seems less of an option:
  • it's really hard (look at the API) and the practice isn't actually encouraged. The 100% Java purity had probably done more wrong than right here and most people will just suggest using some Swing Application or framework like NetBeans Platform. But why shouldn't people do this kind of applications ? Most internal apps have some sort of tabular data and lists and then fancy reports. Why should we struggle with JasperReports and such when you have the nice OpenOffice Writer codebase ? Export to PDF: check, export to tons of other formats : sure!
  • OpenOffice doesn't provide a nice "platform". Something to put in a folder with all the jars and DLLs and work flawlessly. I don't need to "install" OpenOffice: I just want to distribute my application as a simple ZIP file. No DLL hell, no nothing. Make that with (Consumer) JRE included and a simpler API ! (this is linked to the previous point).
  • We have reached the point where tiny web-apps seem good enough and are developed fast enough to give existing Excel-based tools a short lifespan. This is a good way because we get rid of Excel but people still need to reinvent the same things over and over: charts and nice (PDF) reports that OO Calc should have facilitated (do I hear OpenOffice-based rich-client ?).
I think OpenOffice missed the boat by a lot for standalone (tabular) applications and it would have been a really nice thing for everyone ! Maybe even for Microsoft since it would have put to death the abomination known as VB 6.

Sure, this would have destroyed the purity of your application, mixing it with the OpenOffice native code and maybe even with some other COMs but I think it would have been better overall.

No comments:

The case of the different jsch 0.1.54 binaries

As part of the Apache NetBeans IP clearance we are combing through all the code and dependencies. One interesting thing we bumped into wa...