Skip to content

Backport PR #15679 to 8.x: [Spacetime] Reimplement config Setting classe in java#16490

Merged
andsel merged 2 commits into8.xfrom
backport_15679_8.x
Oct 11, 2024
Merged

Backport PR #15679 to 8.x: [Spacetime] Reimplement config Setting classe in java#16490
andsel merged 2 commits into8.xfrom
backport_15679_8.x

Conversation

@github-actions
Copy link
Copy Markdown
Contributor

@github-actions github-actions bot commented Oct 2, 2024

Backport PR #15679 to 8.x branch, original message:


Release notes

[rn:skip]

What does this PR do?

This is a not clean backport of #15679 to 8.x branch.
It adds the commit 5ca0686 to avoid errors like

warning: [this-escape] possible 'this' escape before subclass is fully initialized

happening with JDK 21 https://buildkite.com/elastic/logstash-pull-request-pipeline/builds/1524#01924c14-d87e-45ac-8b4f-a5e365b9d474/62-651

Reimplement the root Ruby Setting class in Java and use it from the Ruby one moving the original Ruby class to a shell wrapping the Java instance.
In particular create a new symmetric hierarchy (at the time just for `Setting`, `Coercible` and `Boolean` classes) to the Ruby one, moving also the feature for setting deprecation. In this way the new `org.logstash.settings.Boolean` is syntactically and semantically equivalent to the old Ruby Boolean class, which replaces.

(cherry picked from commit 61de60f)
@elastic-sonarqube
Copy link
Copy Markdown

Quality Gate passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

@elasticmachine
Copy link
Copy Markdown

💛 Build succeeded, but was flaky

Failed CI Steps

History

@andsel andsel mentioned this pull request Oct 2, 2024
@andsel andsel requested a review from yaauie October 3, 2024 07:32
@andsel andsel self-assigned this Oct 10, 2024
Copy link
Copy Markdown
Member

@yaauie yaauie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM for a merge, because getting these in sync is better than perfection.

I think that the this-escape can be avoided, but that it doesn't present a present danger and we can do so in a follow-up effort.

  1. introduce package-private static BaseSetting#validate(T, Predicate<T>):
        void static validateValue(String name, T input, Predicate<T> validator) throws IllegalArgumentException {
            if (!validator.test(input)) {
                throw new IllegalArgumentException(String.format("Failed to validate setting `%s` with value: `%s`", name, input);
            }
        }
  2. migrate the instance method BaseSetting#validate(T) and the validate-in-initializer calls to use the static method:
        public void validate(T input) throws IllegalArgumentException {
            validateValue(this.name, input, this.validator);
        }
        // protected BaseSetting(String name, T defaultValue, boolean strict, Predicate<T> validator) {
        // ...
            if (strict) {
                validateValue(name, input, validator);
            }
        // }
        // protected Coercible(...) {
            if (strict) {
                T coercedDefault = coerce(defaultValue);
                BaseSetting.validateValue(name, coercedDefault, validator);
                this.defaultValue = coercedDefault;
            } else {
                this.defaultValue = defaultValue;
            }
        // }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants