jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <sitnikov.vladi...@gmail.com>
Subject Re: PR221 : Guava or concurrentlinkedhashmap or Caffeine after Java8 migration
Date Wed, 10 Aug 2016 22:03:36 GMT
Just to be clear: do you feel we are reinventing the wheel by not using
Guava? <-- I do not think so (modulo java 8)
Do you think we will get more user contributions by using Guava?

Philippe Mouawad:

> JMeter is core, although we should take into account the eco-system, I
> don't see why we should block ourselves from using a library because some
> plugin may in the future use it ?
>

JMeter does not have classloader separation between "core dependencies" and
"plugins". Am I wrong here?

JMeter users are not happy observing NoSuchMethod or NoClassDefFound
errors, thus the less dependencies core publishes to plugins, the less
amount of pain user would experience trying to figure out the proper jar
set.


Vladimir> org.apache.jmeter.core.shaded.guava...
Philippe> But if you want to contribute it why not.

I do not.
I might contribute if it was maven (I'm somewhat fluent in it), but that's
another story.


Philippe> I am not a guava expert, you seem to be.

I'm not. I just do not see lots of users/developers suggesting to replace
certain existing code parts with Guava equivalents.

Are we using immutable collections often?

I'm not a Guava expert, but I would like to hear some real-life cases for
JMeter where Guava would shine.

Philippe> Why not show here that guava brings nothing if java 8 is
introduced ?

I'm afraid that if we migrate to Guava _before_ Java 8, then lots of
contributions like "lets migrate to Guava's FluentIterable" would follow.
In Java 8 it is natural to use Stream API for that matter and so on.
The same goes for Guava's Optional, etc, etc.

Vladimir

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message