Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

switch to jdk 8 #98

Closed
jangalinski opened this issue Jun 14, 2016 · 25 comments

Comments

@jangalinski
Copy link
Member

commented Jun 14, 2016

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

@jangalinski jangalinski self-assigned this Jun 20, 2016
@osteinhauer

This comment has been minimized.

Copy link
Contributor

commented Jul 17, 2016

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

This comment has been minimized.

Copy link
Member Author

commented Jul 18, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Jul 18, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Jul 19, 2016

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

This comment has been minimized.

Copy link
Member Author

commented Jul 19, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Jul 19, 2016

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

This comment has been minimized.

Copy link
Member

commented Jul 19, 2016

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

@hawky-4s-

This comment has been minimized.

Copy link
Contributor

commented Jul 21, 2016

@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-

This comment has been minimized.

Copy link
Contributor

commented Jul 21, 2016

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

This comment has been minimized.

Copy link
Member Author

commented Jul 21, 2016

lets do it

@jangalinski

This comment has been minimized.

Copy link
Member Author

commented Jul 21, 2016

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

@osteinhauer

This comment has been minimized.

Copy link
Contributor

commented Jul 21, 2016

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 😉.

@jangalinski jangalinski added this to the 1.3.0 milestone Jul 21, 2016
@meyerdan

This comment has been minimized.

Copy link
Member

commented Jul 21, 2016

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-

This comment has been minimized.

Copy link
Contributor

commented Jul 21, 2016

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

@jangalinski

This comment has been minimized.

@hawky-4s-

This comment has been minimized.

Copy link
Contributor

commented Jul 21, 2016

:octocat:

@jangalinski

This comment has been minimized.

Copy link
Member Author

commented Jul 22, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Jul 22, 2016

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:
  3. Use JDK8 at all.
@jangalinski

This comment has been minimized.

Copy link
Member Author

commented Jul 22, 2016

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?

@jangalinski jangalinski modified the milestones: 2.0.0, 1.3.0 Jul 22, 2016
@osteinhauer

This comment has been minimized.

Copy link
Contributor

commented Jul 22, 2016

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

This comment has been minimized.

Copy link
Member Author

commented Aug 5, 2016

jangalinski added a commit that referenced this issue Aug 5, 2016
@osteinhauer

This comment has been minimized.

Copy link
Contributor

commented Sep 3, 2016

Seems that our rockets are in the pockets.

@osteinhauer osteinhauer closed this Sep 3, 2016
@jangalinski

This comment has been minimized.

Copy link
Member Author

commented Sep 3, 2016

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 jangalinski reopened this Sep 3, 2016
@jangalinski

This comment has been minimized.

Copy link
Member Author

commented Sep 3, 2016

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

This comment has been minimized.

Copy link
Member Author

commented Sep 11, 2016

done and merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.