switch to jdk 8

[jangalinski]

I know we had this discussion i the past, but I want to get back to it.

Here are some numbers I stumbled upon: http://www.baeldung.com/java-8-adoption-march-2016

I just cannot imagine, that anyone will start a camunda-spring-boot project in 2016 using Java < 8.

So if we switch in this extension, we could benefit from the new language features and provide clean, state of the art examples. All this null checking and for-looping feels so 2k-ish ...

see also https://forum.camunda.org/t/java-8-in-community-extensions-please-say-yes/886

[osteinhauer]

Hi Jan. I know there are Java < 8 runtimes 😞 Think of the people running IBM WAS for example. I am still sure that it wood be good to separate the starters compile level from the examples compile level to provide examples using Java 8.

@hawky-4s- : I remember there were some issues to have different JDKs for starters and examples. How can we achieve different JDKs anyway?

[jangalinski]

I am 100% sure that no one who starts working with camunda and spring-boot will work with anything else than Java8. This extension is not addressing legacy systems like WAS. All other Java version are no longer supported anyway ...

Regarding separation of examples and extension: we could use different repositories or separate pom structures.

[osteinhauer]

As long as spring and camunda are supporting Java 6 the boot starter(s) should do this too as long as there dependencies do. I cannot see any issue with that. The code is only doing configuration magic.

So if we switch in this extension, we could benefit from the new language features and provide clean, state of the art examples.

This can be reached by separating examples from extensions.

[osteinhauer]

Another possibility could be Animal Sniffer which I found in a interesting blog post How Spring achieves compatibility with Java 6, 7 and 8. Using this we could compile with JDK 8 and check if extensions are JDK 6 compatible while using full feature set in examples.

[jangalinski]

I obviously have a different opinion ... a community extension must not support the same jdk levels and "legacy" platforms the core product has to. We already use JDK7, so we are not fully compatible with camunda-platform anymore ... and following this logic I see no benefit to stick to the deprecated version 7 ... But I do not want to get religious, if no one else has thoughts to share, we are in a stale mate and I then would say: just leave as is, extension and examples on JDK7 for now. @meyerdan , @hawky-4s- , @saig0 ... what do you think?

[osteinhauer]

Seems I am confused now because the fact "we already use JDK7". I've probably known earlier or now forgotten. I checked the camunda-spring-boot-starter-root/pom.xml:

<properties>
   ...
   <!-- camunda and spring use different properties ... -->
   <java.version>${version.java}</java.version>
</properties>
...
   <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <configuration>
          <rules>
            <requireJavaVersion>
              <version>[1.7,)</version>
            </requireJavaVersion>
          </rules>
...

where ${version.java} resolves to 1.6 and configures the compile plugin and maven-enforcer-plugin forces a JDK 1.7 at build time. If I am not wrong this means everything is 1.6 compatible. Am I right?

[saig0]

IMO, I agree with Jan. Everyone who use Spring Boot works with Java 8, in most cases.

[hawky-4s-]

@osteinhauer: Yes you are right, the binaries will be compiled targeting 1.6. But you need 1.7 to run the tests I think. (Tomcat?)

[hawky-4s-]

Regarding the JDK 8 proposal. Personally I'd like to see JDK 8 being used a lot more so I would vote for JDK8.

[jangalinski]

[jangalinski]

Do we want to call a jdk8 release 1.3 or 2.0?

[osteinhauer]

Seems I am outvoted. Do it with release 1.3. @jangalinski Please refactor to use JDK8 features so that it is more than a compiler switch 😉.

[meyerdan]

just a few comments on this:

This is a community project and as such it makes it's own decisions. The opinions of Camunda Employees (like myself) who do not actively contribute to the project are not as relevant as the opinion of an active maintainer such as @jangalinski or @osteinhauer.

My advice for deciding on a question like this is to look at it from a user's perspective. I am building these projects so that users can use them an not for myself. Here, the question is "Can we require Java 8+?". Assume we answer this question with "Yes". Then there are (in my opinion) some reasons which are the right reasons and there are some reasons which are the wrong reason. The right reason is, in my opinion, what @saig0 wrote: "Everyone who use Spring Boot works with Java 8, in most cases." (assuming he is right, of course). The wrong reason would be "I like Java 8".

So I guess, what I am trying to say is: this project probably has very few lines of Code. Whether I as a developer can use Lambdas in there does not make me a lot more productive. That should therefore not be reason we require Java 8. On the other hand, if everybody who uses this project uses Java 8 anyway, well then, why not!

[hawky-4s-]

Maybe initiating a poll in the Camunda forum would be a better source of information than guessing what people use?

[jangalinski]

Like this one: https://forum.camunda.org/t/poll-which-jdk-to-use-for-camunda-spring-boot-applications/1167 ?

[hawky-4s-]

:octocat:

[jangalinski]

So far 7 votes lead to 100% Java8 ... did you vote? If I should start, copy the tone loc meme and I'll start ...

[osteinhauer]

I would feel comfortable with the steps:

1. Separate extension from examples and use JDK8 in examples right now.
2. Do a last release with extension using JDK 6 including:

   • 86

   • 77

   • 47

   • 46

   • 110

3. Use JDK8 at all.

[jangalinski]

We can do the next release without java8. But I would not see any benefit doing the example separation first (separate poms, new build, ...). We do not need all that anymore when the whole extension is on java8.

So I would say: I keep my feet quiet (does that work in english :-) ?) we do a 1.3 on jdk6 and then go for 8 in the next step. Maybe even call it "2.0" then to make it clear. Switching to ProcessEnginePlugins could then also be done in the 2.0 release. Ok?

[osteinhauer]

I would like to see the last issues regarding documentation and architecture to be in the last jdk6 release.

Separation might be misleadingly: In my mind is to compile with JDK8 at all, but use different java versions in compiler plugin (see a950a0a).

[jangalinski]

I created https://github.com/camunda/camunda-bpm-spring-boot-starter/tree/release200 with java8 settings

[osteinhauer]

Seems that our rockets are in the pockets.

[jangalinski]

Imho we should close issues only when they are merged to master ... we have a lot of feature branches and just having some implementation hidden in one them does not mean a feature can be used in the next release. So I will re-open

[jangalinski]

Also: as you mentioned it makes sense to have a look at all implementation that can be improved with java8 so its not just a version number we use. I would like to do this on this issue as well.

[jangalinski]

done and merged