|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 6 of 7
java.util.concurrent.locks) and atomics (java.util.concurrent.atomic)
Looking beyond explicit support for parallel processing, Java EE developers have been exposed to an inherently threaded model
since the inception of enterprise Java. All the building blocks of the Java EE specification—servlets, session beans, and
entity beans—have always been regarded as components, where threading issues need to be explicitly considered and handled
by the developer. It is fair to assume then that advances in parallel processing hardware will cause no issues at all for
this segment of the Java ecosystem. Developers will still create bugs relating to unordered access to shared variables by
threads and create bottlenecks by the inappropriate use of Singleton objects in their code, but by and large, these bugs/anti-patterns and their resolution are understood and well documented.
However, Java by itself is weaker when compared to popular frameworks such as Spring and Hibernate, which support threading good practices. Java EE developers want to delegate threading issues to the framework and focus on implementing business logic.
Moving off the server and onto the desktop, client-side developers will have more work to do. Threading issues have always
been well known on the client; multiple helper classes and best practices abound to prevent improper use of the AWT (Abstract
Window Toolkit) main UI thread (SwingWorker, javax.swing.SwingUtilities.invokeLater, etc.), while the entire model of the latest UX buzzword—Ajax (Asynchronous JavaScript and XML)—is based on using JavaScript
to asynchronously receive data from the server to update the rendered HTML shown to the user.
On an interesting side note, it is fair to say that Java on the client is under pressure from Ajax-enabled browser applications, with the crowd storming the fort being led by Google Suggest, Maps, Spreadsheet, etc. Therefore, we need to ask the question: How do Internet Explorer, Firefox, Safari, etc. handle multicore CPUs, or, put another way, what are the threading models for these applications and their built-in JavaScript interpreter engines?
As it turns out, this is a difficult question to answer, and the answer will change over time. (Why wouldn't Microsoft and Mozilla add threading code to take advantage of additional cores—just as a Java programmer would?) At present, I believe that the answer is that all browsers have one main UI thread, just like the main UI thread in AWT/Swing. The JavaScript interpreter gets another thread to process events that occur during a page's lifecycle.
In summary then, a client machine with more than one true processing unit could run your application differently than a client with only one processing unit. The only way to certify your client-side Java threaded application is to test it on a true multicore CPU.
Archived Discussions (Read only)