You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Embedding inside Spark still works, @drcrallen to verify
Embedding inside Tranquility still works, @gianm to verify
It's also possible to use Java 8 source and bytecode but I think that's a separate discussion, that IMO should come with some patches that use the new Java 8 features to good effect.
Just to be clear, I'm not intending to drive a change to Java 8 source and bytecode. Just requiring Java 8 JVM at runtime so we can use dependencies that do use Java 8 bytecode (like newer versions of Jetty and DataSketches).
I would be OK with changing to Java 8 source and bytecode as well if the community thinks it's worth it, but that is not what I meant to propose.
I read through the druid-user poll and the two common themes for the "keep java 7 support" vote seem to be:
Concerns about Scala compatibility (we already captured that in this ticket)
Concerns about Hadoop, since a few people are stuck on Java 7 based Hadoop clusters that are seemingly out of their control to upgrade. I can see this being the case for centrally managed Hadoop clusters, especially if the team behind it doesn't upgrade very often.
I'm not sure if this is feasible, but we might be able to keep the Hadoop indexer working on Java 7 runtimes even as the services move to requiring Java 8. The Hadoop indexer shouldn't need Jetty and if we're careful about what other Java 8 dependencies we add then we could possibly make that work.
@drcrallen our "hadoop gauntlet" tests for Apache Hadoop distros run in jdk-7u71. I'm not sure about our tests for other distros, but if the Apache ones work then that's a good sign.
Activity
drcrallen commentedon Dec 6, 2016
See #3328 for byte-code java 8 related stuff.
gianm commentedon Dec 6, 2016
Just to be clear, I'm not intending to drive a change to Java 8 source and bytecode. Just requiring Java 8 JVM at runtime so we can use dependencies that do use Java 8 bytecode (like newer versions of Jetty and DataSketches).
I would be OK with changing to Java 8 source and bytecode as well if the community thinks it's worth it, but that is not what I meant to propose.
[-]Require Java 8[/-][+]Require Java 8 runtime[/+]gianm commentedon Dec 6, 2016
IMO a proposal to switch to Java 8 source should involve some patches that use the new Java 8 features to good effect.
gianm commentedon Dec 14, 2016
I read through the druid-user poll and the two common themes for the "keep java 7 support" vote seem to be:
I'm not sure if this is feasible, but we might be able to keep the Hadoop indexer working on Java 7 runtimes even as the services move to requiring Java 8. The Hadoop indexer shouldn't need Jetty and if we're careful about what other Java 8 dependencies we add then we could possibly make that work.
drcrallen commentedon Dec 14, 2016
@gianm / @dclim do you guys have a test environment setup that could capture a java7 hadoop environment?
tjgiuli commentedon Dec 14, 2016
From Cloudera's documentation (https://www.cloudera.com/documentation/enterprise/5-3-x/topics/cdh_cm_upgrading_to_jdk8.html): "Cloudera does not support a rolling upgrade to JDK 1.8. You must shut down the entire cluster." Pretty unfortunate.
gianm commentedon Dec 14, 2016
@drcrallen our "hadoop gauntlet" tests for Apache Hadoop distros run in jdk-7u71. I'm not sure about our tests for other distros, but if the Apache ones work then that's a good sign.
gianm commentedon Feb 14, 2017
Closed by #3914