Alex Miller lives in St. Louis. He writes code for a living and currently work for Terracotta Tech on the Terracotta open-source Java clustering product. Prior to Terracotta he worked at BEA Systems and was Chief Architect at MetaMatrix. His main language for the last decade has been Java, although Alex have been paid to program in several languages over the years (C++, Python, Pascal, etc). Alex has posted 43 posts at DZone. You can read more from them at their website. View Full User Profile

Java 7 Predictions

01.22.2008
| 21761 views |
  • submit to reddit

So, we're a few weeks into the new year and it's time for my predictions about what will make it into Java 7. My best guess is that a Java 7 SE JSR will be created in the next couple months to have it ready before JavaOne.

The list you'll find below summarizes the majority of Java 7 features that have been talked about at one point or another and gives my own personal best guess as to the likelihood of inclusion. Note that a) these are my own personal guesses and do not reflect the actual activity of anyone involved in the JCP and b) these don't necessary reflect my own personal desires, just what I think is most likely.

FeatureChanceComment
JSR 294 SuperpackagesYes - 90%OSGi controvery aside, I think 294 and 277 will exist in some form
JSR 277 Java ModulesYes - 90%ditto above
JSR 203 NIO 2Yes - 95%Work is mostly done, adds many important improvements
JSR 275 Units and QuantitiesYes - 70%Progress is far along but there have been some questions on whether this should be in the JDK
JSR 310 Date and TimeYes - 90%There's a strong desire for this and progress has been excellent
JSR 107 Cache APINo - 5%Despite occasional blips on the radar, I don't see 107 making a comeback in time for Java 7
JSR 166 Concurrency UtilsYes - 95%Mostly some evolutionary additions plus the new fork/join library
JSR 225 XQuery API for JavaYes - 90%Pretty far advanced
JSR 284 Resource Consumption ManagementMaybe - 60%Hard to judge this one - there is a proposed final spec and seemingly interested support from major players, but not too much info out there.
JSR 296 Swing App FrameworkYes - 95%Seems far along and well-liked
JSR 295 Beans BindingYes - 90%Lots of progress
JSR 303 Beans ValidationYes - 70%I get the impression this is a key piece with the other Swing items, but there is far less info out there. I'm assuming it will solidify.
Java Media ComponentsYes - 80% Seems like Sun is strongly interested in filling this gap to compete against Flash, Silverlight
JSR 255 JMX 2.0Yes - 95%Far along, many useful improvements
JSR 262 Web Services Connector for JMXYes - 95%Available now
JSR 260 Javadoc UpdateNo - 10%This has been strung along for several releases now - I see no hope or interest that anyone will pick it up for Java 7
Reified GenericsNo - 20%Seems like a long shot to me. Could be an upset for me, but my gut says no.
Type LiteralsMaybe - 60%I think some useful class or reflective helper will be added as a small stopgap to no reified generics.
JSR 308 Type AnnotationsYes - 80%Prototype available now
Type InferenceYes - 80%I think some type inference additions will be added, particularly those that allow the generic types on LHS to be inferred.
ClosuresYes - 70%I think there is enough interest in this that something will be added. I don't think it will be BGGA as it currently stands, but rather something that evolves from that as a starting point. Syntax is likely to change. I'd say the control abstraction aspects are less likely to be included.
ARM BlocksNo - 20%Generally, I'd say no, unless they end up getting included instead of closure control abstraction.
XML SupportNo - 0%Not a chance
Property supportMaybe - 40%I'd say this isn't dead but that there is indifference from a large segment of the user base and splintered support from the rest. I don't see the big players pushing any particular solution to this. I've said Maybe but only as a long shot.
BigDecimal operator supportYes - 90%Seems like a duh to me
Strings in switchYes - 90%Easy and useful
Comparisons for EnumYes - 80%Bit more of a stretch but still really useful
Chained invocationsMaybe - 50%Too early to say on this one.
Extension methodsMaybe - 50%Also too early to say - I think this one depends a lot on where closures goes and how badly this is needed to retrofit collections with wherever we end with for closures.
Improved catchYes - 80%Seems to have a lot of support
JSR 292 invokedynamicYes - 90%I think JSR 292 will produce some JVM changes in Java 7, probably most likely an invokedynamic. But John Rose has taken JSR 292 to a broader place and is really using it as an umbrella for many potential dynamic language optimizations like tail call optimization, tuple support, and more in the JVM. Unlikely that any of this will leak out to Java 7 the language though.
Tiered compilationYes - 70%Work on this seems active enough that there will be some updates in this area, although it's difficult to tell exactly what that will mean.

So there you go - those are my predictions. We'll see how I do in the coming year. If you're interested in watching the Java 7 space, check out my Java 7 link blog (RSS).

Published at DZone with permission of its author, Alex Miller.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Neal Gafter replied on Tue, 2008/01/22 - 12:53pm

I believe BidDecimal operator support won't happen because we can't change the meaning of the "==" operator without breaking backward compatibility.

Mark Mahieu replied on Tue, 2008/01/22 - 4:56pm

It certainly feels like ARM blocks need a number of details thrashed out before they can be considered a real contender.  See here for some thoughts on the matter (and an attempt at a prototype).

As for reification - whatever happened to the EGO approach here ?  Didn't one of the authors join Sun's compiler team recently?

 

Andres Almiray replied on Tue, 2008/01/22 - 6:37pm

Great compilation of proposed features. I hope that chained invocation doesn't make it, is too magical for something that should be designed from the start, not as a afterthought (the client API that is) IMHO. It is worth nothing that some of those proposals are already available in Groovy, if someone cares to "feel" it today and probably send some feedback to the appropriate JSRs :-)

Alex Miller replied on Tue, 2008/01/22 - 8:48pm

@ng100699 (presumably Neal Gafter) - thanks for the update. I'll assume by the lack of any other corrections, that the rest is all correct. :)

@mm49838 - yep, I think ARM will get a little more fleshed out, and who knows, it may have legs regardless of which way closures go. There have been some ideas sketched out for reification and even for reconciling the collections library to work with both but to my eye it's not pretty. I'm guessing it's too much, especially on top of closures and everything else.

@aalmiray - yep, I've been doing some Groovy recently and I'm finding it very useful in thinking about what Java would be like with some of these features.

Jeroen Wenting replied on Fri, 2008/01/25 - 1:33am

Good thing I've all those 1.5 releases stacked away because if this all goes through (or even a small part goes through) that's where the train stops, the ship docks for the last time, the aircraft gets grounded.

The wholesale destruction of the language and platform to please its enemies (and Sun's and IBM's marketing folks) that started with 1.6 would be completed in one fell swoop.

 

Rahul Thakur replied on Fri, 2008/01/25 - 3:29pm

no JSR-291?

Alex Miller replied on Sat, 2008/01/26 - 9:14pm

JSR 291 (aka OSGi R4) was approved in Aug 2007.  It's not contingent on Java 7 and will work on existing JDK platforms back to, I think, Java SE 1.2.  The question is really whether JSR 294 and 277 will be open enough that OSGi-based systems (which are now quite numerous) will be compatible with them.  If they are not, then I fear there will be a schism in users of the two module systems with people choosing one or the other, which would be a shame.

Oliver Plohmann replied on Mon, 2008/01/28 - 6:55am

If the introduction of closures is postponed I will definitely run mad at Sun. People that come from high-level languages and have to code in Java where there are no closures are pissed enough already. Sorry for the language. But this had to be said :-))).

 Cheers, Olli

prashant jalsutram replied on Mon, 2008/02/04 - 12:48pm in response to: Oliver Plohmann

Alex,

 This is really cool job and great to have a passionate developer in java community.

 Thanks

Prashant Jalasutram

http://prashantjalasutram.blogspot.com/

aslan ozturk replied on Thu, 2008/07/03 - 2:01am

very nice article.

tüp bebek 

taranfx fx replied on Sun, 2009/08/30 - 5:50am

There are lots of new things coming in for Java 7. The most noticeable thing about Java 7 is the performance. And i wrote this blog on  Benchmark Java 1.5 1.6 1.7 which shows where we are heading

Carla Brian replied on Thu, 2012/06/07 - 11:47am

It is really nice and reliable for me. It has good packages too and it is very useful. - Steven Delarge

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.