'Java SPI Usage On Non Open Source [Company Based] Project
I recently learnt about Java SPI, and I think it is only useful for third party library to implement the interface, like slf4j and jdbc [i.e. most likely, open source library]. It may also be useful if the application is a product where it allows end user to create custom implementation of sth.
But for developing a software in a company, where we only expose APIs to client, and end clients never have the right to customize any implementation, is there any reasons to implement interface using Java SPI?
For example, let say, I am working on a payment system, where it directly connect to different bank system [e.g. Morgan Stanley, Bank Of China, Deutsche Bank...], but each system will definitely have different API and maybe our server needs to handle the request and response differently. Therefore we must create an API to wrap such information, so that other developer will calling such services, does not need to concern on the difference between different bank system.
public interface PaymentInterface {
String bankName();
boolean pay(Customer customer, BigDecimal amount);
}
In such scenario, I can in the same Jar, create a method, that implements the interface directly, then create a static factory method, for selecting different PaymentInterface on the fly. Then it is good to go.
And of course, one can create a SPI, and define META-INF/service xxx file to specify we implement SPI in XXX and YYY. But when one cannot foresee future implementation of SPI will be built on external jar, but in the same jar. Are there any reasons to use SPI?
Let me rephrase my questions again,
is Java SPI seldom used by programmers / companies? Unless you are doing open source projects, like
spring,dubbo,slf4j?
Solution 1:[1]
Below is my understanding. Perhaps not correct, but I hope it can be helpful.
Take your case as example, payment methods of each bank has different rules and you can use static factory or strategy to get the specific implementation which you want in your own code/project. That's because you are designer and implementer.
Consider one case, you are the designer of that interface, and the implementation has to be done by other team, and they cannot access/change your code. At this time, I think SPI is a good choice.(Or like Spring, provide a way to let the customized implementation to override/extend the default implementation, like @Configuration and XXConfiguredAdaptor).
Framework is a scaffold(designer), and you are trying to implement business scenarios based on some scaffolds(implementer).
Solution 2:[2]
Seriously, if you think SPI will be useful in your project / product use it. If you don't, then don't.
The reasons to use or not use the SPI approach are entirely dependent on the technical requirements of your project, not on whether it is open source versus proprietary.
And whether the SPI approach is frequently or seldom used should not material to your decision making either.
If you want a summary of the (general) advantages and disadvantages of SPI, there are resources on the web that will provide this.
If you are worried that you are not permitted to provide your own SPI implementations (or implement your own SPIs from both sides) for legal reasons, I don't think there is an issue. AFAIK, neither Oracle JDK or OpenJDK licensing prevents you doing this. (But if you are really concerned, ask a lawyer who specializes in IP law.)
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | |
| Solution 2 |
