Looking back and thinking on my first major project coming out of college: AptPlot, a WYSIWY plotting tool written in Java.

AptPlot was originally developed as a fork of Grace at Applied Programming Technology (APT) before it was ultimately acquired by ISL. As an employee of APT, I was the original and sole developer tasked with porting the entirety of APT's Grace-based offering to Java.

AptPlot home

Background and Impetus

Before AptPlot existed, APT had developed a fork of the plotting tool Grace (named AcGrace) that extended Grace with support for reading simulation plot files from thermal-hydrualic codes like TRACE and RELAP5. AcGrace was a powerful plotting tool for analyzing simulated outputs, including a wide suite of visualization tools, data analysis utilities, and scripting capabilities for heavy number crunching. But AcGrace had several significant drawbacks:

• Development was challenging. Grace, and by extension AcGrace, were written in C on top of X/Motif. Simply building AcGrace took hours and required dedicated hardware.
• Installation was difficult. AcGrace was developed well over a decade before solutions like Windows Subsystem for Linux became available; the only way to get AcGrace running on Windows at the time involved a long, complicated, and error-prone interop with a heavyweight Cygwin installation. The process was so onerous that AcGrace users would ignore updates simply to avoid going through the installation process again.
• While not an issue per se, Grace is licensed under the GPL v2. This meant the entirety of AcGrace, including the analysis code-specific extensions, needed to be released under the GPL. While some solvers are developed by government grant and are freely available, others are more strictly controlled or proprietary: AcGrace could not support their plot file formats under the GPL.

AptPlot set out to solve all of these issues the way many small outfits like APT solved them in 2006: by porting the project to Java.

Java Swing was a natural choice for a desktop application at the time of AptPlot's development. It ran on anything with significantly less platform-specific heartache than most other multiplatform options at the time. APT already had tooling for building and distributing Java applications with point-and-click installation. We could develop updates on any hardware. Compile times dropped by several orders of magnitude, and it was written in a language our developers were already proficient in.

Perhaps most importantly, the JVM class loader made it significantly easier to develop a plugin architecture that allowed extricating proprietary analysis code plot file functionality into closed source plugins. AptPlot could support additional file formats that analysts had been clamoring for, while still releasing the base application as free software licensed under the GPL.

Development

I was the sole developer tasked with porting the entirety of AcGrace to Java, developing the plug-in interface, writing the initial offering of analysis code plug-ins, and creating a suite of standalone demultiplexers for analysis code outputs. Areas that needed to be ported included:

• The base level coordinate systems, graphing engine, and user interface.
• AcGrace's complex typesetting engine. Grace is capable of some very complex typesetting markup since it aimed to be a tool for mathematicians and engineers; there are examples on their site: example 1 & example 2. This was particularly challenging because the X/Motif compile target for Grace set the (0,0) canvas coordinates origin on the bottom left and drew text from the glyph box upper left, where Java has origin in the upper left and positions text from the left baseline.
• AcGrace's scripting language, originally built from Lex & Yacc sources. The Lex files had been lost along the way and the parsing logic had to be converted by hand. For the Yacc definitions we generated the Java symbol tables with BYACC/J. We had to make some modifications to account for symbol tables hitting the 64 KB function size limit. All static variable declarations occur as part of an implicit static function; I had to modify BYACC/J to break table declarations up into multiple static methods.
• Translating multiple complex math libraries, which themselves were machine translated from Fortran 77 to C with f2c. Do you know how f2c handles Fortran arrays starting at index 1? It passes all arrays as typed pointers (e.g. float* foo), decrements then on entry (foo--) so that foo[1] effectively translates to foo[0], and increments them when passing to another function (foo++). If you've seen how many nested layers those old math libraries can get, you can imagine what a fun and exciting time this was.

On top of that, there was developing the plug-in architecture and implementing the analysis code plugins. Each of these could be a blog post on their own. And then there were the demuxers, but I think that is actually grounds for a separate post.

Did I mention I was a college intern at the time? I was a college intern at the time, and successfully porting AcGrace to Java was what got me a full time offer at APT.