I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 640 posts at DZone. You can read more from them at their website. View Full User Profile

Do You Really Need Java 7?

  • submit to reddit

It's a long wait for Java 7 and there's a lot of speculation about what we can expect once the final JSR is out. I took a look through the what's coming up to find out if there's anything I actually needed.

One thing that struck me about the whole thing is that maybe there's less demand for a new Java version because of the following reasons:

  1. The advancements made in both Java 5 and 6 have satisfied most of our development needs from the JDK.
  2. One of the main things I was looking forward to in future versions was the reduced footprint from the JRE. Once again, that's already cleared with with Java 6 Update 10. 
  3. We've got so many frameworks out there, that we are no longer so dependent on JRE changes
  4. There's a whole lot of focus on JavaFX releases from Sun. Maybe this has taken over from old fashioned excitement about the next major version of Java.

Either way, from reading various breakdowns and predictions about Java 7, I decided to put together my own list of what I'd like to see happen.

No Closures

Neal Gafter has a closures prototype completed, but I'm still not convinced that it should be part of Java 7. When I interviewed Joshua Bloch a few months back I asked him for his opinion on the closures debate. 

As readers of the first edition know, I value simplicity and clarity above all else. So it should come as no surprise that I don't want to see anymore major additions to the Java programming language. It's already as complex as a language should be. If Java programmers want to use features that aren't present in the language, I think they're probably best off using another langauge that targets the JVM, such a Scala and Groovy.

I agree 100% with this. Simplicity is key and the thought of having closures in there just muddies the waters.  This feature has caused so much of a split in the Java camp, that it just doesn't feel right to include. Not for now at least. For those of you unfamiliar with closures, there's a good introduction here.

Better I/O

This is definitely something I'm looking forward to. The introduction of NIO was great a few years back. JSR 203  will include much better filesystem APIs. There's a good overview of the JSR over at David Linsin's blog, and on this article from Java.net. 

Making Swing Easier

I'm not saying it's too complicated right now or anything, but JSR296 would be a welcome addition. It has the aim of making desktop applications easier to create in Swing - which is something that's needed. The Eclipse RCP has raised the bar for desktop applications, and Swing needs to be able to compete. This specification will make it easier, and faster,  to get your Swing applications off the ground.

There's an excellent article on the Sun Developer Network outline how the new Swing Application Framework can be used. Geertjan has also written a nice account of what it actually means. 

If you want to keep track of what's going on in Java 7 discussions, the best place to go is Alex Miller's linkblog on the topic. It's been a great basis for me to get some insight into what may be coming up.

You've read what I'd like included, but what do you think is most important? And do you actually need Java 7?


Jacek Furmankiewicz replied on Fri, 2008/10/17 - 9:15am

I disagree (strongly). Java is starting to fall (badly) behind all other languages (especially C#) in terms of   basic language features, e.g.:

- multi-line string literals (Groovy/Python/Ruby have them)
- strings that do not need escaping for regex expressions or embedded paths (C#/Python have them)
- regions (great for organizing source code, C# has them)
- closures (for crying out loud, Delphi will have them...at this rate COBOL will get closures faster than Java
- automatic resource management (ARM I believe it's called)
- "real" properties that are ready for data binding out of the box (i.e. without having to manually code firePropertyChange() on every set())
- a data binding solution that doesn't suck (i.e. doesn't require you to write more code to support it than it's supposed to replace)

And I am not even talking about advanced features like
- mixins (Ruby)
- LINQ (C#)
- lambda functions (Python)


If Java is supposed to thrive in the long term, developers must be excited about it, not just grudgingly accept it because it's the best way to earn a paycheck right now.



Andy Leung replied on Fri, 2008/10/17 - 9:25am

The JSR296 sounds like they covert their entire good servlet framework into desktop, that's it.  I really want to have this on desktop application.

To Jacek's comment, I think it's more of IDE features you are refering to.

Ricky Clarkson replied on Fri, 2008/10/17 - 9:27am

Can you please explain to me how C# can have closures and Java cannot?  These are very similar languages with similar communities.  Is there something about the Java language or its programmers that make closures unworkable?

James Sugrue replied on Fri, 2008/10/17 - 9:38am in response to: Ricky Clarkson

It's true we could have closures. But just because C# has them doesn't make it necessary that Java has. Personally, I'd like to see what the addition of closures would really help out with?

James Sugrue replied on Fri, 2008/10/17 - 9:43am in response to: Jacek Furmankiewicz

Very interesting points Jacek. And maybe I'm wrong about Closures.  My main concern is that I  don't want Java getting too bloated - I could be worrying about nothing. 
It seems building on the VM with languages like Groovy seems to be the thing to do these days rather than adding to JDK itself. 


Geoffrey De Smet replied on Fri, 2008/10/17 - 11:02am

I am not waiting on any shiny new language syntax, but I am waiting on the new Date and Time API. The guys of that API are doing a good, transparent job. The current java.util.Date class is very unreliable: the birth date you write to another system can actually be different then what you get from that system, because of timezone and daylight saving. It's about time they cleaned up Date and Time.

Jacek Furmankiewicz replied on Fri, 2008/10/17 - 9:47am in response to: James Sugrue

I hate to hear comments like these..."just use Groovy or Ruby"...it's nearly impossible to get any large corporation to switch to a totally different language (even moving up to a newer version of Java is a challenge sometimes). We need Java to be able to compete head on with all of them instead, since it already has such an established marketshare and developer mindshare.

Just my $0.02.

P.S. I wonder how are we supposed to trust Sun with the stewardship of Java, if they built Project Kenai on JRuby on Rails instead? if you believe in Java (and JSF) then use it!

Jacek Furmankiewicz replied on Fri, 2008/10/17 - 9:54am in response to: Andy Leung

How so? Hardly any of these are IDE-related...

a) multi-line strings, e.g. for entering multi line SQL queries (assuming the same ''' syntax as in Groovy or Python):

String query = '''
FROM mytable
WHERE something > 5

b) string literals that do not need escaping for regex, e.g. like in C#

String regex = @"[a-zA-Z]*\s"; (instead of "[a-zA-Z]*\\s")


String path = @"C:\Program Files\My App\myapp.exe" instead of  "C:\\Program Files\\My App\\myapp.exe"

c) all the property/data binding issues are explained here as well:


(see "what is the problem we are trying to solve" section)

etc. Java needs to start catching up to its competition instead of wasting valuable resources on new languages with many questionable issues (*cough* JavaFX *cough*)

Ricky Clarkson replied on Fri, 2008/10/17 - 10:09am in response to: James Sugrue

You seem to have inserted some logic that I didn't write.  Java doesn't have to have closures because C#, PHP, C++, Delphi, JavaScript, Ruby, Python, Haskell, Scala, Groovy, Smalltalk, Lisp, D, VB.NET and Perl do, but because they're useful.  That's why closures are in those languages.  (Yes, I know closures aren't completely in C++ yet, but they're in Boost regardless of what happens with the standardisation)

Here's an example where closures are useful:

List<Integer> lengths = listOfStrings.map(string =>  string.length());

There are many more, and you can write them all in Java today, at the cost of unreadable code.

Otengi Miloskov replied on Fri, 2008/10/17 - 10:38am in response to: Ricky Clarkson



It is dumb to think that Java doesnt need to evolve with the basic things even PHP for god sake will have closures and Java people always talked that was a noob language. I don't want Java to become Haskell or Scala just keep little bit up with the popular Languages as C,C++, PHP, Python, C#, VB.Net and Ruby. It is a shame the direction is taking Java the language, It will stay like Cobol for 50 years as that? If is it  Im done with Java and better move on to C# or another alternatives.

Sun wasting time with JavaFX that nobody is interested, Look at Flex and now with Flash 10 even now runs on Linux pretty well and Silverlight 2 it is running in firefox 3 in my Mac. WTF is doing Sun??. Should put power on Java and the real value not in hypes and Fads.

Im very dissapointed with Java direction even I will thank them if they include delegates to Java so event programming is little more fun and easy to use and less verbose.

Note: If for closures we need to use another language take a loook to Clojure is pretty cool and minimalist and powerful and have very good performance.

Arek Stryjski replied on Fri, 2008/10/17 - 10:41am

The short answer is yes (I think all Jacek and ge0ffrey points are important.)

But I'm very suprised by your point 4. Who needs JavaFX?

From one point we have Groovy from other... Eclipse Silverlight. Yes this is not a mistake. Look:

It it is true what Microsoft together with Eclipse will do the next generation of open-source Silverlight for all 3 OS, and both browsers (yes only IE and Firefox) and we could use Java not C# then why should we invest any time in JavaFX?

James Sugrue replied on Fri, 2008/10/17 - 10:50am in response to: Jacek Furmankiewicz

You're right Jacek - it is probably difficult for corporations to turn around to using Groovy or Ruby.

So really, it sounds like we should be pushing to get Java7 on the road as soon as possible.

James Sugrue replied on Fri, 2008/10/17 - 10:51am in response to: Arek Stryjski

Just on the JavaFX thing - it's just my observation that there's a lot of focus on it. For me, the jury's out on whether it is right or wrong to invest time in JavaFX.

Otengi Miloskov replied on Fri, 2008/10/17 - 10:58am in response to: Arek Stryjski

Silverlight 2 is interesting, I did some samples with IronPython. But Im more into Flex it is getting also interesting and I use it with Python PyAMF or Java with JSR311 Jersey. But I would like more support for Flex with Java, Sun should do that effort instead wasting time with JavaFX. Plus need need Java Closures!.

Michael Finger replied on Fri, 2008/10/17 - 10:58am

What, no love for join/fork? No exactly as exciting without closures though...

Jacek Furmankiewicz replied on Fri, 2008/10/17 - 10:59am in response to: James Sugrue

Assumming it will have any of these...I know the Sun guys already rejected properties (what????? this is crucial for any apps that want to easily use databinding) and it seems closures are out too (pretty sad).

P.S. One extra thing for me that's in Java 7: most of the glaring GTK+ bugs in Swing have been fixed, so Swing under Linux actually looks good now. Finally.

Otengi Miloskov replied on Fri, 2008/10/17 - 11:07am in response to: Jacek Furmankiewicz

yeah that is good point because last time I checked Swing fonts on GTK sucked and sometimes there was bugs with combo box drop down arrow. Also I love JSR311 and the spec of JEE6 it is coming great.

But please to Java the language dont let die, it is a simple and minimalist language and useful that moved the software industry to the next level but it have to evolve little bit.

JeffS replied on Fri, 2008/10/17 - 12:39pm

What's so great about closures?

 I know lots of people are into functional style programming, and being able to pass around functions like you can in Javascript.

 But what is the real benefit?  I've seen this paradigm being supported in stuff like Javascript and C#, but it hasn't made want to use those languages over Java.

 Also, there is a huge cost to adding more features to a language, no matter how "cool" many devs might consider those features - and that's complexity.

Remember, one of the orignal value add propositions of Java over C++ was that it was a much simpler, cleaner language that was much easier to learn and use.  And thus, over the years Java devs and proponents have always bagged on C++ because it has "too many features" and it's "too complex".  And now, many of these same proponents want to keep bolting on new features, in an effort to keep up with the Jones, and continually make Java more complex (and, ironically, gradually become more and more similar to C++).

 Look at what has happened with Java Generics.  Generics are a nice addition to Java for some uses, and basic usage.  But it has some major dark corners and gotchas, and people have really complained about Java's implementation of Generics.

 So what I'm getting at is that there better be a major, huge, massive, gigantic, no-brainer, obvious, benefit to adding Closures to Java, that also makes developers have orgasms and brings on world peace, because the cost in added complexity is huge.

Besides, you can already use Closures in Groovy, and you can easily intermingle Groovy code with Java code, and they all compile down to the exact same byte code.

Also, you can just as easily add Groovy to your programming environment, or get corporate approval, as you can developing on and deploying to a completely new JRE and JDK.

Harald Krake replied on Fri, 2008/10/17 - 12:55pm

When it comes to new (enterprise-) projects, Java is facing a competitor which is getting stronger and stronger: DotNet. Therefore the Java platform must evolve in many ways, and one certainly is the language itself. You're not forced to use closures or reifiable generics, but it is important to keep the "product" up to date. Otherwise decision makers will eventually consider Java as outdated. This would be fatal for the whole platform -- including all those new languages like Groovy, Scala and whatever comes next. Just my 2 cents...

Ricky Clarkson replied on Fri, 2008/10/17 - 1:47pm in response to: James Sugrue

Having looked through the language spec, which after 3 years is alpha, I see a Scala-like domain-specific language for GUIs, with static typing and type inference.  It has interesting variable binding techniques, related to Functional Reactive Programming, an interesting research area.  But for so little to have happened in so much time suggests that it would be a waste of time to look at as a Java replacement, especially as it's not a general purpose language at all.

Incidentally, you could implement it in Scala as a library with a bit of extra noise.

Ricky Clarkson replied on Fri, 2008/10/17 - 1:49pm in response to: Jacek Furmankiewicz

Properties are perfectly implementable in library code.  Closures might help this somewhat.

JeffS replied on Fri, 2008/10/17 - 1:52pm in response to: Harald Krake


When it comes to new (enterprise-) projects, Java is facing a competitor which is getting stronger and stronger: DotNet. Therefore the Java platform must evolve in many ways, and one certainly is the language itself. You're not forced to use closures or reifiable generics, but it is important to keep the "product" up to date. Otherwise decision makers will eventually consider Java as outdated. This would be fatal for the whole platform -- including all those new languages like Groovy, Scala and whatever comes next. Just my 2 cents...


Well, so long as the implementation is completely non-obtrusive, I'd be fine with it.

 But I will add this.  Many (including me) argue that C++ is not quite the beast that many make it out to be.  You can always use a common subset, and go from there - and add on stuff like template metaprogramming as needed.

 So I guess Java is going in that direction.

Ricky Clarkson replied on Fri, 2008/10/17 - 1:53pm in response to: JeffS

"What's so great about closures?"

Not a lot really.  It's like asking what's so great about recursion.  For both closures and recursion, using a language that doesn't support them involves using poor emulations of them, such as Java's anonymous classes, or C# 1.0's delegates.

Take a look at Guy Steele's talk, Growing a Language (the video and the PDF are available).  Lacking closures makes it hard to grow a language, because user-supplied control structures look nothing like the built-in ones (and in Java's case, they look awful).

Try using fork/join for a while with Java, then with the BGGA prototype.

Serge Bureau replied on Fri, 2008/10/17 - 1:54pm

I understand the nercousness after the bad decisions with Java5

Annotations, autoboxing should not be there at all, and generics is just an awful patch.

Closures would be much more useful than any of them.


Talking about simplicity ,where was Joshua when Java5 was conceived ? I do not see simplicity in the3 features I just mentionned.


Closures on the other hand is an easy concept.

Ricky Clarkson replied on Fri, 2008/10/17 - 1:55pm

As Groovy has the same syntax as Java plus some extra bits, I have to question the doublethink that says closures are good for Groovy but dangerous for Java.

Are you people just lying on purpose?  Do you know you're doing it?

Ricky Clarkson replied on Fri, 2008/10/17 - 1:59pm in response to: Serge Bureau

Congratulations, Serge.  You've said something reasonable!

There's some value in the approach Sun took to generics, but it's certainly simpler in .NET-land, where you can just use Foo<int> and you never have to box.  It's nice in Java that generics have no runtime cost.

Mark Thornton replied on Fri, 2008/10/17 - 2:00pm

I've been using the Fork/Join framework (aka jsr166y) for a while, so I'll be happy to see it in Java 7.

As it happens my usage would not benefit from closures (the subtasks are not that small).

Mikael Grev replied on Fri, 2008/10/17 - 2:07pm

Many of you seem to mix up what you want and what 95% of the general Java developers want. Noone in a real company is choosing C# over Java beacuse it has more language features. Corporations makes decisions of totally different grounds and anyone that works in a company that has more than ten employees knows this.

Ease of use and consistency is what matters. Availability of developers that knows the language matters. Availability of components/frameworks with good support matters. Making the language more powerful at the expense if ease of use works against all this and it is bad for Java, but good for you. Joshua Bloch is right. Period. Anyone that has truly understood his Effective Java books knows this to be true.


JeffS replied on Fri, 2008/10/17 - 2:04pm

On another note, someone else here mentioned LINQ.

 I'm no MS fan, but quite frankly, LINQ is pretty kick-@ss.  It's much nicer than regular ORM like JPA/Hibernate.  In fact, LINQ is a layer on top of ORM datasets in ADO.net, and integrates simple query syntax within the language.  Very elegant, clean, and powerful.

I'd rather see something similar in Java, as a higher priorty than Closures.


And on a completely other side note - I think Sun is too strapped financially to "keep up with the Jones".  Sure, other corps are contributing via JSRs.  But Sun just seems to be behind the curve on everything, as the sole Java source.  And they don't generate all that much revenue from Java (JME licensing on cell phones, and licensing from IBM and Oracle on their JDKs/App servers passing the JCK and having the Java name). But the R&D cost to keep Java moving forward is rather large.

There are rumors that Sun could be acquired, due to it's plummeting stock.  It'd be nice to see a bigger, deeper-pocketed, player inject some new life into Java.

Sun's engineers are doing awesome work - Java 6, NetBeans, Glassfish, etc.  But I sort of doubt they'll be able to keep up.

Jacek Furmankiewicz replied on Fri, 2008/10/17 - 2:14pm in response to: Ricky Clarkson

Yeah, but by "properties" I always understood something that is bindable out-of-the-box...the Sun guys seemed to understand properties as just replacements for get/set where you still have to add all the databinding plumbing (i.e. firePropertyChange) manually....

Comment viewing options

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