Name: jk109818			Date: 09/16/2002


FULL PRODUCT VERSION :
java version "1.4.1-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-rc-b19)
Java HotSpot(TM) Client VM (build 1.4.1-rc-b19, mixed mode)


FULL OPERATING SYSTEM VERSION : N/A


ADDITIONAL OPERATING SYSTEMS : all



A DESCRIPTION OF THE PROBLEM :
A persistant obstacle to maximizing java performance has
been the excessive creation (and cleanup) of small helper
classes generated by methods which are called frequently. A
simple extension to the language specification would obviate
the need for a large portion of these helper classes.
Consider the following code:


java.awt.Point getLocation() {
    int x,y;
    ...
    return new java.awt.Point(x,y);
}

...

void myFunc() {
    ...
    java.awt.Point point=getLocation();
    System.out.println("location is ("+point.x+","+point.y+")");
}


Even though java.awt.Point is fairly small and j2sdk1.4
improved upon perfomance while handling small classes, if
myFunc() is called often enough performance still can be a
problem. Improving performance of the JRE in this case is
sidestepping the issue; the best solution is to avoid
creating the class at all, especially since it serves no
purpose here other than to convey the information. Extending
the language specification to allow multiple return
arguments is the ideal solution:

int,int getLocation() {
    int x,y;
    ...
    return x,y;
}

...

void myFunc() {
    ...
    int x,y;
    x,y=getLocation();
    System.out.println("location is ("+x+","+y+")");
}

This is actually easy to implement (I've done it myself).

ADVANTAGES:
  *Current source would still compile with no problems.
  *Implemented correctly, current byte code would still run
with no problems.
  *In most cases (such as in the example) the code is at
least as clear as or clearer than using the current methods.
  *Dramatic improvement in the performance of classes that
currently rely on helper objects (assuming they are rewritten).
  *Very dramatic improvement in methods that parse String
objects.
  *Increased interest in upgrading development tools to take
advantage of the latest specifiation (you'll sell more
copies of Forte).
  *This method is much more elegant/intuitive than the C++
method of passing references as arguements.
  *Not using helper classes is slightly more secure.

DISADVANTAGES:
  *Source code is clearly not backwards-compatible.
  *It may be difficult to implement in such a way that the
generated byte code is backwards-compatible.
  *Java would arguably become a little less 'object-oriented'.

SIDE ISSUES:
  *RFE's for return argument overloading would logically
follow. This would clearly make source code less legible.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. N/A
2.
3.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
(see description)

---------- END SOURCE ----------
(Review ID: 164181) 
======================================================================