Hi Felix, Vladimir, and all, I agree that we should proceed with the release of version 6.0, given the significant amount of work that has been completed.
Looking ahead, I believe we should migrate to virtual threads and memory usage. Regarding memory consumption, many other tools, such as k6 and Gatling, do not store full query responses in memory by default. For instance, k6 offers a "discard response bodies" option to optimize performance. https://grafana.com/docs/k6/latest/using-k6/k6-options/reference/#discard-response-bodies While we should likely continue capturing everything by default to maintain backward compatibility, we should provide users with the setting to change this behavior. Implementing a more selective approach to what is saved in memory (e.g., only storing what is captured by an extractor) would significantly reduce JMeter's memory footprint. Antonio Gomes Rodrigues Le mar. 31 mars 2026 à 19:08, Felix Schumacher < [email protected]> a écrit : > > Am 31.03.26 um 18:57 schrieb Vladimir Sitnikov: > > Are there any blockers, that would hinder us from releasing a 6.0 version? > > Frankly, I have been working on 6389 since November, and currently I > implement generic "explicitly unset" vs "set to empty" for text-like and > combobox controls. > I don't remember why it was required, however, it looks like it is required > so "http defaults" do not override the values in http sampler unless the > user explicitly asked for it. > It might be fine to postpone the 6389 and "explicitly unset" to a > subsequent release. > > Well, users will expect a .0 version to contain bugs, right? > > No, do you have an estimate how much work is still needed? Can anyone help > you out with some tasks? > > > * I would like to switch off oro by default (PR 6661), any reason not to > > do so? (There is one question hidden in the PR :) ) > > What do you mean by "switch off by default"? > I would like to avoid introducing breaking changes as much as possible. > Ideally, the script designed for old versions should be workable with newer > versions just fine. > > In 5.6 (i don't remember the exact version), we introduced a switch to use > Java regex instead of oro, with the default being oro. > Now with 6.0 I think it is a good time to reverse that and use Java regex > as the default while the user can still enable oro back, if he likes. > > I don't think that the regex implementations differ that much, except that > Java regex is more feature rich and probably better tested. > > With a next major version we could then (if we don't get too many > complaints) remove oro completely. > > The question I have is more about the change in the escapeOroRegex > function, where I boldly assume, that a user wants to use that function > even with Java regex enabled, but we want to pave the way for removal of > oro. So that function uses Java regex quote functionality instead of oro, > when Java regex is enabled. > > > * PR 6610 seems to be a no-brainer, but haven't looked too closely > > * We distribute rhino in version 1.8, but as we don't include > > rhino-engine, we can't select js in JSR223 elements. I think, we should add > that missing jar (or even add nashorn, now that we have Java 17 as minimum) > > Unfortunately, the syntax between rhino and nashorn differs, so we can't > replace one with another without breaking the users' scripts. > If we can't select rhino in JSR223, that sounds like a bug, and we should > probably add rhino-engine. Nice catch. > > Well, we already were on nashorn, way back, when it was in the JDK, so > going back to rhino is a breaking change for these people :) > > But I don't mind either way, as I think groovy is way better suited for > scripting in JMeter anyway. > > > The discussion with virtual threads and Java 21 should be (in my opinion) > > deferred to the next version after 6.0. > > Fair, I do not think it should hold the release. > > Vladimir > > > Felix > >
