Javalobby

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 605 posts at DZone. You can read more from them at their website. View Full User Profile

Plan B for Java 7: The Details

10.11.2010
| 7846 views |
  • submit to reddit

We Recommend These Resources

A few weeks ago when Mark Reinhold announced that there were two possible plans for getting Java7 out the door, most people seemed to be behind the Plan B implementation, which meant we'd get a lighter version of Java7 earlier, rather than wait for all the features. Mark has recently posted details on his blog about what is actually to be included in Java7, and in the subsequent Java 8 release.

 

Java SE 7 — Mid 2011

This makes Java 7 a very appealling release, while Java 8 will include some of the big ticket items:

 

Java SE 8 — Late 2012

The umbrella JSRs for both Java 7 and Java 8 have yet to be finalised, but this list gives a good indication about what we can expect from Java in the next few years. 

Tags:

Comments

Martijn Verburg replied on Mon, 2010/10/11 - 7:19am

I think for the typical Java developer there's not too much that screams 'upgrade to me!!!', but there are some gems in here:

One of the *big* ones for all of you JVM langauge enthusiasts, and it's JSRs like this that I feel will continue to increase the lifespan of the Java platform as a first choice platform for developers.  Being able to choose the language tool that suits your domain problem yet still can use the power of the core Java APIs is a compelling argument to stick with the platform.  I expect to see Java developers learning at least one other language on the JVM to co-exist with Java for their problem solving needs.  This JSR helps bring dynamic languages literally up to speed with Java on the JVM.
Automatic Resource Management is the big one here, it'll be interesting to see if the engineers can get it working right the across all of Java's resource APIs (JDBC/File/Socket etc etc).  This will genuinely help reduce nasty bugs in most people's code.  Who hasn't forgotten all of the corner cases in closing off a resource?  I've certainly made that mistake more than a few times.
Pretty exciting, concurrency is increasingly important, we have lots of cores to play with now :).  Concurrency is still hard and anything that helps the developer out is a bonus.  Does this make Java  first clas language for dealing with Concurrency?  I'll leave that debate to the concurrency experts (I'm not qualified by any stretch of the imagination).

A potentially massively impacting change.  The ability to write code that deals with I/O far more efficiently is a real boost to anyone writing hard core server side apps.  I can see the App Server folks and the like jumping all over this one.

Those are my picks to get excited about!  What are other people lookign forward to?

Cheers,

Martijn (@java7developer - twitter)

Donny A. Wijaya replied on Mon, 2010/10/11 - 10:29am

One thing that I want to see to be removed: the need to use getter/setter for properties access. They're very annoying

cowwoc replied on Mon, 2010/10/11 - 11:33am in response to: Donny A. Wijaya

The vast majority of the time, Properties are an anti-pattern: http://www.c2.com/cgi/wiki?TellDontAsk

If you eliminate this anti-pattern, you will find that the vast majority of the time you don't need a language-level paradigm for properties, methods are enough.

Jacek Furmankiewicz replied on Mon, 2010/10/11 - 11:52am in response to: cowwoc

Wrong.

Properties are badly needed to enable easy data binding. Right now to do data binding you need to do the horribly verbose PropertyChangeSupport logic in every setter...it's a nightmare. Especially compared to how easy it is to do databinding to properties in C#.

Try to set up proper two way data binding between UI properties and a bean using BeansBinding and you will be cursing the lack of bindable properties in 30 seconds flat.

Alessandro Santini replied on Mon, 2010/10/11 - 4:30pm in response to: Jacek Furmankiewicz

Never agreed with you like in this case. It is not about encapsulating a field with some methods, it is about having a consistent method of accessing a property.

Otengi Miloskov replied on Tue, 2010/10/12 - 11:07am

I would like to see too the remove of getters and setters I would like to code an entity class as this with Java even with an annotation to note is an accessor property:

@Entity public class Customer implements Serializable { @Accessor private Integer id; @Accessor private String name; @Accessor private String address; }

Jacek Furmankiewicz replied on Tue, 2010/10/12 - 11:40am in response to: Otengi Miloskov

It's called Lombok :-)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
"Starting from scratch" is seductive but disease ridden
-Pithy Advice for Programmers