You could do this with a helper method // rename method to taste. public static Iterable $(Iterable iter) { return iter == null ? Collections.EMPTY_LIST : iter; } // later. List list = null; for(String s : $(list)) { }

BTW, I realize it will never happen as it could hurt backward compatibility. Some people may count on a NPE to be thrown. Man I hate backward compatibility.

You're right: I mis-read Joe's slides about Project Coin, which has a hex floating point literal slide at the end (perhaps to discuss how a previous change was done). Since the poll's only been up a few minutes and has had no votes for hexadecimal floating point literals, I've removed that option. Thanks for the catch.

Extension methods make programming especially with interfaces a breeze: e.g. all of the Collections, Arrays and other utility method classes can be used far more elegantly. This is the OO-variant of having static imports. Please take a look at how C# 3.5 implements extension methods and should you not be convinced do some coding with it and I am sure you will. This would also cure the demand for static or final concrete methods in interface definitions.

I don't get it...why is this a vote thing? My $.02 would be "Yes", let's get at least all of these things. The Java language needs things like this, which in my book are useful refinements.

Do we get multi-line strings, like: String sql = @"SELECT * FROM Company WHERE Id = 123"@;

Why not lose the try keyword? Every { } block can have catch and finally attachted to it.

Why not lose the try keyword? Every { } block can have catch and finally attachted to it.

Null handling is the biggest pain for me, by far. Interesting that you are ignoring it in the survey.

I just wrote the following: } catch (final ImporterException ex) { Logger.getLogger(B2ImporterBackingBean.class.getName()).log(Level.SEVERE, null, ex); FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(FacesMessage.SEVERITY_ERROR, ex.getLocalizedMessage(), null)); } catch (final IOException ex) { Logger.getLogger(B2ImporterBackingBean.class.getName()).log(Level.SEVERE, null, ex); FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(FacesMessage.SEVERITY_ERROR, ex.getLocalizedMessage(), null)); } catch (final NamingException ex) { Logger.getLogger(B2ImporterBackingBean.class.getName()).log(Level.SEVERE, null, ex); FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(FacesMessage.SEVERITY_ERROR, ex.getLocalizedMessage(), null)); } catch (final ParserConfigurationException ex) { Logger.getLogger(B2ImporterBackingBean.class.getName()).log(Level.SEVERE, null, ex); FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(FacesMessage.SEVERITY_ERROR, ex.getLocalizedMessage(), null)); } catch (final SAXException ex) { Logger.getLogger(B2ImporterBackingBean.class.getName()).log(Level.SEVERE, null, ex); FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(FacesMessage.SEVERITY_ERROR, ex.getLocalizedMessage(), null)); } catch (final TransformerConfigurationException ex) { Logger.getLogger(B2ImporterBackingBean.class.getName()).log(Level.SEVERE, null, ex); FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(FacesMessage.SEVERITY_ERROR, ex.getLocalizedMessage(), null)); } catch (final TransformerException ex) { Logger.getLogger(B2ImporterBackingBean.class.getName()).log(Level.SEVERE, null, ex); FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(FacesMessage.SEVERITY_ERROR, ex.getLocalizedMessage(), null)); } Someone, please help us end the madness

What happened to null safe operators a lot of people voted for on devoxx? From Stephen Colebourne's blog: // today String result = null; Foo foo = getFooMayBeNull(); if (foo != null) { Bar bar = foo.getBarMayBeNull(); if (bar != null) { result = bar.getResult(); } } // with null-safe operator String result = getFooMayBeNull()?.getBarMayBeNull()?.getResult();

I suggest that arrays support methods current available via helpers such as System.arraycopy Arrays.* Array.* and ArrayUtils.* By hacking the Object class, I have show that this change would work with Java 5+ and IDEs handle this naturally. The basic change suggested is that arrays have their own super-class rather than Object to hold calls to the relevant helper methods. A working example: int[] ints = {5, 4, 3, 2, 1}; System.out.println("ints= "+ints); ints.sort(); System.out.println("after sort() ints= "+ints); ints = ints.add(6); System.out.println("after add(6) ints= "+ints); Prints ints= [5, 4, 3, 2, 1] after sort() ints= [1, 2, 3, 4, 5] after add(6) ints= [1, 2, 3, 4, 5, 6] I have the code changes required on my wiki. ;)

How about operator overloading so I can define my own behavior for the bracket operators (among other things)?