Updates of runtime components

[alshopov]

This is up for discussion, we could do it partially

[yurishkuro]

what is the motivation for these updates? Some I don't have problems with, like mockito or brave/zipkin, as they are implementation details. Others are a bit more problematic, e.g. tchannel upgrade in crossdock needs testing (if works, then ok), or Jersey upgrades that appears to be actually breaking (since you had to change code).

[alshopov]

Bugfixes and performance in the underlying libs is the main reason. As jaeger is used throughout Uber's services depending on old version causes problems.
I have removed the jersey update.
The tchannel 0.7.7 is far better than 0.5 as many memory leaks have been eliminated both in it and underlying netty.
What testing do you expect for crossdock? instantpay uses latest tchannel-java and xtchannel-java with much less problems than previous versions.

[yurishkuro]

As jaeger is used throughout Uber's services depending on old version causes problems.

that's the point I don't understand - unless there are API differences, the versions that Jaeger lib is using should be non-binding to the actual applications; if they want to use newer versions the build system should resolve accordingly.

[alshopov]

I get your point as a maintainer - you would rather ensure long term stability and minimize changes.
However you have to weigh this against other goals.
I do point releases updates because they usually contain bugfixes, especially security ones. I've had instances when due to an outdated library we have relied on a bug as a feature. These things get ironed out with the updates.
Larger than point releases updates are to minimize the usage of old, deprecated APIs. Unless you do these regularly, they keep piling up and it becomes increasingly more difficult to finally fix them.
While what you say is true - a project may declare updated dependencies, it also may not and that also causes maintenance burden. Additionally it becomes harder to convince a project to move to a new version if the library it depends on has not been verified to work with that version.
But yeah - these decisions rest finally on the maintainers.
I may reduce the number of updates or you can deny the pull request.

[yurishkuro]

Given the current list of upgrades I don't have objections to them. But it looks like they are already introducing incompatibility as the build is broken with NoSuchMethod

[codecov]

Codecov Report

Merging #286 into master will decrease coverage by 0.14%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #286      +/-   ##
============================================
- Coverage     82.62%   82.48%   -0.15%     
+ Complexity      552      550       -2     
============================================
  Files            91       91              
  Lines          2072     2072              
  Branches        237      237              
============================================
- Hits           1712     1709       -3     
- Misses          264      265       +1     
- Partials         96       98       +2

Impacted Files	Coverage Δ	Complexity Δ
...jaeger/reporters/protocols/ThriftUdpTransport.java	77.96% <0%> (-5.09%)	14% <0%> (-2%)

---

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 916de0c...d1b8e55. Read the comment docs.

[alshopov]

@yurishkuro - is the patch fine now?

[yurishkuro]

looks like we have flaky test coverage, this didn't execute

if (!this.isOpen()) {
 throw new TTransportException(TTransportException.NOT_OPEN);