Tomasz Nurkiewicz around Java and concurrency

Some domain objects in many enterprises applications include a concept of state. State has two main characteristics: the behavior of domain object (how it responds to business methods) depends on the state and business methods may change the state forcing the object to behave differently after being invoked. If you can’t image any real-life example of domain objects’ state, think of a Car entity in rental company. The Car , while remaining the same object, has additional flag called status, which is crucial for the company. The flag may have three values: AVAILABLE , RENTED and MISSING . It is obvious that the Car in RENTED or MISSING state cannot be rented at the moment and rent() method should fail. But when the car is back and its status is AVAILABLE , calling rent() on Car instance should clearly, apart from remembering customer who rented the car, changing the car status to RENTED . The status flag (probably single character or int in your database) is an example of objects’ st

In one of my previous posts I gave you an example of some unexpected behavior when using Spring AOP proxies. Few days later I began to read " Pro Spring 2.5 " by Jan Machacek, Jessica Ditt, Aleksa Vukotic and Anirvan Chakraborty. It turned out that my riddle is actually a well known problem which has more than one solution. Also one of my Readers suggested some different approach. This almost nine-hundred-pages book has a whole section in Chapter 6: Advanced AOP introducing the problem which I believed I have discovered. There is even a programmatic solution, similar to EJB’s SessionContext.getBusinessObject() . But if the EJB method may be treated as somewhat standardized, using AopContext.currentProxy() looks awkward and unnecessarily couples you to the Spring framework. I almost feel guilty for telling you about this method and you should feel the same if you thought about using it. Luckily, authors of " Pro Spring 2.5 " also discourage its use. So if you wa

Suppose you have some client code (developed by you, legacy code or third-party library) which requires object of some specific type. On the other hand you already have almost exactly the same object, which does almost the same (in other words, fulfils similar contract). But the problem is, although both, required and yours, objects are pretty much the same, they have slightly or completely different interfaces. And in strongly typed Java world, even slightly means incompatible. If you travel a lot, you probably came across the same problem in your real life. European and American AC power plugs and sockets are different. Although they both have same purpose – provide you with electrical power – and have similar contract (voltage, frequency, etc.), they simply don’t fit each other. Even though they are semantically equivalent, they are syntactically incompatible (have different shapes). The solution is the same for both developer and traveler: provide an adapter, which will have two

I recently finished reading " Programming Groovy: Dynamic Productivity for the Java Developer " and this book really opened my eyes on what Groovy language really is. Most tutorials or lectures I have attended are focused on syntactical sugar: closures, operator overloading, easier access to bean properties or maps. Elvis operator, spread operator, spaceship operator... But the strength of Groovy is not syntactic sugar on a Java cake. Groovy is a brand new dish with really exotic taste, which not everybody would enjoy. The gap between Java and Groovy is really huge, although they integrate tightly and seamlessly. But remember, Firefox did not became so popular because it was so similar to IE, but because it was different [1] . Maybe Groovy is not better than Java, but is certainly worth trying. Thanks to " Programming Groovy... " I realized what amazing things can be done using Groovy which you would never even thought about in Java. As Chinese said, Java code is