Some comments on D&R’s Java 7 wishlist
I listened to the Drunk and Retired’s Java 7 wishlist podcast this morning and had a few comments. If you haven’t listened to the podcast, then some of this may make no sense… :)
- Properties – I think something around properties would be cool, but I haven’t seen a properties proposal that I’m excited about yet. I think in this case, the devil is in the details. I concur with Charles that defining it on interfaces would be nice. So here’s my reason not to have properties (I’ll take my chances that Charles won’t kill me): no implementation/proposal exists that doesn’t suck in some way. And perhaps more importantly, maybe a non-sucky properties proposal is not possible. I don’t know. If the actual implementation added properties but made the whole language more complicated as a result, then I don’t think it would be worth it.
- Closures – I think from what I’ve read, it is far from certain that closures (or any other language features) will make it in to Java 7. Buried in this recap from Elliotte Rusty Harold on JavaOne, you’ll see near the end that Neal Gafter himself (the most visible proponent of closures) said at JavaOne that he didn’t think any language changes would make it into Java 7. So, at this point, I’d say no one really knows whether closures will be included. Generally, I think having closures and some form of control abstraction would be nice, but as with properties the devil is in the details.
- Superpackages – JSR 294 defines the superpackage stuff, which is really just a way of specifying a new visibility scope above the package level. So if you have a component with some public interfaces in a package and some private implementation details, you can declare that users of your superpackage (which at runtime may be a Java module ala JSR 277) can see only the interfaces, and not the implementation. This is something that can actually be checked at compile-time as the superpackages are defined with the code. You can already see tools doing this stuff – for example in Eclipse (really in OSGi) you can declare which parts of your project/bundle are public. I gather that there are some important differences between OSGi and JSR 294 in the granularity of definition.
- Named parameters – I have seen no one propose this, but I’ve been thinking for a while that it would be really helpful in situations where you have lots of optional parameters. It would be great for constructor injection, argument passing on a program interface, embedded DSLs/fluent interfaces, etc.
- Removing interfaces – I think it’s crazy to talk about removing interfaces. That said, I kind of understand what Charles is asking for and the closest thing I’ve heard is Stefan Schulz’s interesting proposal for meta-interfaces which I really like. It’s a way to define an interface of static methods that a class must “conform” to. I think generally the use cases discussed in the podcast are more instances of bad design, IMHO.
If you’re interested in more Java 7 stuff, check out my Java 7 page.
Hi! My name is Alex Miller and I live in St. Louis. I write code for a living and currently work for 
Concerning named parameters… when I hear people request this feature I always ask myself, “Why not just pass in a map of Strings to Objects?” I guess the only downside is that you lose the run time type information, but if you find yourself /really/ wishing for named parameters then it seems a small price to pay.
I suppose I’ll find out shortly if this is a really awful idea based on the next few comments.
I think that’s a big price, not a small one, personally. You could certainly implement the equivalent of named parameters using a Map with the value (or even a value/type pair). But that would not lend itself to tool support, javadoc, etc. In other words, you’d lose all the things you expect from a decent programming environment, which I think is enough that it’s not worth doing it.
I think the real argument around named parameters is whether they are useful in enough situations to be worth the added complexity. And really, I have no idea on either part of that equation (usefulness or implementation complexity).
Thanks for the follow-up! ;) We need to get you on some episodes. What do you say?
Ha ha…sure. I doubt I would be half as entertaining as you guys though.
It will be a sad day in Java world if we don’t get closures in Java 7. I think they are long overdue. Considering all the changes that would be required to the JVM, I can see why they wouldn’t make it in Java 7. Considering all the problems they solve and the flexibility they add to the language, I would rather see Java 7 delayed then skip closures.
@Mike: I hear ya. I think if we had closures and control abstraction, there are lots of future features and changes that could instead be done via closures instead of by extending the language. And that would enable us to make those changes in libs (not even in the JDK necessarily) intead of waiting for a new version of the JDK.
It will be interesting to see if the desire for things like closures will actually drive permanent forks to Java in the future. I’m not sure whether I think that would be good or bad. Would be bad if Java became JavaTM / NotJava+Closures / NotJava+Properties / … But would be good if Java forked off a closures version which proved to be so useful that it drove the fork back together and we started getting language changes bottom-up due to consensus of the Java community rather than top-down via the JCP.
I like the Named Arguments idea!
I responded more detailed my blog, have a look if you’re interested. :-)
@Michael: Awesome! You rock. Thanks for doing the work I’m too lazy to do. :)
@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.
@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.
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.
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.