Table of Contents
1. Software requirements
1.1 Coding
1.2 Graphics & Audio
1.3 Other
2. Libraries
2.1 Logging
2.2 Command line parsing
2.3 Settings store
2.4 Unit tests
2.5 Benchmark
| Application |
Version |
Download |
| Photoshop |
=CC2018 |
via Adobe |
| Illustrator |
=CC2018 |
via Adobe |
| Visio |
=2016 |
via Microsoft |
This project uses a variety of external libraries. The following list is divided into groups with libraries of the same purpose. We compare the pros and cons amongst them and decide on which ones to use (final decision marked in bold).
We wanted a small logging library that could write to console and a file. Tinylog allows us to do that with an extremely small footprint. It support 5 commons log levels and configuration at runtime.
| Name |
Version |
Pros |
Cons |
| tinylog |
>=1.3.4 |
easy to use (static class), console- and file writer, no dependencies |
no support for tags |
| Log4J 2 |
- |
Huge functionality, solid documentation, support for filters |
too much overhead (we only need simple logging) |
| Logback |
- |
Successor of log4j, |
Based on Java7, not as knows as Log4J 2 also bigger than tinylog |
Initially we parsed the command line argument as strings by hand. The nice part about picocli is, we can annotate any field in the main class and it will become a command line parameter or option. This is very handy for quickly added new ones. As a bonus, the "--help" command is generated automatically with the provided field description.
| Name |
Version |
Pros |
Cons |
| args4j |
- |
Relatively simple to setup, html doc output |
Developed by individual, last release more than two years ago, no multiple name for options |
| airline |
- |
|
Focused on multi command applications |
| picoli |
>=3.0.0-Alpha-3 |
Automatic usage information, simple annotations, optional parameter support |
Creates instance of class to parse arguments |
| jcommander |
- |
Similar functionality to picocli (contender) |
Less documentation then picocli |
Usage: client/server settings, highscore, reconnect.
Settings: Using a textfile based configuration to overwrite default values (no need for recompiling).
Highscore: Save server highscores in a file, read it on server start.
Reconnect: When connecting to a server, write userID and server ip in a textfile in a temporary location. If game crashes file will still be there and client can reconnect automatically. On normal shutdown, file will be deleted.
| Name |
Version |
Pros |
Cons |
| java.util.Properties |
- |
Built in, key/value store, plain text |
Can be slow for large amounts of key/value pairs |
| No alternatives found/needed |
- |
- |
- |
Unit tests are part of our quality assurance concept. JUnit allows us to test all our core components for integrity and make sure the application runs stable.
| Name |
Version |
Pros |
Cons |
| junit |
=4.12 |
Widely used, big community, required/recommended by tutors |
has dependency on |
| mockito |
=2.17.5 |
Used in conjunction with junit, easy mock classes from interfaces |
more overhead, than only unittests - in the end worth it |
| TestNG |
- |
No contender, junit is a project requirement |
|
| Arquillan |
- |
No contender, junit is a project requirement |
|
//FOR FUTURE USE
| Name |
Version |
Pros |
Cons |
| caliper |
=1.0-beta-2 |
Recommended by Research Assistant, developed by Google, simple annotation of function to get benchmark |
|
| spf4j |
|
Powerful performance testing framework |
Has too many features and is harder to setup |
| javasimon |
|
Very simple framework |
Has only 2 functions, stopwatch needs to be started and stopped manually |