JMH is a great tool to write microbenchmarks but when you need to integrate it with CDI it can be a bit tricky or you need to break the “common” concept of shade JMH really loves.
However OpenEJB ApplicationComposer provides a built-in solution to this issue pretty neat.
Sometimes you need to parse JSON files in a library. Then the question is pretty quickly: do I use a SPI (Service Provider Interface) to let the user choose the library he uses with my code or do I bind my library to one parser/writer?
Sometimes the answer is easy: when the need is basic (read/write) having a SPI and a default implementation is pretty good and let your users avoid to depend on one implementation. Said otherwise, you let your users reuse the implementation they probably already have in their application/classpath.
However sometimes you need a more advanced setup to get some customizations or features (like comments in JSON for instance which is very handy for configuration files) so either you bind your library to one implementation and your users end with N JSON implementations they don’t control and which potentially conflict together, or you enhance a lot your SPI risking to loose some features if your user chooses an implementation not supporting some of your needs, or you can also grab an implementation which work fine for you and just put it in your delivery. This last option is pretty nice cause then your code can use all the shortcuts an implementation can offer – like custom annotations.
Going further with this last option you can also potentially reuse some standard API like JSON-P or the coming JSON-B in your code and just hide it and not depend on the container for the runtime.
Of course there is no free lunch and it will make your delivery a bit more heavy but a good mapper is ~200k max so it is still a good option for JSON needs.
How to do it?
If you use BatchEE as JBatch implementation with a EE container which doesn’t integrate directly with it you can get some surprises like not using the right bean manager or just getting errors about CDI context.
This is because by default BatchEE uses its own pool of threads as needed by the spec but then in these threads CDI is not initialized and the lazy lookup of the bean manager done by BatchEE to avoid to use a “startup” bean manager at runtime in some – expensive – containers can fail cause of it.
New posts here >>> rmannibucau.metawerx.net 