Why reimplementing liblouis in Java is a waste of your time
There are some proponents of the Braille in DAISY Pipeline 2 project who would like to re-implement liblouis in Java. While I would much rather hack in Java than in C I still think it’s not a good idea to re-implement liblouis in Java.
Let’s first have a look at what liblouis is:
- Liblouis is a library and a set of tables that translates text into Braille.
- But first and foremost liblouis is a community of likeminded people from all over the world who work together to improve the state of Braille translation and formatting.
That is the key: it’s a herd of cats. They work out of their own self-interests, bottom-up and you cannot steer them. All the specifications in the world aren’t going to change that.
They work on liblouis because it might work for their language. It might run on their device. And quite likely it can be interfaced from their favourite programming language.
A major part of the existing implemetation is that it is written in C. This means that it runs on virtually any device from embed to server and interfaces to virtually any programming language from PHP to Java.
If you re-implement liblouis in Java you will loose many of these benefits. Most of the community will stay with the C-based implementation as that one is usable on their device and from their language.
You are creating a fork with all the problems that come with that. You will be doomed to trace all the changes that go in to the C-based implementation so you can stay compatible with the tables.
And what is the gain? Why would a Java-based implementation better than one written in C (aside from the fact that Java is “nicer” and providing a perfect example of the not invented here syndrome)?
Liblouis and its Java API is used by dozens of organisations around the world (Bookshare, American Printing House for the Blind, SBS, Torch Trust). It is included in many braille embossers (ViewPlus, Index Braille). And it is used every day by thousands of users in the form of the NVDA screen reader and the Google Chrome browser which includes liblouis for braille. Why do we have have to re-implement something that is battle-tested and works perfectly well?
I would argue that a much better approach would be to invest into the test suite of liblouis to get the best quality out of it we can in any programming language. Let’s not waste our time and money, so let’s work with the community instead of against it.