FAQs

What JQuantLib is about?

In a nutshell, JQuantLib is a 100% Java implementation which is good for price valuation of financial instruments and value at risk (VaR) valuation.

What JQuantLib IS NOT about?

JQuantLib does not store anything on any kind of medium, which means it is not intended for managing data streams such as stock quotes, etc. JQuantLib does not support directly needs for portfolio management, money management and order management, in spite several functionalities JQuantLib offers can be very helpful in such cases.

Is there a quick start guide? Is there something available for download?

Yes. Please follow these links:

What is the licensing model?

It’s BSD, which basically means that you can commercialize applications you’ve created on top of JQuantLib.

Which version of QuantLib you are porting to Java?

JQuantLib is a Java port of QuantLib v0.9.7 (which is implemented in C++)

Why on Earth are you reimplementing QuantLib in Java?

Quick answer: Because nobody had tried it before with success.

Elaborated answer: If you try to develop applications in Java which talks to QuantLib, you will face certain integration problems which lead to poor performance. This is true that QuantLib offers SWIG wrappers for many programming languages, Java included but, when you try to develop a serious application (not simply a quick proof of concept) you will find very inconvenient situations and very poor performance due to the way low level data needs to be fed into QuantLib via SWIG wrappers.

Why don’t you use SWIG wrappers instead of reimplementing QuantLib in Java?

Due to performance penalties. The previous question explains this topic a bit more.

Why haven’t you used a C++ to Java translator to do it automagically for you?

There’s no translator able to produce a 100% reliable translation. Performance is another issue: in order to perform well, a translation by hand is needed in order to address certain weaknesses Java has. Besides, QuantLib/C++ has so many templates, typedefs and other tricks that an eventual tentative automatic translation would be possibly useless.

Java is slow! Why on Earth are you implementing a number crunching thing in Java?

Quick answer: Well... it is myth that Java is slow!

Elaborated answer: Modern versions of Java can perform even better than C++ in some circumstances. Unfortunately, many Java developers do not know details “close to metal” like C and assembly developers know. Due to this reason, they are not able to produce software which performs well.

Java is slow! The garbage collector is a deadly bad idea!

The garbage collector is your best friend but also your worst enemy. The problem is not the garbage collector itself, but how programmers abuse of the garbage collector or simply do not know techniques intended to reduce utilization of memory which ultimately impacts the performance of the garbage collector.

What’s the relationship between JQuantLib and SKWASH’s JQuantLib?

There’s no relationship between JQuantLib (us) and the example provided by SKWASH called... well ... JQuantLib. We’ve taken the approach to translate QuantLib to Java whilst they’ve taken the approach of writing SWIG wrappers for QuantLib which could be called from Java applications. These are completely different approaches which produce very different benefits.

How can I contribute to JQuantLib?

Please see our Developer’s Guide for more details.
There’s also a list of tasks in our issue management system at http://bugs.jquantlib.org/