Conversation
Checked with IntelliJ: Run Inspection by Name > Usages of API which isn't available at the configured language level jaeger-crossdock still requires Java 7 because it calls InetAddress#getLoopbackAddress() (closes jaegertracing#129)
Codecov Report
@@ Coverage Diff @@
## master #132 +/- ##
============================================
+ Coverage 81.41% 81.43% +0.02%
- Complexity 523 529 +6
============================================
Files 90 91 +1
Lines 1964 1988 +24
Branches 196 194 -2
============================================
+ Hits 1599 1619 +20
- Misses 271 277 +6
+ Partials 94 92 -2
Continue to review full report at Codecov.
|
|
lgtm (with we could do reformatting separately). it's ok to keep crossdock at 1.7, since it's just an integration test. @vprithvi could you please review as well? |
|
Sure, I'll take a look later in the day |
There was a problem hiding this comment.
LGTM, but I'm not convinced of the value of moving the entire project to Java 6. Wouldn't moving jaeger-core and jaeger-context satisfy your use case?
Run Inspection by Name >
Usages of API which isn't available at the configured language level
This should be automated so that a future commit doesn't introduce such usages. I've heard good things about the AnimalSniffer plugin for this purpose.
| import java.util.Random; | ||
| import java.util.concurrent.ThreadLocalRandom; | ||
|
|
||
| public final class Java6CompatibleThreadLocalRandom { |
There was a problem hiding this comment.
Could you add tests for this?
There was a problem hiding this comment.
Hard to test this in a meaningful way. Especially since Gradle 3 does not run with Java 6.
If jaeger-zipkin also was 1.6 it would satisfy my use case. But I think it's a bit confusing and inconsistent for developers and users to have a mix of java versions in published artifacts. Also, in the other artifacts I almost had to change nothing. All in all it would make jaeger accessible to a larger user base without much effort.
I tried this plugin but didn't get it to work at first. Was a layer 8 problem ;) |
|
#131 also is important for java 6 compatibility as the currently used ot-api version (0.15.0) is not java 6 compatible while the recent one is. |
| * Note that you need to install thrift 0.9.2 on your system for this task to work. | ||
| * | ||
| * If you are using macOS, you can install this specific version via homebrew like so: | ||
| * `brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/56d8c1eba1e5ac30290dd0c486f4bba37f821e42/Formula/thrift.rb` |
There was a problem hiding this comment.
That took me quite some time to figure out 😅
| int messageSizeOfNextSpan = delegate.messageSizeInBytes(Collections.singletonList(next)); | ||
| // don't enqueue something larger than we can drain | ||
| if (Integer.compare(messageSizeOfNextSpan, delegate.messageMaxBytes()) > 0) { | ||
| if (Integer.valueOf(messageSizeOfNextSpan).compareTo(delegate.messageMaxBytes()) > 0) { |
There was a problem hiding this comment.
how is this different from messageSizeOfNextSpan > delegate.messageMaxBytes() ?
There was a problem hiding this comment.
you're right. done.
The downside is that it's probably less JIT friendly as I've removed the final keyword on the threadLocalRandomPresent flag
|
Conflicts are resolved now. I also tried to improve the |
Checked with IntelliJ:
Run Inspection by Name >
Usages of API which isn't available at the configured language level
jaeger-crossdock still requires Java 7 because it calls
InetAddress#getLoopbackAddress()
(closes #129)