Software guru Larry O'Brien has started a thought provocative series of articles on DevX that talks about leveraging multi-core systems with concurrent programming techniques.
This lead me to wonder how we, J2EE developers (or JEE developers, for the most advanced of us), could leverage these multi-core systems, which are bound to become our standard configurations. I might be completely wrong but I have not figured out how this could change our practice! Let me detail.
J2EE applications are designed to be deployed and executed on J2EE servers, which are highly multi-threaded environments: any J2EE server will contain several thread pools waiting to process your HTTP requests, or your EJB invocations, or your JMS message submissions... Such a system is de facto a greedy consumer of multi-core or multi-processor architectures.
In fact it requires a lot of talent to ensure that a J2EE application does not leverage this multi-threaded environment. I have seen once such a product: the developers had to be very consistent in using thread unsafe objects to ensure the system would crash if more than one user would use it. Indeed, even the simplest web-tier only application will benefit from the thread pool dedicated to serving web requests.
Attempts to parallelize some processes by creating specific threads can be made, but with great caution as it is not recommended to create random threads in an application server. In fact, for such parallelizing, internal JMS destinations and consumers can be used: this is already common practice.
Besides, it is interesting to note that more native thread execution capabilities will allow to better leverage JVM features like parallel GC. But this is true for any kind of Java applications (for JVM versions greater than or equal to 1.3.1), not only for J2EE ones.
To sum it up, these new multi-core architecture will improve performances of J2EE applications, but without the need for programmers to do anything about it.
This is good news, anyway.
