JarCastingStored Procedure Proxy 
A more convenient and type safe way to call stored procedures from Java.
This project allows you to define a Java interface method for every stored procedure you want to call. Then it creates a dynamic instance of that interface that calls the stored procedure whenever you call the method.
Simply create an interface that represents the stored procedures you want to call.
public interface TaxProcedures {
BigDecimal salesTax(BigDecimal subtotal);
}
Then create an instance using only a javax.sql.DataSource
TaxProcedures taxProcedures = ProcedureCallerFactory.build(TaxProcedures.class, dataSource);
Invoking interface methods will then call stored procedure.
taxProcedures.salesTax(new BigDecimal("100.00"));
will actually call the stored procedure.
Check out the wiki for more information.
The project has no runtime dependencies and is a single JAR weighting 100 kB.
<dependency>
<groupId>com.github.marschall</groupId>
<artifactId>stored-procedure-proxy</artifactId>
<version>0.12.0</version>
</dependency>
What problem does this project solve?
Calling simple stored procedures in JDBC or JPA is unnecessarily cumbersome and not type safe. While this may be required in rare cases in common cases this can be solved much easier. None of the common data access layers solve this issue:
- While spring-jdbc offers many ways to call a stored procedure all of them require the registration of SqlParameter objects. The options are:
- call JdbcOperations#call
- sublcass StoredProcedure
- use GenericStoredProcedure
- use SimpleJdbcCall, accesses database metadata by default. Metadata access has to be disabled for every use
- Spring Data JPA offers two ways
- the first is hardly an improvement since it still needs a
@NamedStoredProcedureQuery - the second is quite nice, we take inspiration from this approach and add more flexibility
- the first is hardly an improvement since it still needs a
- jOOQ offers stored procedure support in a way that is similar to this project, in addition it supports many more features and can generate classes from a database schema. The only down sides are that it requires passing a configuration object (for now) and Oracle support is commercial.
- jDBI falls back to manual parameter registration for out parameters as well.
- Ebean falls back to manual parameter registration for out parameters as well.
- Querydsl has no support at all
- Sql2o seems to have no support at all
- spwrap is similar in spirit but requires more annotations and is currently a bit less flexible
While they all have their use case none of them fitted our needs.