From JQuantLib
| Status
| Retired in favour of v0.0.2
|
| Objectives
|
- Define scope;
- Determine challenges;
- Identify critical issues;
- Initial architecture design;
|
| Results
| This version is deceased due to a major code review needed for adoption of JSR-308. For more information, see DesignTypeChecking
|
| Download
| TAG-0.0.1-RELEASE
svn co https://jquant.svn.sourceforge.net/svnroot/jquant/tags/TAG-0.0.1-RELEASE/jquantlib/
|
| Progress
| Compared with QuantLib-0.8.1, which has 645 .hpp files and 364 .cpp files, JquantLib has currently 77 Java classes translated. It corresponds to around 10% of the entire mission.
|
| Comments
|
- Scope: The first release must be enough for compiling without errors the demonstration program EquityOptions till the line 236, where Black&Scholes model is used to calculate European options.
- Challenges: Create a good proof of concept which expresses well the compromises with a fast and developer friendly code. The implementation must be clean, simple and readable. It must use as fast as possible via the use of primitive types whenever possible in order to obtain good execution time.
- Critical issues
- Strong type checking with semantic information;
- Fast mathematical calculations;
- Multiple inheritance in Java;
- Observable interface (and not Observable class)
- Templates in Java;
- Professional documentation with formulas;
- Java lacks some useful constructions C++ has, such like typedef. This language feature which helps on strong type checking is considered critical for correctness of JQuantLib due to the complexity of the original C++ code and the possibility of mistakes very difficult to identify. The alternatives and the proposed solution is discussed at DesignTypeChecking.
- Producing fast code whilst providing strong type checking is even more challenging, as a double does not have any strong type signature from the semantic point of view of a certain business object. Hopefully, the solution for this problem is partly addressed by DesignTypeChecking. More considerations on performance can be seem at DesignPerformance.
- As the original C++ code uses multiple inheritance whenever necessary, JQuantLib must offer a simple, clean and well documented way to provide this language feature. As you probably know well, multiple inheritance is not provided in Java. The proposed solution for this problem can be seem at DesignMultipleInheritance;
- Observable pattern as it is implemented in the JDK is not friendly for multiple inheritance. Due to this reason, we implemented our own Observable and Observer classes. The solution is presented at DesignObservablePattern
- Templates is a C++ language feature which basically can be understood as a very powerful and flexible macro processor which most of the times is used in a very crypt and over-complicated way by class designers. Our approach for C++ templates in Java is initially try to get rid of them whenever possible. If not possible or not desirable, substitute it's use by generic classes. The discussion is available at DesignCppTemplates
- Javadocs provided by JDK are good but they are far from being a professional artifact for complex projects. In order to provide such artifact for JQuantLib, we added UML class diagrams and mathematical formulas to our documentation. See more details at DesignJavadocs
|
RichardGomes 01:19, 8 February 2008 (UTC)