In this case I would prefer a comment: // This driver is registered in a resource file .... ;-)
Chris Am 18.09.18, 10:18 schrieb "Julian Feinauer" <[email protected]>: Hey, the interesting thing for me is not the automation but the visibility. Many developers never look into the resources folder (what should be there?) but just copy code. And this thing keeps the configuration at code (its like the spring annotation vs xml stuff). But I agree with you that this benefit is minimal with regards to additional complexity. As I do not plan to implement another driver in the near future, it was just a hint to you hard working driver implementors : ) Best Julian Am 18.09.18, 10:12 schrieb "Christofer Dutz" <[email protected]>: Hi Julian, yup ... just add it to the CP and it will find it ... that's what the ServiceLoader was made for :-) I would strongly like to keep additional tools out of the build. Right now providing a new Driver means only adding a text-file with one line to the project (Ok ... with the Apache Header it's a little more). Automating this only adds tooling that can break and cause problems. I don't see any benefit of automating this ... Probably adding the import statement and adding the annotation is even more code than needed by the ServiceLoader property file ;-) I really like to automate annoying things, but for me the threshold of being annoying is far from being reached here ;-) Chris Am 18.09.18, 09:38 schrieb "Julian Feinauer" <[email protected]>: Hi Chris, thanks, I didn't know this (that it works that smooth). And thinking about it I agree that Singletons are evil and also static init blocks are bad. So it stays the same as with jdbc, simply add jar to cp and go? Then it should be totally feasible for us to implement the DriverManager as interface for our pool as its kind of the equivalent of JDBCs Datasource as its non-static. During a short research I stumbled across this https://github.com/google/auto which seems really cool (annotation based generation of service loader files), perhaps this is a cool way to keep "registration" code in the driver class. I see no necessity right now as we have very few drivers, but wanted to share this with you. Best Julian Am 18.09.18, 09:27 schrieb "Christofer Dutz" <[email protected]>: Hi Julian, 1. Because that's what the ServiceLoader is made for ;-) and I think the JDBC way greatly sucks. And it's not a singleton as this way it is way simpler to test. 2. You always could reference multiple files with the same name in the same package. Spring has been handling that quite nicely for many years. After all each resource has an URL of "mycool-lib.jar/package/package/resource.txt" ... no problem at all. The ServiceLoader option was added in Java 7 and JDBC is way older and therefore can't rely on that. The static init block is the main reason why setting an Exception breakpoint for NullPointerException sucks so greatly (Cause it is always thrown in the JdbcOdbcBridge driver which is part of the JDK). ServiceLoader only initializes things that are explicitly requested. Chris Am 18.09.18, 09:16 schrieb "Julian Feinauer" <[email protected]>: Hi all, I have another question about another bit of the internals of the Plc4J core for you : ) While implementing our Connection Pool I thought of the interface to use and observed that PlcDriverManager is no singleton and behaves quite a bit different than JDBCs. One notable difference is that it relies on Javas ServiceLoader to load drivers on the classpath. This leads me to two questions: 1. Why did you choose to do so and not use an approach like JDBC took with the singleton collection and each driver registering itself there during loading in a static init block? 2. How do the different service files interact (they have all equal name at equal path in the cp). Are they merged somehow during compile time with some kind of maven mabo-jumbo? Or how does this work that they don’t overwrite each other? Thanks! Julian
