Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 9 features announced

jaxenter.com

Post reply on HN
Print view View original

71–80 of 228 posts

Re: Java 9 features announced

#71

Post by [deleted] »

aikah wrote: post #57
zo1 wrote: post #51

Earlier quoted context omitted.

And making your instance variables public doesn't solve that for you?

States(properties) should never be public or it breaks encapsulation.That's why a language that allows a property to be a method under the hood is usefull, because the state is still encapsulated. State changes can have desirable side effects.If you expose an instance variable directly it's harder to encapsulate that. Of course there are exceptions. If you have a class that is meant to be only a parameter bag(in an r…

[deleted]

Re: Java 9 features announced

#73

Post by bollockitis »

rufugee wrote: 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 isn't perfect, but Lombok[1] helps with this. It uses annotations to automatically generate getters and setters. The downside, of course, it yet another dependency and more annotations.

[1]: http://projectlombok.org/features/GetterSetter.html

Re: Java 9 features announced

#74

Post by noblethrasher »

rufugee wrote: 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.

I admire Java for the fact that it is significantly more painful to write mutable rather than immutable classes.

I love C#, but I do wish that setters weren't so easy to define (and that classes were sealed by default, and that fields were read-only, and that all extant warnings would become errors, etc.).

Re: Java 9 features announced

#75

Post by osi »

arielweisberg wrote: post #48

Still no solution for the GC fragmentation and pauses? Arbitrarily large heaps and data structures? They are going to improve lock performance, but do nothing to help people avoid locking like lightweight threads. Not waking up a thread and not locking is faster... It's weird how so many software projects completely lose sight of the fundamentals. I know I am biased due to how I use Java. I care very little for synta…

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)

Re: Java 9 features announced

#76

Post by mdaniel »

mmastrac wrote: post #2

The lack of an official JSON API has been a huge sore point for quite some time and has spawned dozens of libraries re-implementing the same thing over and over (GSON, Jackson, and even my own nanojson). I do hope that we avoid the DocumentBuilderFactory mistakes of XML and just end up with One True JSON implementation this time.

There is an official JSON API: https://jcp.org/en/jsr/detail?id=353

But it is unclear how many of the existing implementations conform to it, and it definitely doesn't work toward your misguided One True JSON Implementation goal.

Re: Java 9 features announced

#77

Post by [deleted] »

[deleted] wrote: post #71
aikah wrote: post #57

Earlier quoted context omitted.

States(properties) should never be public or it breaks encapsulation.That's why a language that allows a property to be a method under the hood is usefull, because the state is still encapsulated. State changes can have desirable side effects.If you expose an instance variable directly it's harder to encapsulate that. Of course there are exceptions. If you have a class that is meant to be only a parameter bag(in an r…

[deleted]

[deleted]

Re: Java 9 features announced

#78

Post by sanderjd »

necubi wrote: post #35
exabrial wrote: post #30

Earlier quoted context omitted.

The other "Missing feature" is null safe ".". Other languages have it, but I don't know what the technical name is... basically: Integer val = some.other.chain.of.objects.value; In Java, this code has a huge potential for NullPointerExceptions. Instead a new operator (yes, I know) like: Integer val = some.?other.?chain.?of.?objects.?value; If any of the intermediate objects are null, the whole assignment becomes null…

This is solved in a more general way in Java 8 via monadic optionals. The basic idea is to wrap your nullable objects in an Optional , which then both forces you to deal with the possibility of the value being absent and gives you good tools for doing so. Your example, with Optional, looks like this: T obj = ...; Optional.of(obj).map(T::some).map(U::other).map(V::methods).getOrElse(null); Not quite as clean syntactic…

The sugar your parent proposed would still be nice and has precedent in other languages with option types. Swift has something very similar[0], and Rust is debating it[1]. Haskell's do-notation and Scala's for-comprehension are other solutions to the same general problem of conveniently using option types.

It may be a good thing to only support that sort of convenience for option types and not for nulls, in order to further encourage their use. Although using nullable types is already pretty darn convenient!

[0]: https://developer.apple.com/library/prerelease/ios/documenta... [1]: https://github.com/rust-lang/rfcs/pull/204

Re: Java 9 features announced

#79

Post by zo1 »

[deleted] wrote: post #71
aikah wrote: post #57

Earlier quoted context omitted.

States(properties) should never be public or it breaks encapsulation.That's why a language that allows a property to be a method under the hood is usefull, because the state is still encapsulated. State changes can have desirable side effects.If you expose an instance variable directly it's harder to encapsulate that. Of course there are exceptions. If you have a class that is meant to be only a parameter bag(in an r…

[deleted]

Your public facing methods/accessors are a sort of contract between a class, and whatever uses it.

The contract basically says: "I will behave as you expect me to and as we agreed but only as long as you only interact with me in the predetermined(designed) ways that I allow you to"

Re: Java 9 features announced

#80

Post by AnimalMuppet »

[deleted] wrote: post #71
aikah wrote: post #57

Earlier quoted context omitted.

States(properties) should never be public or it breaks encapsulation.That's why a language that allows a property to be a method under the hood is usefull, because the state is still encapsulated. State changes can have desirable side effects.If you expose an instance variable directly it's harder to encapsulate that. Of course there are exceptions. If you have a class that is meant to be only a parameter bag(in an r…

[deleted]

Here's a class C with a variable v of type T. It's supposed to be something that the rest of the world can access. You can make it public. Or you can make it private, and write

public T get_v() { return v; }

So far, not much difference. Both let the world access the variable, and both break encapsulation by doing so.

The difference comes when the class gets more complicated, and v changes. Now v might be null, whereas it never could be null before. But if it is, then what the rest of the world saw as v should now be some default value. So we can say:

public T get_v() { if (v != null) return v; else return default_T; }

and life goes on for everybody that was using v. But if all we had was a variable that everybody accesses, then all the users have to change. They either have to access the new getter or, worse, they each have to copy the logic to check for null.

This is how the getter encapsulates the inner workings of the class, and why it's a really good thing.

P.S.: How do I specify code formatting on HN?

Post reply on HN