Skip to content

Make PolarisConfiguration member variables private #2007

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 11, 2025

Conversation

poojanilangekar
Copy link
Contributor

As pointed out in #1959, this change converts all public member variable to private variables.

@poojanilangekar
Copy link
Contributor Author

CC @dimas-b

dimas-b
dimas-b previously approved these changes Jul 7, 2025
Copy link
Contributor

@dimas-b dimas-b left a comment

Choose a reason for hiding this comment

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

Thanks @poojanilangekar ! LGTM 👍

@github-project-automation github-project-automation bot moved this from PRs In Progress to Ready to merge in Basic Kanban Board Jul 7, 2025
Comment on lines 127 to 137
public String key() {
return key;
}

public String description() {
return description;
}

public T defaultValue() {
return defaultValue;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there actually a use case for method/nonvalue implementations of these? I notice the methods are not final.

If not, it might not be worth breaking the interface and adding the extra overhead for callers. The values were already final so there's no risk of someone changing a config in an unexpected way.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Adding @dimas-b's comment here, (and let him address your question):

Sorry, I did not notice this before, but I think having public fiends in general is not a good idea. Since you're toughing this code in current PR, would you mind following up with another PR to convert them to private fields?

I agree that it's probably a bad idea to have public member variables, but don't feel strongly either way.
The other part that I'd be concerned about is the inconsistent public/private handling of fields. Since the fields are all final, why shouldn't catalogConfigImpl, catalogConfigUnsafeImpl, and typ be public?

Copy link
Contributor

@eric-maynard eric-maynard Jul 8, 2025

Choose a reason for hiding this comment

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

I think having public fiends in general is not a good idea.

I'm not sure if I find that a compelling enough reason to make this change. It's generally considered a good idea because it affords you more flexibility to change the behavior of e.g. key() without breaking an API, but

  1. In this case, we're proposing to actually break the API by removing public field key
  2. Do we actually want to support that kind of flexibility? If so let's make this change, but originally my intent was to enforce that the child types have only a "plain" implementation of e.g. key.

Since the fields are all final, why shouldn't catalogConfigImpl, catalogConfigUnsafeImpl, and typ be public?

Those fields don't have a use outside this class.

Copy link
Contributor Author

@poojanilangekar poojanilangekar Jul 8, 2025

Choose a reason for hiding this comment

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

Those fields don't have a use outside this class.

That's inaccurate, there are several places in the code where catalogConfig() is invoked. Which is simply trying to access the catalogConfigImpl if present.

Copy link
Contributor

Choose a reason for hiding this comment

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

Any java symbols inside polaris-core do not have backward-compatibility guaranteed per https://polaris.apache.org/in-dev/unreleased/evolution/

Copy link
Contributor

@eric-maynard eric-maynard Jul 10, 2025

Choose a reason for hiding this comment

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

Yeah I was thinking the same in my original comment, if the accessors are public final then we at least do not have to worry about divergence in the immediate concern and then the only real issue is that we're changing the API for seemingly no value.

Break points on a field do not work well in my experience (e.g. they do not catch reflected access, IIRC).

Watches are generally used for fields, not breakpoints.

Reflection and proxying can cause issues for breakpoints both fields and methods, which is one reason to avoid them. Unfortunately, you can observe this when working with method breakpoints in many proxied objects in Polaris today.

Copy link
Contributor

@dimas-b dimas-b Jul 10, 2025

Choose a reason for hiding this comment

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

@eric-maynard : would you be ok with making these fields private and their accessor methods public final? Just to confirm :)

Copy link
Contributor

Choose a reason for hiding this comment

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

yep!

Copy link
Contributor

Choose a reason for hiding this comment

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

@poojanilangekar : would you mind applying this suggestion?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

snazy
snazy previously approved these changes Jul 9, 2025
Comment on lines 127 to 137
public String key() {
return key;
}

public String description() {
return description;
}

public T defaultValue() {
return defaultValue;
}
Copy link
Member

Choose a reason for hiding this comment

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

public fields are generally considered bad practice, carefully designed interfaces are generally preferred. This is how things are composable and provide much better backwards compatibility. There are a lot of prominent examples in Java's core libraries. (Spoiler: Would anyone expect java.util.Map.Entry.key being a field?)

In the past, a lot of changes went into Polaris that count as "breaking changes" according to the above arguments. Some received strong objections while others were just approved.

@poojanilangekar poojanilangekar dismissed stale reviews from snazy and dimas-b via ca47130 July 10, 2025 23:03
dimas-b
dimas-b previously approved these changes Jul 10, 2025
@dimas-b
Copy link
Contributor

dimas-b commented Jul 10, 2025

@poojanilangekar : it looks like some direct field access still exists (compilation errors) 🤔 some parallel code changes perhaps...

@poojanilangekar
Copy link
Contributor Author

This is strange, the build passed on my machine. I will try and fix it.

@poojanilangekar
Copy link
Contributor Author

Turns out I just needed to rebase.

@dimas-b
Copy link
Contributor

dimas-b commented Jul 10, 2025

If no other feedback, I'll merge tomorrow.

@dimas-b dimas-b merged commit 15f23ca into apache:main Jul 11, 2025
11 checks passed
@github-project-automation github-project-automation bot moved this from Ready to merge to Done in Basic Kanban Board Jul 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants