Optimization

[MrTigreroux]

• Improve MessageUtils#getMenuSentence.

• Use OOP for config files, move many methods of ConfigUtils and ReportUtils in a Config class extending an abstract class named ConfigFile.
  Parse and store data in a Java way (for example, store "none" value as null, "yes"/"no"/"true",... as boolean, ...) in 2 classes: Config and Messages.
  Multi-line messages should be saved as a single String and not String[] because of the placeholders. Indeed, with a String[], we would need a wrapper to allow to write something like replace(placeholder, value) on the message. That wrapper would execute the String replace operation on each String of the array, creating new strings that would need to be put in a new String[]. The wrapper overhead, the replace operations executed on several Strings instead of only one, and the creation of a new String[] are likely less efficient than the simple String replace then split operations.

• Study optimization of placeholder filling in messages.
  Could try to define a class per message, holding the values with the fields name matching the placeholder name ("Placeholder " is replaced with the value of field placeholder).
  Each message line would be saved as a String[], containing all the non placeholder text. An other array would store the fields (placeholders) reference to concatenate between each element of the String[]. Getting a message line would simply consist of reading the String[], join it with the placeholders values that are in the class instance provided, placeholders that we know thanks to the array holding the references of the placeholders to use at the right place.

Example:
"a _P1_ b _P2_ c"
String[] = ["a ", " b ", " c"]
placeholder references = [1, 2]
message class { String p1; String p2; }
used with: messages.msg1.get(new Msg1Values("p1", "p2"))

Is this approach better than the current approach (String#replace every placeholder) ? There would be a probably significant memory overhead because we store 2 arrays, create a new object, use reflection to get the values.
But the String#replace operation creates a new String each time.

Conclusion: big overhead and time consuming for defining all the "MsgXValues", for reflection, making the formatting process more rigid, without offering any meaningful advantage.

• Optimize cache system: group SQL queries for nonArchived, opened and archived reports. Cache reset each x minutes. Only one instance of Report per report id at a time.
• Create a PaginatedMenu and move all the page logic there (getPageDisplayerItem(), ...).
  This is actually more difficult than that, because of ReportManagerMenu which allows to have the report instance automatically accessible in the implementation of menus, and not all of those menus are paginated.
  Could create an abstract class like MenuDataProvider(Menu menu), which would be optionally provided to Menu, called at opening, check and closing... Mutual dependency. In all menus needing ReportManagerMenu, replace call to "r" with "reportProvider.getReport()".
• Fix comments multi pages and optimize it.