Support extra Java for IDEs via EXTRA_JAVA_VERSION

[hohwille]

In some projects we are forced to develop with older Java versions (e.g. Java8).
On the other hand some tools like e.g. Eclipse and its plugins may already require a newer Java version (e.g. Java11) to work.
For some projects this already results in inconsistencies that cannot be resolved by the project:

• they need to have the build with the older Java version
• but with that older Java version Eclipse is not working anymore and still if the project configures an older Eclipse release, the plugin update sites can not be pointed back to older states and those are simply lost and gone.

The only possible workaround for a project might be to conserve a working eclipse with all required plugins archived as *.tgz file and configured as custom-tool or by its own software-repo. However, this will break platform-compatibility or require a large amount of work for the ide admin of that project. The actual idea of devonfw-ide is to automate, make things easier, faster and reduce efforts.

Therefore, with this story we should consider the following:

• introduce a new optional variable EXTRA_JAVA_VERSION
• if this variable is present, the java commandlet will assert that it is different from JAVA_VERSION and install another Java of that version to software/extras/java (EXTRA_JAVA_VERSION) in addition to software/java (JAVA_VERSION). The extras subfolder will prevent that this extra Java will be automatically added to the PATH.
• when an Java-based IDE is launched (e.g. Eclipse oder IntelliJ) and the EXTRA_JAVA_VERSION is present or the software/extras/java directory is present, that will be used to launch this IDE.
• Inside the IDE the default JRE can still be configured to JAVA_HOME (.../software/java) so also when compiling code and running tests the project will use the regular Java (JAVA_VERSION).

Due to continuous updates and the fact that Eclipse and its ecosystem is unwilling and unable to provide stable (e.g. versioned) plugin Update Sites, I see this as a good solution to prevent the problematic project situation described above.
And if it is not for the update from Java8 to Java11 the same problems will follow from Java11 to Java17 and so forth so I see this story as a reasonable future invest for Java project support.