I'm currently working on a project that utilizes Spring Data JDBC custom repository. In my custom repository, I have implemented my own DataAccessStrategy, AggregateRoot, AggregateExecutor, and SqlParameterSource to generate SQL scripts. However, I would like to use the SqlGenerator class to generate SQL, which has a package-private access modifier.
To get around this, I plan on using composition by creating a public class in org.springframework.data.jdbc.core.convert and using a private final field with the SqlGenerator type.
My question is: would it be a good idea to open up the methods of the package-private SqlGenerator class for use in my library?
Any advice or suggestions would be greatly appreciated!
would it be a good idea to open up the methods of the package-private
SqlGeneratorclass for use in my library?
There are a couple of different interpretations to that question, but I think the answer is always: No.
Should the Spring Data Team open up the methods?
No, they shouldn't. Making methods publicly accessible would require additional maintenance and design work. SqlGenerator simply isn't intended for reuse outside of Spring Data JDBC itself.
Should I patch my version of Spring Data JDBC to make these method accessible?
No, the patch needs to be reapplied to every new version, creating significant maintenance work on your side and possibly preventing you or your team from upgrading to the latest version of Spring Data JDBC, which might affect the ability to upgrading other Spring versions and libraries and will eventually effect the ability to apply upgrades that are very important due to security issues.
The whole idea of creating a class in a package that isn't controlled by you is a hack and I would recommend against it.
Instead I'd just copy SqlGenerator into your package and work with the copy. This way you have everything under you control and it is also obvious that it is your control since it is in your source path.
An alternative, would be to use reflection to access the existing class.