Skip to content
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

improve: use Base64 implementation from jre #1996

Merged
merged 2 commits into from
Dec 30, 2020
Merged

Conversation

bokken
Copy link
Member

@bokken bokken commented Dec 22, 2020

Removes Base64 from org.postgresql.util and updates use in RecoveredXid with jre Base64.

All Submissions:

  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

  1. Does your submission pass tests?
  2. Does ./gradlew autostyleCheck checkstyleAll pass ?
  3. Have you added your new test classes to an existing test suite in alphabetical order?

Changes to Existing Features:

  • [y] Does this break existing behaviour? If so please explain.
    It removes the Base64 utility class
  • Have you added an explanation of what your changes do and why you'd like us to include them?
  • Have you written new tests for your core changes, as applicable?
  • Have you successfully run tests with your changes locally?

@davecramer davecramer modified the milestones: 42.2.6, 42.3.0 Dec 29, 2020
@davecramer
Copy link
Member

hopefully nobody uses the Util class. We could always deprecate that and then remove it later. I'm ambivalent as it's a private API

@bokken bokken merged commit 1e20039 into pgjdbc:master Dec 30, 2020
@bokken bokken deleted the base64 branch December 30, 2020 19:12
@vlsi
Copy link
Member

vlsi commented Feb 10, 2022

@bokken , I believe this removed a class without aging it in @Deprecated state for a while.

Please refrain from removing classes as people might still be using them: https://github.com/search?l=Scala&q=org.postgresql.util.base64&type=Code

@jorsol
Copy link
Member

jorsol commented Feb 10, 2022

While I generally agree that backward compatibility is extremely important in this project, I'm ambivalent to resurrecting this class just to mark it as @Deprecated, it's an internal API after all (even if it's not marked as such).

I'm not against of resurrecting that class either just to mark it as @Deprecate but there is no benefit for it, in GitHub search, you will find all kinds of usage, many toy projects, and also unmaintained code that doesn't reflect a real usage, there might be valid real-world production projects, but those should not use this class anyway.

@sehrope
Copy link
Member

sehrope commented Feb 10, 2022

+1 to not adding it back. The util classes are not part of the public API.

Anybody that was using it would see a compile time error. No runtime behavior of anything public has changed.

If we haven't done so already, we should also explicitly declare in the README or the docs the packages that we consider "official" API.

@davecramer
Copy link
Member

I see no harm in adding it back @deprecated ...
+1 to documenting what we consider the official API.

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.

None yet

5 participants