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

Ensure backward compatibility of Hikari Config #1842

Merged

Conversation

sideeffffect
Copy link
Contributor

@sideeffffect sideeffffect commented Apr 15, 2023

/cc @jatcwang

@mergify mergify bot added the hikari label Apr 15, 2023
@jatcwang
Copy link
Collaborator

Thanks @sideeffffect I'm not too sure what motivated this change given that we're breaking back compat in 1.0?
When you're talking about backwards compatibility do you mean binary back compat?

@sideeffffect
Copy link
Contributor Author

The point is to enable backward compatible evolution of Config. When we would potentially add a new field to Config, we don't want to break binary compatibility.

Binary compatibility with case classes is a tricky topic in Scala https://docs.scala-lang.org/overviews/core/binary-compatibility-for-library-authors.html#evolving-code-without-breaking-binary-compatibility

@jatcwang
Copy link
Collaborator

If you want to keep backwards binary compatibility you'll need to use package private I think. Using private makes it unavailable at the bytecode level.

@sideeffffect
Copy link
Contributor Author

Are you referring to the access modifier of the constructor of Config?
Making it private doesn't make it private in JVM bytecode, it is actually still publicly accessible in JVM bytecode. But it makes it inaccessible from Scala code. And that is good enough for keeping backward compatibility with our Scala users.

@jatcwang
Copy link
Collaborator

I've added a demo of making method private breaking bin compat https://github.com/jatcwang/binary-compatibility-guide

[error] Test suite IncompatibilityShowcases failed with java.lang.IllegalAccessError: class com.example.LibA$ tried to access private method 'int all_incompat.MakeMethodPrivate$.willBePrivate()'

You can see that projects like cats use package private to maintain bin compat.

@sideeffffect
Copy link
Contributor Author

making method private breaking bin compat

Of course it breaks 😃 There's probably a misunderstanding. I know the changes that I'm proposing in this PR are breaking bin compatibility. I'm introducing them so that once we get to 1.0.0 we can evolve Config in a bin compatible way.

)

@nowarn
def fromProduct(p: Product): Config = p.productArity match {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Sorry not sure why we need this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Scala 3 defines fromProduct in companion object of case classes. If you add a new field to the case class, you need to add a new case to fromProduct to ensure compatibility with old code which counts with the old number of fields.
I've improved the comment on top of the case class.

@sideeffffect
Copy link
Contributor Author

@jatcwang so what do you think? Can we merge this?

@jatcwang jatcwang added this to the 1.0-RC3 milestone May 4, 2023
@jatcwang
Copy link
Collaborator

jatcwang commented May 4, 2023

Will need some time @sideeffffect. I ran javap on a Scala 3 compiled case class but still couldn't find fromProduct so I'm a bit confused. I don't see it in the docs either (I think fromProduct is a method on Mirror?). Will get this in for RC3

@sideeffffect
Copy link
Contributor Author

Did you look into the companion object?

@jatcwang jatcwang modified the milestones: 1.0-RC3, 1.0-RC4 Jun 6, 2023
@sideeffffect
Copy link
Contributor Author

@jatcwang do you think we could merge this PR?

@sideeffffect
Copy link
Contributor Author

@jatcwang ping 😸

@jatcwang jatcwang modified the milestones: 1.0-RC5, 1.0-RC6 Jan 6, 2024
@jatcwang jatcwang merged commit d170c33 into typelevel:main Apr 27, 2024
6 checks passed
@sideeffffect sideeffffect deleted the hikari-config-backward-compatible branch May 5, 2024 21:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants