Comments on: Some comments on D&R’s Java 7 wishlist

by: Alex Miller - Java 7 Roundup (August 20th)

Mon, 20 Aug 2007 14:08:30 +0000

[…] There was a pretty good discussion of Java 7 this week on the Drunk & Retired podcast #104. I had some followup comments that I blogged as well. […]

by: Alex

Sat, 18 Aug 2007 01:34:08 +0000

It seems like it would be difficult to make this work generically without making the parameter names available in the bytecode. I’m sure there is some partial solution that would just work in the compiler by doing the translation and just replacing the method call, but seems like you would need reflection to really get the most useful version of named params.

by: Saurabh

Fri, 17 Aug 2007 18:39:54 +0000

Can this idea be extended to making available the name of the method parameters at runtime using reflection?
At my current workplace, we are using JConsole to invoke JMX calls on the JVM. We end up with methods that take 2 or more integer arguments and we have to go back to the source code to work out what each parameter is supposed to be.
Making the method parameter names available at runtime would be a nice thing to have.

by: Alex Miller

Thu, 16 Aug 2007 01:36:27 +0000

@Talden: Generally, I agree, although it’s possible that some other feature for Java 7 could be made simpler if closures were included. I can’t think of such a thing, but it’s possible.

Also, as far as I know, JSR 305 is not dependent on JSR 308 or Java 7. I believe there is already a prototype impl available. JSR 308 (potentially for Java 7) would allow JSR 305 annotations to be used in a greater variety of locations.

by: Talden

Thu, 16 Aug 2007 01:07:04 +0000

@Mike: “It will be a sad day in Java world if we don’t get closures in Java 7.”

I’d rather reduce that statement to “It will be a sad day in Java world if we don’t get closures in Java”. I’m a closures proponent, I’d really like them in J7 however I wouldn’t want to seriously delay J7 either as there are many other things to get into the wild as well. There’s no reason a feature targeted for release X can’t be delayed until release Y to let other features through. I’d rather a J7 soon and a J8 soon after.

There will always be, as is already the case, those projects that leap from X to Z by skipping Y. As long as some segment of the user-base finds compelling changes in Y it’s still worth getting them out there and bedded down sooner if the feature is ready - don’t create artificial dependencies.

Let’s see some or all of JSRs 305, 308, 203, 275, 310, 166 getting out there…

Let’s see if smaller, more easily digested changes such as short-instance-creation can get out there…

Meanwhile, let’s keep working on the complex issues such as closures until they’re right.