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

111–120 of 228 posts

Re: Java 9 features announced

#111

Post by sdegutis »

ryanobjc wrote: post #97
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 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…

This reminds me of two tweets from Nat Pryce[1][2]:

> Colleagues & I once doubled system's functionality & replaced 750K lines of Java with 50K lines of ... Can you guess the language.

> Of course it was Java!

[1] https://twitter.com/natpryce/status/409034320108867584

[2] https://twitter.com/natpryce/status/409232836945010688

Re: Java 9 features announced

#112

Post by mythz »

tieTYT wrote: post #105
mythz wrote: post #82

Earlier quoted context omitted.

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 th…

Binary compatibility is important when accessing properties of a type defined in another Assembly, i.e. if an Assembly was updated where a Field was changed to a Property it would break access from dependent Assemblies.

In .NET Reflection, Fields and Properties have distinct API's, i.e. fields can be accessed with `type.GetFields()` and properties with `type.GetProperties()`. The API's are basically wrappers around how they work, i.e. Fields let you get/set an instance's field value whereas with Properties you're instead invoking the properties getter/setter method accessors.

Re: Java 9 features announced

#113

Post by stevebot »

Sooo this means it will be what 5 years if never before Android starts to adopt some of these new Java 9 features? Kitkat introduced some Java 7 features, but I don't think anything in 8 is near to making it in.

Re: Java 9 features announced

#114

Post by MrBuddyCasino »

ryanobjc wrote: post #97
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 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…

This only works well if we get named parameters, too (and maybe defaults). It is too easy to make mistakes with lots of subsequent constructor arguments of the same type.

Re: Java 9 features announced

#115

Post by tieTYT »

einrealist wrote: post #84
haddr wrote: post #5

I'm deeply missing hot swapping. I believed it could be included in java 9 but i think we have to wait...

What is wrong with restarting your application? Edit: Real Hotswapping will requires profound changes to the memory model. It would introduce too much complexity. I rather restart my application than to suffer from a fragile and leaking platform.

It can take up to 5 minutes to restart my application.

Re: Java 9 features announced

#116

Post by Alupis »

ryanobjc wrote: post #97
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 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…

Anyone know what the "sjavac" is about? The link just talks about improving it so it can become the new default... but what is better about it? Is it just the new javac?(why not just in-place upgrade javac then?)

(link provides no real details: http://openjdk.java.net/jeps/199)

Re: Java 9 features announced

#117

Post by ppog »

mythz wrote: post #82
memonkey wrote: post #37

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…

Your comment about changing a field to a property being a breaking change in C# is correct, but in practice, C# programmers tend to use auto properties (e.g. public int Left { get; private set; }) rather than public fields. These are fully fledged properties, but the getters and setters are implemented by the compiler (and back directly onto a compiler-generated field). Because they are properties, they can then be changed to computed properties (or e.g. validation added to setters) without breaking binary or reflection compatibility.

Re: Java 9 features announced

#118

Post by dragonwriter »

tieTYT wrote: post #105
mythz wrote: post #82

Earlier quoted context omitted.

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 th…

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

That's the point, but its not directed at reflection, and reflection goes around behind the scenes of the superficial access-notation compatibility. Which does make properties a badly leaky abstraction, which is problematic since their main reason for existing is to plug a leak in the abstraction provided by the method/field distinction.

Re: Java 9 features announced

#120

Post by curiousCoffee »

pjmlp wrote: post #69
exabrial wrote: post #33

Earlier quoted context omitted.

There's always JRebel!

Not really. http://zeroturnaround.com/blog/goodbye-liverebel/

Oh, damn! I just started using jrebel.. (I know I asked what hotswapping was but I was curious if the OP meant hotswapping in the same way as jrebel or something else)

edit: Wait, that is liverebel, not jrebel

Post reply on HN