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 existing class o…

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() succeed as well? The trick part is transaction propaga…

...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 clien…

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 well as prog…