This example system is about a calculator tool, which is able to calculate the greatest common divisor (http://en.wikipedia.org/wiki/Greatest_common_divisor) as well as the square root (http://en.wikipedia.org/wiki/Square_root). It contains customised product copies, that can be used for case studies, e.g. in the context of difference analysis, clone detection, migration support, or other evolutionary researches.
If you have any questions or feedback about this software, feel free to contact us:
- Benjamin Klatt http://sdq.ipd.kit.edu/people/benjamin_klatt/
- Klaus Krogmann http://sdq.ipd.kit.edu/people/klaus_krogmann/
Product Copies included in this software
The case study consists of two implementations:
- Native Java API and (BigInteger, Math) based implementation
- JScience Library (http://jscience.org/, http://java.net/projects/jscience) based implementation
The former, native java implementation does not require any additional libraries and for this requires less storage (~665kb for jscience.jar) which might be relevant e.g. for the deployment on mobile devices.
The latter, JScience implementation claims to provide better quality attributes especially for 64bit but also for 32bit systems (quotes taken from http://jscience.org/):
- Low-Level Concurrency: To take advantage of multi-core processors automatically. Our benchmark indicates that on a dual-processors our Matrix<Float64> or Matrix<Complex> multiplications are the fastest around (for a pure Java library).
- Stack allocation: To reduce garbage collection, decrease memory footprint and increase scalability.
- Real-Time Behavior and Compliance: JScience can safely be used with RTSJ VMs (www.rtsj.org) without resulting into memory clashes or illegal access exceptions.
Especially the LargeInteger class which is used instead of BigInteger (cite from JavaDoc version 4.3):
- Optimized for 64 bits architectures. But still runs significantly faster on 32 bits processors.
- Real-time compliant for improved performance and predictability (no garbage generated when executing in StackContext).
- Improved algorithms (e.g. Concurrent Karabutsa multiplication in O(nLog3) instead of O(n2).
The scenario is motivated based on the tradeoff decision between better performance of the JScience library versus the additionally required storage for the jar file which might be negative e.g. for embedded devices, such as mobile apps. However, JScience is released under a well usable BSD license, but other external libraries might be available only under very closed licenses, such as GPL. This might represent another motivation to release the "community" edition of a software with a free GPL library but the enterprise release with a library that might require license fees.
This calculator represents a basic example and the tooling itself might not be useful in production. However, it focuses and demonstrates a typical scenario which the case study should focus on. To focus on the scenario under study, the calculator is limited in:
- its implementation itself (e.g., only few code, string based value passing, user interface)
- the calculation performed (the calculations of the GCD and square root are very simple compared to other mathematical operations)
- the differences between the implementations (there are only a few, very local lines of code are modified)