You Won't Believe This, But The Arrow Operator Is Coming To Java 7
And it means something completely different
Yes, the -> operator. According to Danny Coward, Sun Java SE Platform Lead, Java 7 will use the arrow operator for Java Beans property access:
Danny Coward talk PDF (p.27): Reading JavaBeans propertiesa.setFoo(b.getFoo()); a->Foo = b->Foo;
What's wrong with using the good old dot?
Most of the stuff mentioned are nice and useful. I like the XML literal and the BigDecimal arithmetic operator overloading. The Swing simplification effort is long over due too.
Re: You Won't Believe This, But The Arrow Operator Is Coming To Java 7
Hmmm... That is interesting. I had not seen that before.
In groovy property access looks like this...
a.foo = b.fooThat may look like direct field access, but it isn't. It is property access, which is different. That is equivalent to doing this in Java...
a.setFoo(b.getFoo());Incidentally, in groovy the arrow operator is used to separate a list of parameters to a closure from the body of the closure like this...
myMap = [name:'Jeff', location:'St. Louis', company:'OCI']
myMap.each { key, value ->
println "${key} is ${value}"
}
Re: You Won't Believe This, But The Arrow Operator Is Coming To Java 7
The dot is a realy wrong idea - you wouldn't see, what is actually happening. For example you wouldn't notice, that an operation of assigment of two ints isn't atomic, or that a simple System.out.println(foo.bar()) can throw a crazy exception, because getBar() throws it.
Re: You Won't Believe This, But The Arrow Operator Is Coming To Java 7
x.putX(y.getY()) is as atomic as x.x = y.y. Or am I misunderstanding your point?
As far as exceptions are concerned: In JVM languages with checked exceptions (Groovy doesn't have checked exceptions) the compiler would insist you handled a thrown checked exception so you would have to be aware of it and you would see "what's actually happening"
Re: You Won't Believe This, But The Arrow Operator Is Coming To Java 7
Why get hung up over the arrow operator? That's just a minor detail. The good news is that native properties can take away huge gobs of boilerplate code that is hard to read and maintain. http://weblogs.java.net/blog/cayhorstmann/archive/2007/01/arrows_in_the_b.html