Live data from Hacker News

Java 9 features announced

jaxenter.com

101–110 of 228 posts

Re: Java 9 features announced

#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}

Re: Java 9 features announced

#102
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.

It is addressed by better design. First off, it's important to know the difference between value types and objects. For a value type, public final fields are good. They are set in the constructor once, and can only be read, and can't change. Getters are pointless, and my code does not have them. If you want them for a reason, then intellij does an amazing job fixing that. Objects encapsulate mutable state, and getFoo…

> It is addressed by better design.

This! A lot of the horrible Java you see around is nothing but an artifact of mindlessly applying patterns to constructs that don't need them.

> a lot of java was created when we still hadn't figured out how to properly do Object Oriented Programming.

Which is quite unforgivable, considering Smalltalk has been around since the early 80's.

Re: Java 9 features announced

#104
post #82

Earlier quoted context omitted.

Sorry to ask, but as a noob who just picked up Java, how do other languages address this issue? What's wrong with getters and setters?

IMO Dart has the best implementation of properties, which you can start out as normal fields, e.g: class Rectangle { num left, top, width, height, right bottom; } and can access like normal: var height = rect.bottom - rect.top; But can later be changed into a computed property without affecting the above callsites, e.g: class Rectangle { num left, top, width, height; num get right => left + width; set right(num value…

Ruby is quite similar.

attr_accessor :left, :top, :width, :height, :right, :bottom

And you can change these to computed properties (regular methods) later without affecting the callsites

Re: Java 9 features announced

#105
post #82

Earlier quoted context omitted.

Sorry to ask, but as a noob who just picked up Java, how do other languages address this issue? What's wrong with getters and setters?

IMO Dart has the best implementation of properties, which you can start out as normal fields, e.g: class Rectangle { num left, top, width, height, right bottom; } and can access like normal: var height = rect.bottom - rect.top; But can later be changed into a computed property without affecting the above callsites, e.g: class Rectangle { num left, top, width, height; num get right => left + width; set right(num value…

Why does it matter if it's binary compatible? How does that affect the programmer? I guess I don't understand the difference/significance between binary and source compatibility?

I'm surprised to hear that it's not reflection compatible. As a Java programmer, I assumed that was the main point of C# properties: Create a property now because there's no logic needed, but if you need logic in the future you can change the code and nobody outside needs to be aware of the change.

Re: Java 9 features announced

#106
post #41

Earlier quoted context omitted.

For c# just: public int Age{get;set;} no need to declare private variable, get or set methods.

And you can replace it with a virtual property in the future (changing the underlying implementation) without breaking anything. And user code ends up simpler and more readable too: foo.baz += foo.bar; vs. foo.setBaz( foo.getBaz() + foo.getBar() );

That example reminds me of this recent post on The Old New Thing: http://blogs.msdn.com/b/oldnewthing/archive/2014/08/14/10549...

Interesting behavior.

Re: Java 9 features announced

#107
post #75

Earlier quoted context omitted.

If you want to rid yourself of GC problems, go buy Azul's Zing JVM. It works like magic. (disclosure: I'm a very happy customer of theirs)

Zing does not do you any good if you are selling software. Your income is reduced by the license cost of Zing in addition to the additional sales and deployment friction. The reality is that you have to build software that works on the Oracle JVM.

ah, understood. have you been tracking shenandoah? http://openjdk.java.net/jeps/189

Re: Java 9 features announced

#108
post #67

Earlier quoted context omitted.

Sorry to ask, but as a noob who just picked up Java, how do other languages address this issue? What's wrong with getters and setters?

In python the default is that things that look like attributes/properties REALLY are direct access. If you later need to shim them out into a function you use the @property decorator (and foo.setter if you need read/write) class Blah(object): foo = 2 # A normal property. Direct access @property def bar(self): return self.some_lookup_method() @bar.setter def bar(self, value): self.set_the_bar(value)

Thanks for mentioning this. I've found the Python approach works really well in practice.

Re: Java 9 features announced

#109
post #107

Earlier quoted context omitted.

Zing does not do you any good if you are selling software. Your income is reduced by the license cost of Zing in addition to the additional sales and deployment friction. The reality is that you have to build software that works on the Oracle JVM.

ah, understood. have you been tracking shenandoah? http://openjdk.java.net/jeps/189

I have heard of it but haven't read up. I think it's great that someone is stepping up to address the issue. Interesting that both the authors listed in the JEP work for Red Hat.

Re: Java 9 features announced

#110
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.

It is addressed by better design. First off, it's important to know the difference between value types and objects. For a value type, public final fields are good. They are set in the constructor once, and can only be read, and can't change. Getters are pointless, and my code does not have them. If you want them for a reason, then intellij does an amazing job fixing that. Objects encapsulate mutable state, and getFoo…

I agree and I hate getters, but I am one of those who still hasn't figure out how to do OOP correctly. Do you have an example or maybe some suggested reading? For example, if I have a user object, with name, age, number, how would that work without get/set? I'd love to avoid it, I hate the bloat it creates, and also how frivolous it seems to test get/set.
Post reply on HN