Bruce Chapman's Blog

JSR Archives

Continuations JSR dead

So JSR 323 has failed the review ballot, which means it's out before first base. It never quite looked viable.

What is interesting is the voting comments from the JCP Executive Committee. It seems that the later voters are referring to voting comments made by earlier voters. Which means that the later voters can see the voting comments (and presumably the votes) made by the earlier voters BEFORE THEY VOTE. Is that a fair way to conduct a ballot?

As usual the boring part is IBM's comment (less the first paragraph)

"IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model."

They make this same comment on every ballot. Sometimes it is slightly relevant. In this case at least it is completely irrelevant. So IBM, if the intended audience of your message hasn't got it yet, I doubt they ever will, for the rest of us (and I presume the message is not targeted at me), you're starting to sound pathetic.

When I voted Hani onto the JCP I did so because I wanted someone who'd call a spade a spade. I look forward to the day when Hani's votes are postfixed with something like

This vote is based on the technical merits of the proposal and not on whether or not IBM makes statements about licensing terms in their vote comments which admit to not necessarily being directed at the particular JSR being voted on.

Maybe if a few other EC members started playing the same silly game as IBM, then the childishness of it might become apparent to them.

And one last observation, Oracle gets two votes, one as Oracle, and one as BEA, although they only exercised one of those votes this time.

A JSR for Continuations?

If (newly announced) JSR 323 is viable, it looks like it might give us continuations.

If you can move a thread to another JVM and have it run there, you can also presumably move it to storage, pull it back onto the original JVM some time later, and have it continue execution.

This might be worth watching.

Closures and Multiple Return Values

In javaposse 150 the guys were talking about something and veered off on a tangent talking about multiple return values and tuples and such like. Next up they talked about the closures JSR. That sparked a thought that maybe we could transform the multiple return values problem in order to solve it using closures.

So what if instead of returning multiple values, a method returned void, but had another formal parameter which was a closure to receive the results of the method?

I've downloaded the closures prototype compiler (2007-11-20 version) and had a play with that idea. Now if it had been a complete disaster you wouldn't be reading this, because I wouldn't have blogged about it, but you are reading it so lets get on with it.

Here is a method to convert rectangular to polar coordinates and pass the results (r,theta) to a receiver closure.

    static void toPolar(double x, double y, {double, double => void } rThetaReceiver) {
        rThetaReceiver.invoke(Math.sqrt(x*x + y*y), Math.atan2(y, x));
    }

And this is how you use it

        // test toPolar
        toPolar(3,4,{double r, double theta =>
            System.out.format("3,4 = %f<%fRad%n",r,theta);
        });

Here is the complete class with both converters, and a round trip test. Note how the round trip nests the closures.

package closures.multireturn;

/**
 *
 * @author bchapman
 */
public class RectangularToPolar {
    
    static void toPolar(double x, double y, {double, double => void } rThetaReceiver) {
        rThetaReceiver.invoke(Math.sqrt(x*x + y*y), Math.atan2(y, x));
    }
    
    static void toRectangular(double r, double theta, { double, double => void} xYReceiver) {
        xYReceiver.invoke(r * Math.cos(theta), r * Math.sin(theta));
    }

    public static void main(String[] args) {
        
        // test toPolar
        toPolar(3,4,{double r, double theta =>
            System.out.format("3,4 = %f<%fRad%n",r,theta);
        });
        
        // test toRectangular
        toRectangular(5, Math.PI / 2, { double x, double y =>
                System.out.format("5<90deg = %f,%f%n",x,y);
        });

        // test Round trip - toPolar and back to rectangular
        toPolar(3,4,{double r, double theta =>
            System.out.format("3,4 = %f<%fRad%n",r,theta);
            toRectangular(r, theta, { double x, double y =>
                System.out.format("%f<%fRad = %f,%f%n",r,theta,x,y);
            });
        });
    }
}

And here's the output

C:\projects\quickhacks\src>javac closures\multireturn\RectangularToPolar.java

C:\projects\quickhacks\src>java closures.multireturn.RectangularToPolar
3,4 = 5.000000<0.927295Rad
5<90deg = 0.000000,5.000000
3,4 = 5.000000<0.927295Rad
5.000000<0.927295Rad = 3.000000,4.000000

This looks promising. I'll keep exploring.

Continue Reading...

This work is licensed under a Creative Commons License.