Skip to main content

Which proposed Project Coin language change most interests you?

Something else (please comment)
8% (27 votes)
Multi-exception catch
49% (158 votes)
More concise calls to constructors with type parameters
15% (48 votes)
Call methods with exotic names
3% (9 votes)
Bracket notation for collections
26% (83 votes)
Total votes: 325

Comments

simple thing

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)) { }

simple thing

Thx Peter, I use this Iterable interface a lot, doing a lot of complicated things and I actually never thought of such a simple thing as using a static import.

complicated thing

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.

Hex literals are in JDK 5

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 as in C# 3.5

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.

+1

I'm registering strong agreement with this one.

I've been using Scala quite a bit lately, and I've found Scala's implicit extension methods are an incredible powertool. It seems like such a simple peice of compiler sugar, it should definitely be added!

Don't get it

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.

Multi-line strings

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

lost the "try" keyword

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

lose "try" keyword

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

Null Handling

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

Mutli exception catch FTW

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

Mutli exception catch FTW

trying to help: try { ... } catch (Exception e) { Logger.getLogger(B2ImporterBackingBean.class.getName()).log(Level.SEVERE, null, ex); FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(FacesMessage.SEVERITY_ERROR, ex.getLocalizedMessage(), null)); }

Mutli exception catch FTW

Totally.

Null-safe operators

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();

Suggest supporting arrays as objects.

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. ;)

Suggest supporting arrays as objects.

Unfortunately, three of the most useful methods - equals, hashCode and toString cannot be added in this way, as that would be backwards incompatible with the current definition of those methods on arrays.

Operator overloading?

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