Tomasz Nurkiewicz around Java and concurrency

" Java Concurrency in Practice ", written by Brian Goetz et al., is not brand new, but certainly one of the best Java books I had pleasure to read. But first two other books should be mentioned. Few months ago I took two classic Java readings: " Refactoring: Improving the Design of Existing Code " by Martin Fowler and " Java Puzzlers: Traps, Pitfalls, and Corner Cases " by Joshua Bloch and Neal Gafter. And I didn’t enjoy both of them. The first mentioned book is completely outdated. The author explain step-by-step how to perform certain refactorings manually, but nowadays any mature IDE will do those refactorings automatically in not more than two mouse clicks. Besides, most of explained approaches are simply trivial and obvious. If I have the same statement at the beginning of if block and else block, I don’t need a book to figure out, that those duplicated statements can be moved before if condition. Also reading how to extract interface from existi

Spring support for aspect oriented programming is very wide , but sometimes you may shoot yourself in the foot if you are not careful enough. Consider the following service interface: public interface FoobarService { void foo(); void bar(); } ...and its implementation: public class DefaultFoobarService implements FoobarService { @Override @Transactional public void foo() { //some code requiring active transaction } @Override public void bar() { foo(); } } To keep things simple, assume that foo() throws exception if not run in context of active transaction. Since main() is so old-school, we’re going to test both methods through test case: @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration public class DefaultFoobarServiceTest { @Autowired private FoobarService foobarService; @Test public void testFoo() { foobarService.foo(); } @Test public void testBar() { foobarService.bar(); } } Assuming testFoo() succeeded, will testBar() s

...and prefer Spring. After passing my SCBCD exam lately, I gathered few disadvantages of EJB3 standard, which I found especially irritating and annoying. 1. Whole concept of session beans is unclear to me . Every programmer having even basic knowledge about concurrent programming knows, that single object can be safely accessed by multiple threads as long as concurrent threads do not modify the same variables (in short). But since method arguments and local variables are local to the thread (they exist on stack), the only shared variables are object fields. Logically, if the object has no fields (holds no state), it can be safely accessed by multiple clients at the same time. Stateless session beans are, well... stateless, they should not hold any state and the client should not depend on it. So why, on earth, SLSBs are pooled and each client has its own instance a t atime? Why in order to service N clients concurrently, application server creates N instances (or less, making some cl

While preparing for SCBCD exam I encountered many difficulties in securing remote EJB 3 stateless session bean, and then calling such a component from remote standalone client. I hope this short introduction will help you… avoiding this problem. First, I simply put security annotations on my bean as follows: @Stateless @RolesAllowed("ROLE_ADMIN") @PermitAll public class DateServiceBean implements DateServiceRemote { //... } Surprisingly such a bean can be easily deployed on JBoss 5.1.0 application server and all its methods are available. Why surprise? Because no ROLE_ADMIN was defined in JBoss nor the client was authorized. As the role was not defined, server silently ignored the security annotation! I learned my lesson – always verify security configuration, especially whether it actually secures anything… Quick tour over JBoss documentation and I discovered @org.jboss.annotation.security.SecurityDomain annotation, which should mark all the beans using declarative as