Live data from Hacker News

Java 9 features announced

jaxenter.com

171–180 of 228 posts

Re: Java 9 features announced

#171
post #11

Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.

that's not really because of the language, but mostly because of frameworks and patterns available for the language (Java Beans, reflection-oriented frameworks and so on). Often, getters and setters are more an habit than a need. A while ago I wrote against that: http://www.refactoringideas.com/getters-and-setters-gone-wro...

Re: Java 9 features announced

#172
post #11

Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.

You can always do something like this http://benjiweber.co.uk/blog/2014/03/20/c-style-properties-i...

Although I prefer not using getters & setters at all.

Re: Java 9 features announced

#173
post #11

Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.

If there's a getter and a setter for a class field, you can just make it public.

Re: Java 9 features announced

#174
post #11

Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.

If there's a getter and a setter for a class field, you can just make it public.

whomp whomp. not really.

Re: Java 9 features announced

#175
post #11

Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.

You can always add Project Lombok as a dependency and the issue is gone. I know it is a third-party library but there's nothing bad about that.

Re: Java 9 features announced

#177
post #101
post #11

Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.

Not exactly comparable (because everything is immutable), but Haskell has sort of a cool approach to setting and getting fields. Let's say you have data Point = Point {x :: Int, y :: Int} If you have a Point object called "point", you can get x by doing x_coord = x point If you want to create a new Point with x set to 5, you can do point' = point {x = 5}

F# has a similar concept via the with statement. To use your example:

    type point = { x: int; y:int}
    let z = {x = 5; y = 10} 
    let y = {z with x = 17}

Re: Java 9 features announced

#178

Earlier quoted context omitted.

Awesome! Thanks. I don't know much about the path from idea to standardized feature with the JVM. Is there hope for it in Java 9 or is this much farther out in the future? Probably first and more importantly, what is the chance for this even ever happening?

"the path from idea to standardized feature" Guy Steele was asking for value types in 1998 ( http://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf )

Yeah, but he was also asking for operator overloading.

Re: Java 9 features announced

#180

I had heard a rumor that there ware talks of user defined value types. Does anyone know if there is any hope for this?

What JVM instructions would you use to implement user-defined value types?

I'm not sure you'd need to introduce new instructions.

"user-defined value types", i.e. structs, can already be done today by (ab)using the Flyweight pattern and storing data (possibly off-heap with RAII rather than GC semantics) in some byte[].

All a JDK-supplied implementation would really need to do is (1) automate/hide all the painful work necessary to set this up and (2) provide syntactic sugar in the form of operators that can directly manipulate members of these types (+fast implicitly inlined implementations of them, specialized on the member types).

Post reply on HN