JDK-4492260 : Provide a "once" keyword for a once-only evaluation of designated methods
  • Type: Enhancement
  • Component: specification
  • Sub-Component: language
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2001-08-15
  • Updated: 2008-05-19
  • Resolved: 2008-05-19
Related Reports
Relates :  
Relates :  
Description

Name: ddT132432			Date: 08/15/2001


Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)

The following coding idiom, and variations of it, occur extremely frequently
in Java programs:

 ----------------------
 :
 private SomeType var;
 public SomeType getVar() {
   if (var == null) {
     var == new SomeType(...);
   }
   return var;
 }
 :
 ----------------------

A "once" keyword would reduce program size and improve readability
significantly. Example:

 ----------------------
 public once SomeType getVar() {
   return new SomeType(...); // Always return ref to same instance
 }
 ----------------------

Note that this is *not* the same as a static method declaration, since different
instances of class X which contains a non-static "once"-method with can deliver
different values (note this is in contrast to Eiffel's "once", which returns the
same value for all class instances.)

"once" can also be used in static method declarations:

 ----------------------
 public static once void initializeSystem() {
   // Do initialization
   :
 }
 ----------------------

This example also shows "once"'s use in a procedure. Currently the only way to
code this is by using tedious and error-prone code such as:

 ----------------------
 private static boolean alreadyInitalized = false;
 public static synchronized void initializeSystem() {
   if (!alreadyInitalized) {
      // Do initialization
      :
      alreadyInitalized = true;
   }
 }
 ----------------------

"once" methods are implicitly synchronized, since the "once" keyword  garantees
that exactly one instance of the object is instantiated.

Primitive types work similarly, effectively caching the result in an unnamed
private instance or (in the case of static methods) class variable. All other
aspects of method semantics remain unchanged.

Like "synchronized", the "once" declaration is *not* inherited, although
calling a "once"-method from a subclass e.g. super.getVar(), continues to
exhibit the once-only behaviour.

Optimizing compilers and runtime environments can certainly utilize the "once"
declaration to perform additional optimizations. For example, the method only
need be "synchronized" until the first call to it has completed, and the monitor
released.
(Review ID: 130050) 
======================================================================

Comments
EVALUATION It seems the 'once' modifier on a method (or field?) indicates the method body (or field initializer?) must be evaluated at most once per enclosing instance (as tracked by some compiler-generated framework or by the VM itself) and its return value cached. I agree this opens good possibilities for optimization, but embedding this particular guard idiom in the language is undesirable since it covers only a tiny fraction of possible scenarios. Consider the example provided: private SomeType var; public SomeType getVar() { if (var == null) { var == new SomeType(...); } return var; } -> public once SomeType getVar() { return new SomeType(...); // Always return ref to same instance } The need for var disappears but it's not obvious to me that temporary fields can in general be so easily swept under the carpet. And if the instantiation guard is more complex than simple checks on the local object, then once-only evaluation is pointless. As the previous evaluation noted, this is a low power-to-weight feature, and it should not be added.
19-05-2008

EVALUATION I've heard worse ideas, but also better ones. Java is not an academic exercise where every new untried idea can be thrown in. With millions of developers, and lots of vendors of IDEs, compilers and VMs, introducing a new feature needs to done very carefully. This applies especially to features that have not been used extensively in other languages, and to features whose power-to-weight ratio is low. It's an idea worth keeping in the database. I would not expect to see it acted upon any time soon. ###@###.### 2001-10-11
11-10-2001