Hey Chris,
I second approach with interfaces as it clearly cuts implementation and
declaration of operations. It could also help people who use OSGi
because making a PlcDriverManager valid osgi service will be easier
(lighter) with interface. It boils down to runtime where proxy for
interface type is built in JVM while proxy for class involves cglib/asm etc.
Best,
Łukasz
On 8.01.2023 15:35, Christofer Dutz wrote:
Hi all,
I’m currently working on a new Connection Cache for Java and have stumbled over
two things:
The one is the fact, that the PlcDriverManager is a class and not an interface.
This makes it problematic for me to have the PlcDriverManager implement the
same interface.
I could probably override every method, so this is not a big problem.
However, having a PlcDriverManager interface would be the cleaner solution.
This would require us to change the name of the current PlcDriverManager class
to something like DefaultPlcDriverManager… this would be a breaking change.
Another is that the getConnection doesn’t return a Future … the main reason for
this was the try-with-resources pattern, that automatically closes the
PlcConnection returned from getConnection.
However, returning a future might be the better option and it would be more
like in the other languages.
Especially when we’re working with cached connections. Here a client might be
waiting a while till it gets a connection handle.
This also would be a breaking change.
What do you folks think?
Chris
