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

121–130 of 182 posts

Re: Everything about Java 8

#121

Post by mbell »

actf wrote: post #118
mbell wrote: post #94

Earlier quoted context omitted.

> Getters and setters, C# style. That is, instead of I just stopped using getters and setters all together unless I have a real use for them. The most common reasons are: because they are required by some third party library or they are the external interface for whatever the module of code is doing. For all internal classes, if the field needs external access, just make it public. Most of the arguments I hear for us…

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 what I meant by readability, I instantly know that I'm muddling around with the inner state of another object. Figuring out whats really going on with getter and setters is made far worse by the common practice of 'overloading' getters and setters to accept / return different types than the internal state representation.

3 - I would consider defining field getters in an interface poor form. There is a reason interfaces (in Java at least) do not allow field definitions. Defining a 'getter' in an interface is just circumventing that protection and a strong indication the code should be refactored in a different way.

Re: Everything about Java 8

#122

Post by prodigal_erik »

smrtinsert wrote: post #85
stelonix wrote: post #18

Earlier quoted context omitted.

Nonsense. To paraphrase myself from a similar discussion on reddit: "List.add(otherList) Honestly, it's about time the Java crowd stops with the mantra and starts thinking from themselves. Or at least, learn why the reason you hate operator overloading is fallacious.

the nice part about java is the legibility. I can simply start with a new instance of your object and auto complete to the method that I want. Once operator overloading joins the fray everyone is off to the races for crappy dsl of the week. "here's how you do the XXX lib way". I'd prefer if that option stays off the table. Given that java users are on ides, autocompletion makes an api call a one character effort anyw…

Java users are stuck with IDEs largely because it's so hard to design a decent DSL when you're confined to Java method syntax. Autocomplete doesn't make it any easier to read bulky verbose code, just gives you more of it.

Re: Everything about Java 8

#123

Post by martinced »

"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 : )

Re: Everything about Java 8

#124

Post by tragomaskhalos »

mikeash wrote: post #112
tragomaskhalos wrote: post #104

Earlier quoted context omitted.

Examples ?

The use of > for streams is the one that always comes to mind. So minor, and yet so awful.

Well this is clearly a matter of taste; the visual implication of movement (http://images.google.com/images?q=diversion+sign+chevrons) is quite elegant IMHO, and the precedence seems natural also. But others' mileage obviously varies ...

Re: Everything about Java 8

#125

Post by iSnow »

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…

>- Getters and setters, C# style.

In Java, I use Lombok:

@Getter @Setter private Integer foobar;

>Checked exceptions

True, widely regarded as a mistake, but hard to get rid of now.

Re: Everything about Java 8

#126

Post by gizmo686 »

twic wrote: post #58
DoubleMalt wrote: post #43

Can someone please show the java guys the .TryParse(String s) from C#? I'm convinced everytime I have to manually write the try catch clause for parse a kitten dies somewhere!

As a Java programmer, i agree that the catch blocks around parsing are annoying, but i'm not sure a method that returns an error code is any better. Wasn't that tried back in the '80s? The way Scala (and probably other functional languages, with which i am not familiar) handle this is with a little bit of polymorphism. Using Java syntax, parsing a string into integer would return a Validation , an abstract type which…

Haskell works the same way.

Re: Everything about Java 8

#127

Post by georgemcbay »

RyanZAG wrote: post #40

Massive issue here for many when it comes to Java 8 - what about Android ? Android's dalvik is based off of Apache Harmony, which doesn't appear to be updating anymore. Does this mean no Java 8 for Android/Dalvik? Seems like it would be a major issue if so.

The lack of any public direction on this from Google to Android developers has been annoying me for a while now. It seems like Android has decided to be stuck on Java 6 forever.

I'd love to see them really shake things up in Android by, eg, going with NaCL/PNaCL (or even something like seccomp2, don't really care) to manage sandboxing and exposing an API framework (so apps can present common UI widgets) with a C API (regardless of what it is written in underneath) making it relatively easy to consume from any language. Write your Android app in Go, Python, Java, whatever you want, as long as it has API bindings! But I'm not holding my breath on that.

Re: Everything about Java 8

#128

Post by brown9-2 »

rictic wrote: post #67
pifflesnort wrote: post #49

Earlier quoted context omitted.

The checked exception concern leaves me scratching my head. Without checked exceptions, the forEach implementation has no way to gaurentee that the lamba won't throw, and has to be exception-safe at all times -- in the case of stateful code, this can generate a lot of boilerplate. Rather than write all that boilerplate, most people won't actually write exception-safe code across the board, which allows strange state-…

It's a pain that operations can fail, but handling state when they do fail is a problem that exists whether your exceptions are checked or unchecked. Forcing all exceptions to be checked doesn't seem to help with the problem, but would rather cause a lot of code to simply declare that it throws Exception, rather than listing off all possible exception types that it doesn't handle (e.g. out of memory, SIGTERM received…

Forcing all exceptions to be checked doesn't seem to help with the problem

I think this is a common misperception of Java - not all exceptions needed to be checked exceptions. The author makes a decision when defining the Exception class if it is going to be a checked exception or unchecked exception.

Re: Everything about Java 8

#129

Post by gjulianm »

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…

In C#, properties are handled just like fields:

    class Foo {
       public string Bar { get; set; }
    }

    Foo.Bar = "test";
But I still don't get why wouldn't you use getters/setters or properties. For example, let's say you want to get the number of items in a list. How'd you do it without something like this

    public int Count { get; private set; }

?

Re: Everything about Java 8

#130

Post by zmmmmm »

Hermel wrote: post #65
nollidge wrote: post #63

Earlier quoted context omitted.

> In clean object-oriented code, the internal state of a class is not exposed to the outside. So then you don't write getters and setters for that stuff in C#. I don't get your point here.

The point is that a language should not add features that make it easier to write bad code.

That's being way too dogmatic.

The problem with taking encapsulation to an extreme is that you are trading off against flexibility. The more you hide your state the less any external party can implement their own logic using that state, and the more separate concerns have to be bundled into the class hiding the state because they can't be dealt with anywhere else. Everything in software design is a tradeoff.

Post reply on HN