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

Everything about Java 8

techempower.com

Post reply on HN
Print view View original

131–140 of 182 posts

Re: Everything about Java 8

#131

Post by zmmmmm »

These changes are the first since Java5 to make a real difference to how I will program, and thus are pretty nice to see.

The sad thing is that a large part of my Java programming will involve Android, and thus I will continue living in Java5/6 land, as will numerous libraries and large parts of the Java ecosystem.

I wonder when Google will address the future of Java on Android in a substantial way? Eventually it will not be tenable to stay on a 10 year old version of a language. I hope they will seriously consider either updating their supported syntax to be compatible with Java8 or introducing some other language into the Android SDK (Go go!).

Re: Everything about Java 8

#132

Post by ajanuary »

Hermel wrote: post #55
gjulianm wrote: post #13

As a C# developer now experimenting with Java, I still miss some things even from Java 8. Probably some have technical reasons behind, but... - Getters and setters, C# style. That is, instead of private int foo; public int getFoo() { return foo; } public void setFoo(int value) { foo = value; } write this: public int Foo { get; set; } which is both easier to write and makes code more readable and understandable. - Man…

I don't think there are technical reasons behind, but rather philosophical ones. - Getters and setters are bad design. In clean object-oriented code, the internal state of a class is not exposed to the outside. Thus, getters and setters should not be encouraged. - Exceptions: yes, it would be nice to be able to throw checked exceptions in that example. But the rule that they need to be declared is one of the basic de…

     In clean object-oriented code, the internal state of a class is not exposed to the outside.
One could argue clean OO code also follows the uniform access principle. I guess everything being a method is uniform. In which case why are public fields allowed?

The verboseness of writing getters and setters doesn't realistically stop people from writing them. It doesn't educate them as to why writing lots of them might be a bad idea. It doesn't suggest a better design. It just makes code harder to read and people put up with it, occasionally grumbling to themselves.

It's this kind of philosophy that's prevented java from having a terse lambda syntax for so many years, which in turn has left it out in the cold as API tastes have changed.

Re: Everything about Java 8

#133

Post by MichaelGG »

lucastheisen wrote: post #116
MichaelGG wrote: post #66

Earlier quoted context omitted.

TryParse returns a boolean. So you use it like this: int res; if int.TryParse(s, out res) { // OK } { else // not ok } You certainly do not need an exception to deal with the simple case of "did this string parse into an int". Edit: A great alternative signature is to use Maybe/Option, so you get Some int or None. match int.TryParse s with | None -> ... | Some i -> ...

is that really more work than: int res; try { res = Integer.parseInt( s ); } // if part catch ( NumberFormatException nfe ) { } // else part The words are different (try/catch instead of if/else), but still 2 blocks of code with similar syntax...

The main reason for TryParse, AFAIK, is avoiding the massive expense of exceptions on the CLR.

Another reason is composability. If you're checking several values together, returning a Maybe/Option is much more clear and usable.

Re: Everything about Java 8

#134

Post by ajanuary »

mbell wrote: post #121
actf wrote: post #118

Earlier quoted context omitted.

I really disagree that C# getters and setters are less readable than a public field. Compare: public string Field { get; set;} to public string field; I felt I had to reply to this comment to discourage this practice for a couple of reasons: 1) By convention anyone reading your code will think this is very strange, and it will force them to spend additional time reading your code to understand why you are breaking su…

1 + 2 are exactly why I do it. If your muddling around with the internal state of another object there should be alarm bells in your brain triggering you to think "should i really be doing this?"; It should look weird. Hiding fields behind method calls obscures what your really doing. I like that syntax highlighting changing the color on field access and that there aren't parenthesis at the end of the call. This is w…

Things consuming an object shouldn't care how it does what it asks, only that the object does it.

If knowing that something is a field rather than an opaque getter is important to the consumer, then the consumer knows too much.

You know you're messing with the state of an object when you do object.Something. That it's being messed with by a method call or a field is immaterial.

The syntax for consuming a field or a property are exactly the same. I don't see how fields ring alarm bells while properties don't.

Re: Everything about Java 8

#135

Post by ShabbyDoo »

bhauer wrote: post #3

I'm excited by Java 8 moreso than at least several of the previous versions. Java 7 was especially underwhelming. The lambdas are the new hotness that everyone is aware of. But the work done on streams is almost equally impressive. There are several other small additions and reductions in pain that, when taken as a whole, make this update significant. For example, we finally will have a native JodaTime-like replaceme…

A year or so ago, I wrote what was effectively a small subset of the JDK8 streams stuff. Incredibly useful, but hard to get right. It's good the core APIs will be part of the JDK so that, like the collections API, they may be adopted with some trust that others will do the same.

Re: Everything about Java 8

#136

Post by ShabbyDoo »

martinced wrote: post #123

"Interfaces can now define static methods. " Twenty years for that one ; ) zomg. Another one debated at length through flamewars on Usenet and ##java. And now it's here. Feeling good : )

The number of times I've implemented something by convention due to the lack of this construct... One common use case is that I like "value objects" -- an AccountId class vs. just a String or an Integer. I usually implement them using some sort of internment internally -- WeakHashmap, Guava Interner, etc. When reading from a wire format and using value objects, one must presume the existence of a fromString(String key), fromInt, etc. method. I'd love to state explicitly that all ValueObjects have particular, generic-ified static constructors. Much cleaner. And, it avoids the cliche Java programmer shame of implementing AbstractValueObjectFactory, etc. Some static state, if isolated and properly managed, makes life easier.

Re: Everything about Java 8

#137

Post by foohbarbaz »

gjulianm wrote: post #13

As a C# developer now experimenting with Java, I still miss some things even from Java 8. Probably some have technical reasons behind, but... - Getters and setters, C# style. That is, instead of private int foo; public int getFoo() { return foo; } public void setFoo(int value) { foo = value; } write this: public int Foo { get; set; } which is both easier to write and makes code more readable and understandable. - Man…

I like my checked exceptions. I like knowing what might go wrong with a call and I like being forced by compiler to handle it.

True that in typical chaos that reigns in code written by a disjointed group of people it ends up being Exceptions and RuntimeExceptions all over the place anyway. But why should disciplined people suffer?

Please leave my checked exceptions alone. I like then very much. I have not dealt with C#, but did with C++ and I prefer the Java way.

The arguments against checked exceptions that I have seen go along the lines of leaking data types from unrelated code layers. That's probably valid, but I have not experienced it. The rest seems like just whining about being forced to write code to handle errors, instead of letting things just happen.

Re: Everything about Java 8

#138

Post by foohbarbaz »

nollidge wrote: post #53
gjulianm wrote: post #13

As a C# developer now experimenting with Java, I still miss some things even from Java 8. Probably some have technical reasons behind, but... - Getters and setters, C# style. That is, instead of private int foo; public int getFoo() { return foo; } public void setFoo(int value) { foo = value; } write this: public int Foo { get; set; } which is both easier to write and makes code more readable and understandable. - Man…

And the two things I notice Java has that C# does not (static methods on Interfaces, and functional interfaces) have completely viable alternatives in C# (extension methods, and Action/Func, respectively). This really smacks of catch-up.

Speaking of C#, it's missing one critical for me feature: it does not run on the platforms I am (or my employer is) using. There are some attempts like Mono, but in practical sense it does not. That is sort of a no go right there.

Re: Everything about Java 8

#139

Post by foohbarbaz »

I am not sure I am super excited about Java the language increasing in size. As in, the size of the body of knowledge that need to be committed to one's head to comprehend and write the code.

I am actually quite opposed to the syntax sugar features like "getters/setters from C#", "events" and what not. Java the language is already large enough. IDEs do a decent job dealing with boilerplate code. Please, no new kludgy additions to the language.

Those people that need functional features could use Scala now. Jython is there for those not liking static typing.

Why don't we just leave Java alone?

Re: Everything about Java 8

#140

Post by rdtsc »

rallison wrote: post #26
gjulianm wrote: post #13

As a C# developer now experimenting with Java, I still miss some things even from Java 8. Probably some have technical reasons behind, but... - Getters and setters, C# style. That is, instead of private int foo; public int getFoo() { return foo; } public void setFoo(int value) { foo = value; } write this: public int Foo { get; set; } which is both easier to write and makes code more readable and understandable. - Man…

The boilerplate getters and setters in java do get old very quickly, and C#'s properties handle this nicely. On the surface, it seems like something minor and superficial, but when you are seeing the unnecessary verbosity of getters and setters day in and day out, it becomes frustrating not to have something like C#'s properties. I definitely would like to see a similar feature in java. In the meantime, I am pleased…

that is why I think java IDEs became so popular, they are almost a part of the language because they do some of this lower level refactoring for you
Post reply on HN