I use Moneydance to track my personal finances. Recently Tokyo Mitsubishi UFJ bank decided to drop support for downloading transactions in Microsoft Money format and switched to a CSV format. That is kind of annoying because I like to download my transactions from the bank and jam them into Moneydance. It means I don’t have to type them in. But now they are in CSV format, which isn’t natively supported

There is a beta CSV import extension for Moneydance though, so I tried that out. It has support for formats from some banks, and then has a “custom reader” format that you can use to set up the fields that your bank sends. That worked out well. The problem is that the imported transactions from the bank were garbled. The text didn’t show up as proper Japanese, it was more like goobledegook.

That is a clear indication that the encoding on the file was set wrong. I know the files my bank sends are in Shift-JIS, but I changed the format to UTF-8 in Emacs since UTF-8 is the format that all text files should be saved in. Unfortunately, the extension does not import as UTF-8 and since it does not give an option for selecting the encoding I assume that they just take the platform default or something.

A quick check of the code shows that indeed, they use a Java FileReader (who thought it was a good idea to have the filereader open text files in the platform default encoding? It is never a good idea to assume a default and not allow programmers a way to change it.) So to fix it, you simply need to use a FileInputStream and an InputStreamReader with the encoding set. No problem.

It looks like Google has a SVN repository for the project. I figure I’ll open up Eclipse and use that to make the local change and import my text file. Oh, my version of Eclipse is really old. So let’s download a new version. That was pretty painless.

Now, how do I hook Eclipse up with Subversion? It looks like there are two solutions, the more popular of which is Subclicpse. I was able to install that without any trouble. I was a bit worried about the version of Subversion that my mac came with (1.6.17 according to svn –version) and a mismatch there, but let’s give it a go.

Wait, they don’t have any information telling me how to use Subversion. Well, some British guy wrote something up that makes it pretty clear. Following along with him, I got up to where Subclipse would try to pull down the information and … Some sort of error about a JavaHL library! What? Well, that seems to be pretty well explained on the Subclipse website, so I downloaded JavaHL (the Java subversion bindings apparently) and tried again. Now I get a version mismatch! It says “Incompatible JavaHL library loaded. 1.7.x or later required.” But there were no versions listed on the download page! And by the way, that download from open.collab.net does not list any different versions, only different operating systems! I downloaded the correct version for my version of OSX (I still haven’t downloaded to the latest version) but that did not work! What do I do now? The documentation says that it installs svn itself (it did, in /opt/subversion/bin) but that version is the same as the one that came with OSX by default anyway. So why would there be a version mis-match? Also, they made me register to download their package, which was kind of annoying, but forgivable. As long as they understand that some guy named Fugu Tabetai working as a consultant for Fish Eating Incorporated that makes less that $25 million a year probably isn’t a good business opportunity for them.

A little searching shows that other people have had this problem as well and the solution is to install a newer version of Subversion than the one that open.collab.net installs from wandisco, whatever that is. Apparently wandisco is a subversion provider of some kind. In my case, since I am on 10.6 I needed their 10.6.x package from their subversion download page. After downloading that though, it still seems like I have the same old version of subversion and not some sneaky new 1.7.5 version.

Guess what? Rebooting did not solve the problem either. But doing a sudo rm -Rf /opt/subversion and re-installing the wandisco problem did get me the proper version (after appending /opt/subversion/bin to my PATH) in terminal. So maybe now it will work in Eclipse? Let’s give that a go!

Hey what do you know? It worked! I was able to suck down the code for the CSV importer. Of course, then I realized another problem: since the importer is an extension for Moneydance, I now need to find the Moneydance library files (JARs) that is links against so I can actually compile the thing. Then I have to figure how to compile and package it in the extension format that it needs after I make my changes. Luckily, all of that is available at the Moneydance developer page.

Adding the two JARs in the developer kit did get the project to almost completely compile, except for six errors that popped up. It looks to me like I’m linking against old JARs, because the documentation says that the errors Eclipse is complaining about are not true (e.g., this class doesn’t implement some method, but it shows in the API docs that it does.) So perhaps I downloaded an old version of the developer’s kit somehow. I don’t see how that is possible though; I downloaded the only one that is up there. Well, I’ve posted in the group for the csv importer and will see if that is actually something that they can help me with. If not, I’ll email the Moneydance folks. This should be a simple problem that I can actually fix, and it would improve my life, so I really want to get this done.

After a day’s delay, I heard back from the maintainer of the CSV import plugin and he passed me different versions of the Moneydance development libraries. They were created in 2011 sometime vs 2006 which are the ones that came from the Moneydance website. The project compile successfully with them, so now I have no excuse not to actually add this feature.

The GUI was created in Netbeans’ Matisse which is supposed to be a nice automated GUI creation system. It generates regular old Java code though, so I might as well edit that directly in Eclipse myself and then worry about what to do on the commit later.

I need to modify ImportDialog.java’s creation of a CSVReader and also the one in TransactionReader.java. I did all that, and now I am caught up on the failing unit tests (nothing that I did – these were pre-existing failures) from what looks like a test that can’t compile anyway. After making those modifications and building on my machine (generating my own keys to sign the plugin and all) things looked great, and the import went fine. I’ve sent the changes on to the maintainer, so maybe we’ll see this show up at some point!