Summarizing Java language changes for JDK 7

There haven't any changes to the Java language since J2SE 5.0 in 2004. But there are several planned for JDK 7, coming from a variety of sources (sic). Here's a quick summary:

1) Module support. Known historially as superpackages, though they are assuredly not, this promises to sit atop a variety of module systems to let developers partition big chunks of code more effectively.

2) Type Annotations. Step three in the popular annotations program, this hopes to further extend the reach of attaching meta-data to Java code by letting developers put it in more places.

3) And of course, Project Coin. The small useful changes to soothe away some of the common irritations with the langauge. The most likely handful have been picked (Strings in switch, improved exception handling, ARM blocks, improved type inference, Null safe operators, and simplified varargs), and there's another handful going through the mangle. Including some rather interesting ones for developers hoping to use JSR 292 to implement (better, faster...) a dynamic language on the JVM.

Some might be glad of that !

It's obvious that whoever was chosen to vote on these features don't represent enough of the Java ecosystem. One example of this is the lack of improved string handling...

I just don't understand why they can't implement two of the most basic features, that other languages have had for ages:

1. Multiline-string. Yes it is very useful in many cases. In SQL queries for example. It can't be too hard to handle, because they already handle multiline-comments.

2. Unescaped string. Regular expressions are actually used a lot, and it is extremely irritating to have to add double backslashes to everything. "(\\\\(\\\\d)\\\\)" scares people away. Even worse is the instances where you have to match a backslash, it then becomes "\\\\\\\\".... talk about ugly

Anyway. These are features that your everyday java coder would benefit from.

Posted by Pessimist on July 17, 2009 at 06:33 AM PDT #

You write "The most likely handful have been picked". By whom? For what? Using what process? Sorry if I am so dense, but it's been a bit confusing with the lack of a JSR.



Posted by Cay Horstmann on July 17, 2009 at 08:34 AM PDT #

Most of the upcoming stuff on project coin is quite interesting, and the more informal language change processes managed by Joe Darcy has balanced community review with some welcome open source style agility.

However, I also agree that it is a disappointment that the two proposals mentioned by Pessimist have been seemingly dismissed. I know they both were mentioned at the start of the process, but are nowhere to be found on Joe Dary's 'for further consideration' list ( From the perspective of a work-a-day java programmer, these seem like such fundementally useful features. I'm certain they would see more use than 'underscores in numbers' ( - which I don't doubt is useful, but will get magnitudes less use than a regexp literal (or other string escape helper)

I do wish these two features would be reconsidered. They seem to fulfill the project coin mission statement perfectly.

As a note and a workaround for the RegEx use-case, I highly, highly recommend the open source MyRegExp ( - He has Eclipse, IDEA plugins, and a standalone applet. It not only allows you to live test your regular expressions, but you can use it to encode and decode java escaped strings. I consider a regex instruction inside java source to be no better than a binary representation and this tool is my 'compiler'.

Posted by Adam Malter on July 17, 2009 at 11:12 AM PDT #

here's what Joe posted before the call outs for proposals

I don't think the list of small language will differ much even after the proposal call out. They already had changes in mind and if you're part of the coin mailing list you probably know that rejected proposals will not get explanations why they were rejected. Overall, the coin changes are very underwhelming - instead of getting one of the big changes for java (closures, properties, reified generics) were getting stuff like "strings in switch". There are a couple of changes that are definitely welcome but none of them will make you any more productive than you are now.

Posted by trichard on July 17, 2009 at 01:27 PM PDT #

When evolution leaves the java language, you'll get this snoozefest sold as a major upgrade. Time to move on, guys!

Posted by Sakuraba on July 17, 2009 at 07:03 PM PDT #

wow and this "Map<@NonNull String, @NonEmpty List<@Readonly Document>> files;" is as sure as hell more readably than wirint bgga-enabled code. Yeah right.

Posted by Sakuraba on July 17, 2009 at 07:05 PM PDT #

I agree that using lots of annotations in Java like that can make code hard to read, but I like having the feature in the bytecode, because other JVM languages can take advantage of it to store info not normally in Java.

Posted by Tom Palmer on July 18, 2009 at 09:12 AM PDT #

I agree that Java really needs multi-line strings and unescaped strings. I am tired of having to wait YEARS for features that other languages/platforms already have.

Posted by Ryan on July 20, 2009 at 12:55 AM PDT #

Why can't they use a voting mechanism to decide on features that should be added to the language? I completely agree that multi-line strings and non-escaped strings would be much more useful than some of the features accepted by the "committee".

Posted by Deepak on July 20, 2009 at 06:07 AM PDT #

ARM blocks? Is that an admission that closures & function literals will never be added to the language? I do hope not, but surely adding ARM blocks will be made completely redundant and probably will complicate adding closures too...

Posted by Kieron Wilkinson on July 20, 2009 at 09:38 PM PDT #

With respect to the "Simplified Varargs Method Invocation" proposal, wouldn't we be better off providing an alternative mechanism that converts:

foo(T... list)


foo(List<T> list)

instead of an array? It seems to me that we're better off fixing the underlying problem instead of trying to band-aid it.


Posted by Gili on July 21, 2009 at 02:46 AM PDT #

Project Coin had a completely open call for proposals and a very lively discussion among hundreds of community members. I am amazed that people think blog comments are the place to suggest language features three months later.

As an aside, some of the features suggested above were proposed, but the proposals weren't very good. Sun does not have the resources to fix up and run with every feature that might have potential.

Posted by Alex Buckley on July 23, 2009 at 09:41 AM PDT #

Once there was AOP. It was supposed to get non business logic concerns out of the code.
Now we have annotations. They're supposed to get non business logic concerns into the code.

Posted by Jürgen Weber on July 23, 2009 at 07:32 PM PDT #

) As an aside, some of the features suggested above were proposed, but the
) proposals weren't very good.

For multiline strings and unescaped strings, this statement is not true: proposal was enough detailed and was implemented. You can read one in coin mail list:

If you say, that one is 'weren't good': you must also point to criteria, which say: why this proposal "weren't good" and others (like indexed access collections, or JSR-292 related language changes) was good. Otherwise, such judgment of my work without any arguments will introduces the audience to deceive.

I.e. why this proposal was rejected is other question: I understand that Joe task (select 10 proposal from 140 (where 20 are good) with known time and complexity contraints ) was near impossible and if we choose any 10, other 'good' 10 proposals will be not selected. But this is normal process, which is discussed in mail lists.

Saying "proposal weren't good" instead understanding complex process is not a valuable position.

Posted by Ruslan Shevchenko on July 26, 2009 at 03:07 AM PDT #

Post a Comment:
Comments are closed for this entry.

A blog all about Java in all its flavors on all client platforms from smartcards to desktops and everything inbetween.


« June 2016