Last time I wrote about events in a spring based application I’ve introduced some basics on how events can be dispatched using spring infrastructure. In this post, I’m going to dig deeper into an order of handlers, exceptions and asynchronous events handlers.
We all know how inheritance works and implemented some kind of class hierarchy at least few times during our career. Some of us know already that inheritance is not the silver bullet. Some of us know that inheritance must not be overused and considered with caution. Now I’m going to show you how choosing the quick win might cost you some unexpected troubles in the future.
With spring 4.2 (released more than one year ago) serious improvements regarding embedded events were made. You probably already know it, but I’ve never had a chance to properly investigate it. Lately, when digging into code base of the system I’m currently working on I got an opportunity to see it in action and after quick glimpse, I decided to investigate it a bit further.
Some time ago I’ve been struggling with mapping hierarchical data structure in angular. Labels hierarchy was complex (like 4 levels deep with multiple parents, multiple children, basically graph like structure with some logic behind it). In the end it was/is still working but that’s the best I can say about it.
Optimistic locking is concurrency control method that allows to execute multiple transactions simultaneously as long as they don’t interfere which each other. That’s definition from wikipedia. You probably already know that Hibernate supports optimistic locking and all you have to do in order to implement optimistic locking in you app is to add @Version on number or timestamp field and you are good to go. Right?
Page object pattern is common practice when writing automated tests using selenium. It allows to gather all possible operations on the page in one place and hide page implementation details from test case. Page object pattern can be used in the same way for angular directives, react and [put framework name here] components.
Private final field modification is possible and it doesn’t require a lot of work. Since you should not use this mechanism in real life there are cases when it is useful. For example this how is Hibernate using this to hydrate final entity fields.
But when using final fields with Hibernate you should be extra careful how you declare them.
Sometimes when unit tests setup is complex we are tempted to take shortcuts and write single setup for all tests which will save as few keystrokes. In the time of writing the test it might feel like a good idea to configure complex unit test setup and reuse it in all test. This way we avoid code duplication and we create a more condensed test. This approach looks good only in the time of the writing tests. Then there is a time when unit tests must be maintained. This is the time when you usually realize that saving few keystrokes wasn’t such a good idea.
HashCode and equals implementations are hard. Usually, it’s tricky to properly implement hashCode and equals method to fully fulfill contract from Java documentation. I’m going to focus on just one the point from the hashCode contract:
whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer.
Read it already? Do it again. Let it sink and think about impact of “hashCode method must consistently return the same integer”