Update to Java 8 regarding the library/API usage

[simonharrer]

• Java IO with Java NIO (File -> Path) (available since Java 7)
  • Reason: more type checking instead of String parsing, more exceptions instead of indicating failure through a boolean return type
• Date/Calendar with java.time (available since Java 8)
  • Reason: java.time uses immutable constructs, whereas Date/Calendar has state and is probably the worst Java api ever
• Use prepared statements instead of simple Strings (available since quite a long time) of the JDBC API
• Use Optional instead of returning null

[Siedlerchr]

Refs: #1146

[oscargus]

@Siedlerchr are there thing in #1146 that should be fixed or is that an example of Java 8 features being used? Just so I do not merge it with issues.

[simonharrer]

I do not think the PR is really related as the contains key method has existed for a long time.

[Siedlerchr]

@oscargus @simonharrer Noo, your PR is alright 👍 I just thought this issue will be a more general "Things to use / don't use", not only limited to Java 8

[simonharrer]

I think this is something we can try to work on towards the next JabRef release.

[Siedlerchr]

I also noticed some other things regarding BufferedWriter etc.
There are some new handy methods in the Files class which could be used. (e.g. Files.newBufferedReader/Writer/Stream...

[simonharrer]

Yes, this is part of the NIO.

Basically, all of this is technical debt we should pay back instead of paying the interest rates. :)

[oscargus]

There is a Java 8 (java.time) date picker at https://github.com/LGoodDatePicker/LGoodDatePicker

[koppor]

Usage of prepared statements should be solved by #1451.

[lenhard]

I'll close this for now. We pay attention to this all the time whenever we change a feature or add something.

However, we will not go to the entire code to replace every feature. Therefore, we do not need an issue to track the progress of this.