Lookup bytebuddy strategy for JDK 17+

[m1c1b]

Summary

This merge request introduces several enhancements and new features to the library, focusing on improving abstraction, readability, and compatibility with newer JDK versions.

Changes Made

• AbstractProxyFactory Abstraction:

  • Created an AbstractProxyFactory to provide a more structured and reusable abstraction layer for proxy factories.

• LookupProxyFactory for JDK 17+:

  • Developed a new version of ProxyFactory named LookupProxyFactory.
  • Utilizes the Lookup ByteBuddy method for class loading, addressing the requirements for JDK 17 and above as per JEP 403.

• Builder Enhancement:

  • Introduced a new method in the builder, allowing users of the library to conveniently create their own Proxy Factory implementations.

• Improved Readability:

  • Reordered methods to enhance the readability and maintainability of the code.

• Static Imports and Refactoring:

  • Added a few static imports to make the code more concise.
  • Reduced the number of return statements in methods to streamline the code flow.

• Test Coverage:

  • Duplicated the existing ProxyFactory tests for the new LookupProxyFactory to ensure comprehensive test coverage.

Documentation Note

I am currently uncertain whether to update the main documentation with these changes or to assume that developers will study the source code directly, given the highly technical nature of these updates. If it is deemed necessary to update the documentation to reflect these changes, I am more than willing to do so.

[badgerwithagun]

Hey @m1c1b. Thanks for the PR and apologies for the delay in reviewing. Looking now.

[badgerwithagun]

@m1c1b - why do we need both versions of AbstractProxyFactory? Does the new approach not work on earlier JDKs?

[m1c1b]

@badgerwithagun I'm not sure that deleting anything is a good approach in backwards compatibility way. So let's leave an old AbstractProxyFactory realization as it is but mark it as @Deprecated? What do you think?

[badgerwithagun]

I agree that if there are circumstances where the old approach will work but the new approach won't (for example, older JDKs) then it makes sense to keep both, but if that's the issue, then we should be as friendly as possible and simply auto-select the appropriate mechanism for the runtime by checking the java.version system property, rather than forcing the developer to change settings in order to make it work in their application. As much as possible, we try and make the library work out-of-the-box.

On the other hand, if the new approach will always work, regardless of JDK, I would prefer to just keep the change small and switch to the new approach without retaining the old one.

If we go for the first approach, I think the design of multiple proxy factor implementations seems needlessly heavily engineered; a simple if..else construct would suffice for that one-line difference.

[m1c1b]

So, should I check all versions below 17 for new approach? 16, 15, ... 8? Or just LTS releases: 11, 8?

I think check using testcontainers can be a good way.

[badgerwithagun]

Hey @m1c1b, yes, just check the conditions and select the appropriate implementation. Maybe add a system property that allows the specific implementation to be forced if absolutely necessary, but default to making a sensible choice and don't change the API footprint.