The Java memory model has been forgotten for more than nine years, but most open source Java supporters want to modernize it and focus on concurrency, as introduced in Java memory model takes small step toward modernization.
A JEP (JDK Enhancement Proposal), number 188, has come up this month, offering guidance on shared-memory concurrency efforts that impact Java SE (Standard Edition), JVM support, testing, and tools.
According to the JEP document, specifying shared memory consistency models and developing and maintaining features and components that operate in accord with them are among the most central yet difficult issues in engineering concurrent and parallel platforms. Specification limitations, errors, and unintended consequences become apparent over time; new hardware platforms, programming techniques, and software components and tools emerge that escape existing boundaries.
The JEP tries to solve the aforementioned problems. It also extends coverage of the Java memory model, which was last released with Java SE 5, in September 2004, which is pretty far from the current release of Java SE 7, and the new release of Java SE 8 that is coming in March.
As the author of the proposal, Doug Lea explains, the memory model presents the formal, mostly mathematically expressed rules on how threads interact with memory. All Java thread actions and synchronizations ultimately are specified in terms of the memory model. The model can be used to revise the Java language specification, improve implementations, support new concurrency features and develop new programming tools.
If the JEP effort turns out to be successful, it may lead to various enhancements, adjustments, and bug fixes across the platform. It is also possible that some uncommon borderline programming constructions will be shown to be problematic. But no further impact on backward compatibility or on unrelated specifications or APIs is expected. On the other hand, if the effort fails to achieve its goals, then the current state of affairs will continue to hold.
The proposal would feature improved formalization of the underlying memory model, in which the revised model would be mechanically checkable and more understandable. Existing errors would be addressed as well, and JVM coverage will be addressed along with C11/C++ compatibility and implementation guidance.
According to the proposal, conformance to memory model requirements is difficult to test, so engineers that will design and implement tests with clear bases in specifications are expected. The reformulated model will be amenable to use by development tools that analytically check for errors like race conditions and maintenance of security properties across concurrent execution.
Lea served on the JCP (Java Community Process) executive committee, but left in 2010. Lea clarifies that the memory model proposal is not a JCP effort, although the JCP may become involved with byproducts of the effort.Related Whitepaper:
Bulletproof Java Code: A Practical Strategy for Developing Functional, Reliable, and Secure Java Code
Use Java? If you do, you know that Java software can be used to drive application logic of Web services or Web applications. Perhaps you use it for desktop applications? Or, embedded devices? Whatever your use of Java code, functional errors are the enemy!
To combat this enemy, your team might already perform functional testing. Even so, you're taking significant risks if you have not yet implemented a comprehensive team-wide quality management strategy. Such a strategy alleviates reliability, security, and performance problems to ensure that your code is free of functionality errors.Read this article to learn about this simple four-step strategy that is proven to make Java code more reliable, more secure, and easier to maintain.