Java Reference
In-Depth Information
def "points should be set through ctor"() {
expect:
path.segments.collect { line -> line.start.x } == [0,3,0]
path.segments.collect { line -> line.start.y } == [0,0,4]
path.segments.collect { line -> line.end.x } == [3,0,0]
path.segments.collect { line -> line.end.y } == [0,4,0]
}
def "cant add new segments"() {
given:
ImmutablePoint a = new ImmutablePoint(x:5,y:5)
ImmutablePoint b = new ImmutablePoint(x:4,y:4)
when:
path.segments << new ImmutableLine(start:a,end:b)
then:
thrown UnsupportedOperationException
}
}
Everything I've shown about the @ Immutable annotation so far falls in the category of
the good news. Now for the bad news, though again it's not all that bad. First, the @ Im-
mutable annotation, like many of the AST transformations, wreaks havoc on Integrated
Development Environments (IDEs). The transformations occur at compile time, which the
IDEs have a hard time anticipating. Even though everything I've done so far is legal and
works just fine, my IDE [ 9 ] continually struggled with it. At this point the IDE issues are
mostly annoying, but fixing them is legitimately a Hard Problem and probably won't go
away soon.
9 Most of the code in this chapter was written using Groovy / Grails Tool Suite (STS) version 3.2.
The next problem occurs when I try to use my ImmutablePoint in a Java program.
How am I supposed to assign the x and y values? Groovy gives me a map-based construct-
or that I've been using so far, but Java won't see that.
Fortunately, the developers of @ Immutable anticipated that problem. The transforma-
tion also generates a tuple constructor that takes each of the properties in the order they're
defined. In this case, it's as though the ImmutablePoint class has a two-argument con-
structor that takes doubles representing x and y in that order.
 
Search WWH ::




Custom Search