Hanging Out with Old Friends: SWT and JFace
I’ve been working on a new project at work that deals with files in X12 format: delimited files that generally use asterisks for field delimiters and tildes for line delimiters. Here’s an example fragment:
ISA*00* *00* *ZZ*XXXXXXXXXX *01*030240928*100803*1628*U*00401*000091929*1*P*:~ GS*HC*XXXXXXXXXX*030240928*20100803*1628*91929*X*004010X096A1~ ST*837*00411452~
The way to interpret this file is that each line is a segment composed of elements. The first element in each line, called the zeroth element, names the segment. For example, the first line in the segment above is the ISA segment. The segment then breaks down into its elements, like this:
Index | Element |
---|---|
0 | ISA |
1 | 00 |
2 | |
3 | 00 |
4 | |
5 | ZZ |
6 | XXXXXXXXXX |
7 | 01 |
8 | 030240928 |
9 | 100803 |
10 | 1628 |
11 | U |
12 | 00401 |
13 | 000091929 |
14 | 1 |
15 | P |
16 | : |
When someone wants to refer to the segment containing the “ZZ” above, for example, they call it the ISA05.
Well, I quickly got tired of counting between asterisks to determine which field was the ISA13, or the GS08, or whatever, so decided to write a tool to parse the segment for me and tell me which value was which. Since we do all our Java development in Eclipse, writing an Eclipse plugin was a natural choice — especially because I could then share it with my Windows-using coworkers.
The result is X12 Segment Split View, available as an Eclipse update site (http://grailbox.com/eclipse). Also, you can get the source from github (http://github.com/hoop33/SegmentSplitView). The way it works is it polls your clipboard once a second, and if it detects an X12 segment (well, if it detects text that has at least one asterisk), it pulls, parses, and displays it. Read more on the Downloads page on this site.
I hadn’t written any SWT or JFace code in over five years, so I was a little fuzzy on how to get this tool written. Now comes the surreal part: I cracked open an electronic copy of The Definitive Guide to SWT and JFace and read words I wrote over six years ago to figure out how to write this code! It felt a little weird to have me-from-the-past teach me-from-the-present how to use the technology, but it worked (quickly, I might add) and now I don’t count segments anymore!
As an exercise and to have a feel of how swt works, I’ve rnecetly tried to port a Swing app I’ve been working on lately (allowing to view -potentiallybig, >100Mb- log files in a tabular format).I finally gave up for at least 2 reasons :- the swt approach is very different from swing’s one : the former is controller driven, and the latter is model driven, which suits me better.- for this kind of app swt approach consumes approximately twice as much memory as swing Explanation : I’m visualizing LogEvent objects in a JTable in the swing version. So at any time i only need to have in memory the LogEvent, and whenever a redraw happens, TableCellRenderers create temporary strings to display the visualized part of the table.Whereas in the swt approach, I need to create a Table with all the strings. Thus the events are instanciated twice : once in my model , and once in the Table.In conclusion, and for this app, the swing approach needs about twice as much memory as the log i’m visualizing, and the swt approach is more like 4 times the size, which is way too much