Although I haven’t had much time to work on QuickFIX/J since handing off the project leadership to Smart Trade, I still have many ideas about how the library could be improved. One feature I’d like to see added to QuickFIX/J is message representation plugin support.
The current implementation of QuickFIX/J uses the message representation defined by QuickFIX JNI implementation (no longer supported by the QuickFIX C++ project). The representation is not idiomatic Java and this not only makes it’s more difficult for Java programmers to work with but also increases the challenges when processing QuickFIX/J messages using other Java tools. Since compatibility with previous versions of QuickFIX/J is desirable, the existing message presentation would continue as one of the supported plugins. Another simple, but useful representation would be a java.util.Map where groups are represented as lists of nested maps. This would not be a particularly high performance representation but would be much easier to use than the current representation. For higher performance, it may be possible to pull data directly from the message byte buffer when it’s requested. The point is that plugin support would allow QuickFIX/J to support various ease-of-use versus performance trade offs.
Continue Reading »
Christian at the Carbon Five Community recently published an interesting blog article on Multithreaded Testing. Christian showed how to use Java 5 built-in concurrency features to create a nice, clean multithreaded test for an article dispatcher. It’s a good example of using the Java concurrency features, but I wondered about the effectiveness of the test.
The implementation of Article class was not thread safe. This was acceptable because of the assumption that the ORM library would be creating the Article instances in the requestor’s thread. However, those types of assumptions can be dangerous over the long term. Let’s pretend that the performance of the ArticleService was not good and a developer was given the task to increase its performance. To simulate this scenario, I created an implementation of the ArticleService that stored Article instances in memory (as if they were cached or if a framework like Terracotta were being used). The Article class should be thread safe for this implementation, but it wasn’t modified. We hope the test case will fail with the incorrect code. However, the test succeeded almost every time on my dual core workstation. Why was that?
Continue Reading »
Multiple processor and multicore computing platforms are becoming very common and most programmers are aware that special Java programming techniques are required in these environments. A popular technique is to ensure that your code always executes in a single thread. It’s a reasonable strategy but it’s very easy to unintentionally violate that constraint.
Consider this scenario. Let’s say you have created an InvoiceProcessor class that maintains a count of how many invoices have been processed. The class uses this count for logging purposes. Let’s also say the server is implemented using a Spring IOC container and a single-threaded JMS message listener container. The architect designed it this way to eliminate the need for the programmers to worry about concurrency issues. Or so he thought.
Continue Reading »
This weekend I attended the Groovy and Grails Experience (2GX) conference. I had done some Groovy scripting and had played with Grails a little. However, this was a good chance to dive into some more advanced topics like Groovy metaprogramming and Grail’s GORM.
My favorite talk was Glen Smith’s overview of Grails plugins for Rich UI support, search, Ajax and more. It was a very informative and fun presentation.
The speaker’s panel discussion was one of the best I’ve seen. One of the most controversial questions was about Groovy, JRuby and the relative impedance mismatch with the Java Platform. Neil Ford of Thoughtworks initially took the position that there was no impedance mismatch with JRuby. Graeme Rocher and others listed numerous examples of where JRuby was less integrated with Java compared to Groovy. Graeme commented that although JRuby can access compiled Java classes, it is much more difficult (impossible?) for Java to use JRuby classes. Groovy classes are Java classes and so they can be used relatively transparently in Java programs.
Speaking from experience, I’ve tried to use Java libraries (QuickFIX/J) using JRuby and it has proven much more difficult than with Groovy. One issue was insufficient (and somewhat outdated) documentation about how to integrate JRuby with Java classes outside the “java.*” packages. This was a few months ago so maybe the documentation has improved. However, with Groovy I was able to use the Java libraries within a few minutes.
I agreed with a point that Neil made that having some competition in the JVM dynamic language arena helps everyone. I highly respect the work the JRuby team is doing although I believe that Groovy is a better and more pragmatic dynamic language choice for Java developers.
I recently had the opportunity to participate in a panel discussion at the O’Reilly Money:Tech conference. We discussed the extent that the financial technology community had embraced open source. Other members of the panel were Tim O’Reilly of O’Reilly Media, James Altucher who founded StockPickr and Graham Miller of Marketcetera. I was representing free financial open source software developers in my role as founder and project lead for the QuickFIX/J project.
There’s no question that open source technology is used widely in financial applications, especially for middle components. However, there was also a discussion about how willing the financial companies are to open source their own technology (where “technology” might include algorithms and research rather than just software).
I don’t believe any company intends to sacrifice a competitive advantage by converting their technology to open source. For that reason, I doubt that we’ll see financial companies releasing algorithms or proprietary research. However, financial companies are involved in open source in a variety of roles. The user role is probably most common today, but a few financial companies have contributed to open source. One example is the Advanced Message Queuing Protocol (AMQP) effort started by JP Morgan and others. This technology benefits financial software (and software from other domains) by provides a programming language-independent and vendor-independent wire protocol for message queues. For this technology to be successful it must be widely used. An open source strategy has a clear advantage here.
Another example is the Open Financial Market Platform (OFMP) which has recently become an Eclipse Foundation project. In this case, I’m not so clear about the benefits to the company contributing the initial code. Maybe someone from the project will comment.
Tim O’Reilly closed the panel with a suggestion that open source developers consider projects that make it easier to capture and process the vast amounts of unstructured data available on the net.
