Skip to content

Conversation

@mark-vieira
Copy link
Contributor

More Java compatibility issueswith the elasticsearch-hadoop project.

This time we introduced a requirement on Java11 into the 7.x branch. This refactors some things so we can run in a Java8 runtime.

@mark-vieira mark-vieira requested a review from rjernst August 15, 2019 19:53
@mark-vieira mark-vieira added the :Delivery/Build Build or test infrastructure label Aug 15, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

Copy link
Member

@jasontedor jasontedor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a question. I'm pretty sure that we need JDK 8 here from:

org/elasticsearch/gradle/test/ClusterConfiguration has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

targetCompatibility = 11
sourceCompatibility = 11
targetCompatibility = 10
sourceCompatibility = 10
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn’t the source/target compatibility need to be 8 not 10, otherwise we can still get into a trouble if an API from JDK 9 or 10 is used?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be quite honest, It's not clear to me why this is 10 or if it needs to be. There are funny interactions here between this and the Groovy plugin as well. This is simply a revert back to what this was before the problematic commit that caused the hadoop builds to begin exploding. I think it's likely we use Java9+ APIs in .java code but that isn't used by elasticsearch-hadoop at runtime so all is well.

This is admittedly very awkward and the true solution is to fix the hadoop build to bring it up to Gradle 5.x but we've been kicking that can down the road. This PR is just to unblock the snapshot release builds for the time being. Essentially, this is just the minimal change to bring us back to a known working state.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, in that case, I think we need to stop kicking the can down the road. I don't like that we are held back from using modern features because of this. I also don't like that we're making a change it seems we don't fully understand (myself included)? I don't think this change is going to prevent us from making this mistake yet again, breaking important downstream builds for days.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💯 We had a chat about sorting out the hadoop stuff while back, we just need to prioritize that. I'll put this on the top of my list for when I return from PTO.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @mark-vieira. ❤️

@mark-vieira mark-vieira merged commit 1f6cd5c into elastic:7.x Aug 16, 2019
@mark-vieira mark-vieira deleted the hadoop-java-compatibility branch August 16, 2019 01:39
@mark-vieira mark-vieira added the Team:Delivery Meta label for Delivery team label Nov 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Delivery/Build Build or test infrastructure Team:Delivery Meta label for Delivery team v7.4.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants