Free, open-source Java library for quantitative finance

[zacksm]

JQuantLib is a free, open-source Java library for quantitative finance.

Check it out

Skills Matter : JAVAWUG:JQuantLib and Financial applications

 

[wildcolor]

As a quantitative finance learner, I know that C++ is widely used in the development. I am always wondering what libraries C++ quants use. :-k

 

[iddqd]

Probably quantlib or something proprietary/obscure.

Try installing the boost library and getting familiar with it, then give quantlib a go. (I haven't read the link but I'm pretty sure it's the "original" that was ported to Java in the OP).

As a quantitative finance learner, I know that C++ is widely used in the development. I am always wondering what libraries C++ quants use. :-k

 

[GoIllini]

As a quantitative finance learner, I know that C++ is widely used in the development. I am always wondering what libraries C++ quants use. :-k

It's interesting you should say that, because that's less the case today than it was a few years ago. You see C# and Java native interfaces (sometimes written in C#) used more and more.

C++ is a higher-risk, higher-maintenance language. You don't use it unless you have the following two cases:

1.) You need extremely high speed or efficiency.
2.) The C++ implementation is going to be faster than an implementation in a more maintainable language like C#.

Even then, you try to wrap a JNI around the code if possible for a Java-based service. The old model of Java front-end, C++ pricing engine back-end is disappearing.

 

[wildcolor]

It's interesting you should say that, because that's less the case today than it was a few years ago. You see C# and Java native interfaces (sometimes written in C#) used more and more.

C++ is a higher-risk, higher-maintenance language. You don't use it unless you have the following two cases:

1.) You need extremely high speed or efficiency.
2.) The C++ implementation is going to be faster than an implementation in a more maintainable language like C#.

Even then, you try to wrap a JNI around the code if possible for a Java-based service. The old model of Java front-end, C++ pricing engine back-end is disappearing.

Thanks for the information as well. Both of the above 2 points are about speed.

I've learned computing in schools for about 6 years. I believe C++ is still the one of the most complicated programming languages. But, if everything is designed properly beforehand, the implementation and the maintenance would not be that difficult.

I've read some of other threads in the forum about difference between C++, c#, Matlib and Java, most ppl suggest that the main reason that c++ is widely used is because of luck --- most of the quant coding work was done in c++.

Anyway, I agree that both C# and Java are neater and easier design and maintenance languages. I am just a little bit surprised to know the c++ back-end is disappearing.

Probably quantlib or something proprietary/obscure.

Try installing the boost library and getting familiar with it, then give quantlib a go. (I haven't read the link but I'm pretty sure it's the "original" that was ported to Java in the OP).

Thanks for the info. It's really helpful.

 

[kinderchocolate]

Try QuanLib, the C++ for JQuantLib.

I think it doesn't matter which programming language you are choosing, as long as it is sufficient to you needs. Having a Java product pricing applet is nice and platform independent!

 

[Daniel Duffy]

With Java, the lack of operator overloading facility (Matrix m3 = m1 * m2) is annoying for some people. Java generics is not at the level of C++ templates or C# generics at the moment. And don't forget Excel integration.

Potential employers seem to ask for C++ expertise.

You can write a PDE or MC solver in Java, but what's the point? I have seen very few discussions on option pricing in Java.