The good old JSR 107 (JCache – Java Temporary Caching API) nearly made it into Java EE 7. Hopefully, JCache will finally get into Java EE 8 and, maybe, with better integration with other specifications (we could think of having JCache as a second level cache for JPA)
We used to have performance teams within the development environment. Their job was to make it ‘go faster’ after the developer ‘made it go right’ (gave the correct answers).
An Important Technique
Caching strikes me as an important technique. It will become less useful as the speed of everything improves to the point where it no longer becomes a necessity. Man power costs money while hardware is cheap.
In my future vision, caching by annotations would offer the app code developer, with an intimate knowledge of what he wrote, to offer guidance to the compile and build tools, not the implementtion. The build tool would implement the infrastructure to make it happen – not something specifically coded by the developer. Maybe that’s what JSR107 is all about. We’ll see.
It would not remove the need for a bod/team with a more global view, to further tune the performance of a complete suite.
Think About It
We really need to keep performance issues in mind as we design systems as well as when we build them. Each discipline will need an implementation bod to wear their performance ‘hat’ often during the development lifecycle. We could ask for tuning and performance from many of the areas we typically use :
- The compile tool builder would tune generated results for optimum speed
- The app developer would tune the code to best advantage
- The database bods would choose optimal index path constructions and the appropriate choice of index technique. Clustering techniques might be useful to allocate data stores across physical hardware devices
- Network response is, as always, an issue too, so a nod to this area is important
It all goes toward giving ‘the user’ a satisfactory experience. I have often found that ‘performance’, per se, is never talked about as long as the answers are ‘fast enough’ – but ALWAYS talked about when the answers are ‘not fast enough’.
Performance is not something we can patch on at the end of development, as an after-thought. Performance MUST be an integral component of the entire project lifecycle including post-implementation. Caching is one tool in our performance toolkit.
Thanks to Antonio Goncalves’s post http://java.dzone.com/articles/my-java-ee-8-wishlist for prompting my rant :-}