Update google java format to 1.9

[anuraaga]

We previously couldn't due to building on Java 8 but now we never do so.

[anuraaga]

Ah interesting - since the toolchains only apply to compilations, it doesn't help with google java format since that's actually loaded into Gradle itself. So to do this, we would need to finally deprecate support for building on Java 8 completely. I'd recommend it to avoid getting stuck with old build tooling like we currently are.

[jkwatson]

I can't imagine why requiring java 11 for building would be a problem, but it's worth asking if anyone would have a problem with it. @carlosalberto ?

[jkwatson]

minor conflict to be resolved on this one, as well.

[trask]

fwiw, requiring Java 11 for building will match instrumentation repo

[carlosalberto]

So I'm a little confused now. In CONTRIBUTING we mention we run under Java 8 (and my tests failing seems we are already broken for Java 8).

Maybe it's because I've been out of the loop, but I feel like we increase the required version of Java every month ;)

cc @bogdandrutu

[anuraaga]

We run tests on Java 8 in CI and they pass fine. We were building on Java 8 on Circle CI and they passed too despite some log messages which you noticed until https://github.com/open-telemetry/opentelemetry-java/pulls?q=is%3Apr+is%3Aclosed which should have fixed that so no log messages. Now we are finally proposing actually requiring modern Java to build.

But TBH I'm getting really tired of the continued barriers from the old guard who don't help with this repo at all but only criticize and block the doers and active maintainers. This ownership problem needs to get solved - my recommendation is to remove maintainers that don't actually maintain.

[Oberon00]

I think requiring Java 11 for building is totally fine. We can expect devs to have a new Java version available. However, of course (hopefully) we still want to support executing applications using opentelemetry-java with a Java 8 JVM.

[Oberon00]

But TBH I'm getting really tired of the continued barriers from the old guard who don't help with this repo at all but only criticize and block the doers and active maintainers. This ownership problem needs to get solved - my recommendation is to remove maintainers that don't actually maintain.

This is off topic here. I think this was just a small misunderstanding here.

[kenfinnigan]

+1 to JDK 11 CI/build, but JDK 8 source compatibility

[Oberon00]

but JDK 8 source compatibility

I would not even care about JDK 8 source compatibility only JDK 8 target compatibility, but unfortunately they are tied together 😃

[bogdandrutu]

As long as we are Java8 source compatible it is fine.

[carlosalberto]

We run tests on Java 8 in CI and they pass fine.

Definitely not locally here. Java 11 runs fine though.

But TBH I'm getting really tired of the continued barriers from the old guard who don't help with this repo at all but only criticize and block the doers and active maintainers. This ownership problem needs to get solved - my recommendation is to remove maintainers that don't actually maintain.

I'm not going to answer here, but please feel fee to raise an actual issue, either in this repo or with the GC ;)

To be clear: if we are going to require a newer Java version to build, I'm fine, but this needs to be documented (and as long as Java 8 code can still run against us, etc).

[Oberon00]

Definitely not locally here. Java 11 runs fine though.

There might be some extension packages that require Java 11 IIRC. But the core SDK should work with Java 8. Otherwise I think it's a bug.

[jkwatson]

Looks like it needs a rebase, @anuraaga . Then, let's do it.

BTW, the main branch does currently built for me on java 8, but this one does not, so this will definitely need a doc update, after merging.

[anuraaga]

Thanks added an update to CONTRIBUTING.md

Sorry for going off-topic - I read a comment and probably missed the sarcastic intent, but triggered a general feeling of lack of support from some members. But it's no problem, sorry about that :)

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (master@5e31e99). Click here to learn what that means.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##             master    #1854   +/-   ##
=========================================
  Coverage          ?   85.65%           
  Complexity        ?     1446           
=========================================
  Files             ?      175           
  Lines             ?     5596           
  Branches          ?      581           
=========================================
  Hits              ?     4793           
  Misses            ?      603           
  Partials          ?      200           

Impacted Files	Coverage Δ	Complexity Δ
.../src/main/java/io/opentelemetry/OpenTelemetry.java	100.00% <100.00%> (ø)	12.00 <0.00> (?)
...emetry/sdk/extensions/otproto/TraceProtoUtils.java	76.19% <100.00%> (ø)	6.00 <1.00> (?)
...pentelemetry/sdk/metrics/InstrumentDescriptor.java	100.00% <0.00%> (ø)	2.00% <0.00%> (?%)
...a/io/opentelemetry/exporters/otlp/SpanAdapter.java	95.95% <0.00%> (ø)	20.00% <0.00%> (?%)
...pentelemetry/sdk/common/CompletableResultCode.java	98.30% <0.00%> (ø)	25.00% <0.00%> (?%)
.../opentelemetry/sdk/resources/ResourceProvider.java	100.00% <0.00%> (ø)	2.00% <0.00%> (?%)
...va/io/opentelemetry/opentracingshim/TraceShim.java	100.00% <0.00%> (ø)	3.00% <0.00%> (?%)
...lemetry/exporters/otlp/OtlpGrpcMetricExporter.java	53.93% <0.00%> (ø)	6.00% <0.00%> (?%)
...in/java/io/opentelemetry/trace/PropagatedSpan.java	79.16% <0.00%> (ø)	17.00% <0.00%> (?%)
...ntelemetry/exporters/prometheus/MetricAdapter.java	92.98% <0.00%> (ø)	15.00% <0.00%> (?%)
... and 167 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5e31e99...f3a7329. Read the comment docs.