Re: Are we embracing Java 8?

We don't have nightly builds, we have post-commit jobs instead, but they mostly serve the same purpose. The post-commit job is simpler, and does not require Yetus knowledge to modify. It is defined by */Jenkinsfile*, which uses / *dev/docker/Dockerfile.multibranch *. You need check if the Yetus

Re: Are we embracing Java 8?

Thanks Istvan for all the pointers! Do you think switching 4.x nightly (in multi branch) to use JDK 7 only might be less time consuming to configure? That might also be quite helpful at this point given that there is no plan to commit any change to 4.x which is not compatible with Java 7. Hence,

Re: Are we embracing Java 8?

Some thoughts on Yetus: The only limit on what we can do is the load that we put on the ASF infrastructure, but that is a rather hard limit. The Yetus precommit check does not by default run the unit tests, but I hacked the personality to add the unit tests to it to preserve the old behaviour.

Re: Are we embracing Java 8?

Based on a recent incident, I thought of bumping this thread. I agree with Chinmay on using JDK7 for our 4.x builds. Now with Yetus support (after last discussion on this thread), maybe we can consider supporting MULTIJDK environment (JDK7+JDK8) too with parallel execution of precommit checks

Re: Are we embracing Java 8?

Sorry to slightly digress, but based on these discussions, shouldn't we be setting JAVA_HOME to point to JDK 7 in all our builds? Especially based on Andrew's comment above: " *Java 7 is not forwards compatible with Java 8, especially with respect toJRE internals. What that means is if you

Re: Are we embracing Java 8?

Just linking a discussion we had one and a half years back on the same [1], considering nothing has changed since then because Java 7 was EOLed in July 2015 and Phoenix 5.0 was also out, it majorly comes to the point of the inconvenience of working on old code style and extra efforts required to

Re: Are we embracing Java 8?

Yes, a real cluster, ideally a real application. With some stress. Some scale too if it can be managed. > On Apr 22, 2020, at 6:10 AM, Istvan Toth wrote: > > Agreed, making this change only makes sense if we bump the source version, > and also compile Java 8 bytecode, which precludes Java7

Re: Are we embracing Java 8?

Agreed, making this change only makes sense if we bump the source version, and also compile Java 8 bytecode, which precludes Java7 support. Cross-compiling to Java 7 would defeat the whole point of bumping the Java version. Re the test issue: I am pretty sure that If we bump the Java version in

Re: Are we embracing Java 8?

Yes, what I was trying to say is even if you don't adopt 8 language features and specify a source level of 7 when compiling the binaries, there will be other runtime issues. And so sure there's no reason to hold back on source level changes. The runtime compatibility story will change

Re: Are we embracing Java 8?

Hi! Actually, the convenience binaries would be the least of a (hypothetical) Java7 user's problem. The whole point of moving 4.x to Java8 would be to enable the usage of Java8 features in the project, so almost immediately the 4.x branch wouldn't even compile on 4.x . I would imagine that any

Re: Are we embracing Java 8?

Just to be super clear: > Compile the code with Java 8, then if someone tries to install the resulting binaries into a HBase convenience binary release 1.x, which will have been compiled with Java 7, the regionserver will abort. ... if the code is running on Java 7. I don't know if anyone is

Re: Are we embracing Java 8?

The main problem you will face is the convenience binaries. If you are planning to move to Java 8, for 4.x branches, then you will no longer be able to make binary convenience releases compatible with any HBase 1.x convenience binary, even if you don't adopt any Java 8 language features. Compile

Re: Are we embracing Java 8?

> All supported HBase versions support Java8. (Just checked) Good point Istvan. I was not aware of that. If so I'll think option 3 is still on the table for Java 8 adoption in Phoenix. > Do we know of any major 4.x users (looking at SFDC mostly), who are still > running HBase/Phoenix with Java 7

Re: Are we embracing Java 8?

Hi! Given that in a few months we will be in the awkward position where HBase 1.x mandates Java 7 support, but even OpenJDK will have Java 7 EOLed, this may actually be a good time to revisit the decision to keep 4.x on Java 7. All supported HBase versions support Java8. (Just checked) Do we

Re: Are we embracing Java 8?

Thanks for the comments, Geoffrey. I guess the option 3 is not preferred by anyone. For option 2, I did not know community has discussed on this and the conclusion still holds today. Glad to know. If timing is good, someone can reopen this conversation later. On Fri, Apr 17, 2020 at 1:32 PM

Re: Are we embracing Java 8?

Mingliang, The topic's come up before, and in the past the conclusion has been to keep our Java requirements in line with the HBase dependency of a given branch. Since HBase 1.x supports Java 7, and HBase compatibility guidelines don't allow for making JDK requirements more strict within a major

Are we embracing Java 8?

Hi, I filed PHOENIX-5855 to make the code more Java 8. This may apply to master branch only and Istvan Toth expressed concern about backporting conflicts. I guess this is the trade-off between embracing newer Java platform (Java 7 is EOL and