Update Java version

[stweil]

The goobi-production code still is based on Java 1.5. According to Wikipedia, J2SE 5.0 was released in September 2004.

The current Debian GNU Linux stable uses openjdk-7-jre (I assume this is the same as 1.7), and Oracle officially only supports a free version 8, so 7 and 8 are a must.

As version 7 is now 4 years old, I think support for older versions can be dropped, and version 7 / 1.7 can be used as the new base version.

[claussni]

It's in principle not necessary to raise the source code language level unless we use >1.5 language constructs. But I agree to raise to byte code language level to adopt to more current JavaVM operations and avoid any issues when including third party libraries.

By the way, (Oracle) Java 7 is EOL already.

[stweil]

Are there servers running Goobi.Production with Oracle Java? This might be rather expensive because the prizes which Oracle requests for Java licenses are not cheap (maybe affordable for universities). Don't reply here if you know such servers - tell them to be careful.

[matthias-ronge]

Java 7+ would provide ways to handle file and directory permissions without running scripts. However this is not just done by increasing the bytecode level but would require to rewrite the code accordingly. In addition, it might require the Tomcat to run with sufficient permissions to be allowed to perform these changes, which might be undesired in the sense of server security.

Java 8 comes with a cool feature for wrapping in-line defined runnables on the code level, called “lambda expressions”. Functional programming can inprove performance, but again it would require to rewrite the code accordingly. This is not a real gain in functionality, because implementing runnables is already possible in lower Java versions, it is just much less verbose the new way.

[henning-gerhardt]

Improving code quality is independent from Java language level but a higher language level could help. Changing code without tests which prove that changes are correct are dangerous and introducing new bugs. Removing existing functionality (f.e. shell script support as our instance used heavy modified scripts to run ( f.e. processes directories are distributed to different storage locations)) without a proper replacement could stop using new versions.

Changing language level support is something for major release 1.12.x and not a minor update 1.11.1 which could / should released this month or at least this year.

[stweil]

@matthias-ronge, don't the current shell scripts in FileSystemHelper.java also run with Tomcat permissions? Then only the code would need a rewrite.

[claussni]

I aggree to what @henning-gerhardt said: Rewriting without improved Test Coverage is a suicide mission in current Goobi.

Yes @matthias-ronge, scripts run via FileSystemHelper with Tomcat permissions. Additionally, fiddeling with Tomcat permissions is a no-go in our big, complected Goobi set-up since multiple connected systems exchange data using this permissions.

But I'd still like to welcome a rewrite of this Goobi part. We could come up with a useful Interface design while separating old from new implementations and allow for plug-ins to implement particular file system interactions (e.g. via shell-scripts).

[stweil]

By the way, (Oracle) Java 7 is EOL already.

Maybe it would be a good idea to use Java 8 for the next version then. Package openjdk-8-jdk is available in Debian stable backports, so for my environment that would be possible.

[henning-gerhardt]

Even with Java 7 end of life we should be conservative. Not every user / institute has the possibility to use latest Linux distribution. Java 7 should be OK for next release. If we switch to Java 8 base in next two years, this should be OK too.

[henning-gerhardt]

Removing milestone Kitodo.Production 2.0 as this milestone has needed change to Java 7. Change to Java 8 (or 9) is a goal for a future milestone.

[henning-gerhardt]

Closing as solved for 2.x and master branch for at least Java7 (2.x) or Java8 (master).