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

141–150 of 182 posts

Re: Everything about Java 8

#141

Post by dougk16 »

johnyzee wrote: post #120
smrtinsert wrote: post #89

Earlier quoted context omitted.

Just that an entire revolution is happening in the browser itself, I'd really like to be able to code Java directly with something GWT. I read recently that GWT has support for the latest html5 stuff, but complaints about compile time and lack of performance after compilation turn me off...

You should give GWT a go. Compile time is a valid complaint, though it can be mitigated by only producing a single permutation (browser specific output) while in development, rather than the default five-six. Also note that during development you usually don't compile but run in "dev mode", a browser plugin that runs against your actual Java code. Performance after compilation is certainly not a problem, on the contr…

Another valid complaint is that dev mode runs quite slow, particularly if you're developing something like a game. I read an article about how they are addressing this so that dev mode runs almost as fast as the compiled result, but can't find the link now. Maybe it's already live? Been half a year since I've used GWT.

But I second the recommendation overall. One thing I learned the hard way though, is that their widget library is pretty constraining, and a very leaky abstraction. I would consistently run up against walls using a particular widget, bang my head against it for a day or two, then scrap everything and roll my own solution. Eventually, I just used GWT to compile the core business logic of my app (which would have been a nightmare to do in JS), and did UI with the standard HTML/CSS/JS flow. Doing UI in Java is too clunky for me no matter what library I'm using though, so YMMV.

Re: Everything about Java 8

#142

Post by PySlice »

zmmmmm wrote: post #130
Hermel wrote: post #65

Earlier quoted context omitted.

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.

I wonder what those dogmatic programmers do when they are confronted with a problem in the real world where they need to find a balance between "encapsulation" and "single responsibility".

I guess their brains simply deadlock.

Re: Everything about Java 8

#143

Post by PySlice »

foohbarbaz wrote: post #137
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…

To me, checked exceptions seem to be a second return value: you need to catch it or declare that you are going to pass it to the caller. In this sense, it is enforced by the compiler even more rigidly than the return values themselves. They can be useful.

OTOH, sometimes we need a "panic"(¹) function, and a main loop that catches everything and either communicates the error to the user, or restarts the whole thing. That's why unchecked exceptions can be useful too, especially since they makes it harder to ignore errors - who has the patience required to check every return value of printf in C?

(¹) No, I've never programmed in Go.

Re: Everything about Java 8

#144

Post by quatrevingts »

mark_l_watson wrote: post #52

Unless I am mistaking, Java 8 fails to address the major pain-point I have with Java: hash and array literals. For me, one of the big wins of both Clojure and Scala is being able to handle maps, sequences, etc. conveniently.

Really? new double[] { 1.0, 2.0 }? Arrays.asList("foo", "bar")? Guava's Map builders?

Lambdas are what make operations on data structures convenient in Scala and Clojure, not saving a few characters on the handful of literals in your code.

Re: Everything about Java 8

#146

Post by quatrevingts »

IanDrake wrote: post #102

>Non-final variable capture - If a variable is assigned a new value, it can't be used within a lambda. This code does not compile: So, it sounds like that mean no closures? That's one of my favorite tools in c#.

Everyone gets confused by this it seems. You can mutate fields in the enclosing class. You can read locals. If you really want to, you can box a local, and then mutate it inside the box. You can't mutate locals directly, because that would make lambdas significantly slower for very little benefit.

(You would not be able to do stack allocation of locals in frames that contain lambdas (unless you could prove that the lambda does not escape).)

Re: Everything about Java 8

#147

Post by quatrevingts »

thecombjelly wrote: post #74

The inclusion of lambdas is great, but not supporting full closures severely hampers their usefulness. Instead of using lambdas to use patterns like CPS (continuation passing style) or alternative object interfaces, lambdas just save you from typing extra characters. It is always fun to watch other languages continue to implement features that bring them closer to lisp. I wonder how much longer it will be until every…

I'm not sure what you're getting at with CPS. How do Java's lambda's inhibit CPS? And what do you hope to accomplish with CPS, anyway? I could see you wanting tail-call optimization in order to make CPS useful, but that's a VM limitation, not a language limitation, and you could always trampoline anyway..

Re: Everything about Java 8

#148

Post by PySlice »

masklinn wrote: post #39
smackfu wrote: post #32

Earlier quoted context omitted.

It just seems an odd hill to die on. Just a minor little feature that most people would use only occasionally in their objects.

> Just a minor little feature that most people would use only occasionally in their objects. Yeah until you have to work with java's Bignums one day, then you start wanting to choke people to death.

Yeah, I guess it sucks if you work with Bignums. I would be happy if BigInteger and BigDecimal were promoted String-level language support: still implemented as classes, but with compiler support. They could add indexing [] for collections, but I can live with .get() and .put().

Some people seem to think that if they don't use, then it doesn't matter. In many business applications, you don't even need floating point (you just transfer data to the database and back), anyway.

Are floats and doubles "little features"?

In computer graphics, you need lots of floating point calculations. Are ints and longs "little features"?

In embedded software, you usually don't want to use resizable strings (C doesn't even have this feature built-in), because reallocations are expensive or unavailable. Are resizable strings (or containers) "little features"?

Different programs have different needs. If you haven't stumbled upon a good use case, doesn't mean that it's useless.

Re: Everything about Java 8

#149

Post by PySlice »

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…

Me too. However, I don't think Java needs much to become an appealing language (for language-geeks).

It's already going to get lambdas. Add some shortcuts for getters and setters (Lombok-style, maybe) and collections literals, then you get surprisingly close to Groovy (and JPA @Entity classes will become 1/6 of their sizes). And just like Strings have special + and +=, Bignums could have some compiler help (as they already do in JSP EL).

It will still be behind C#, but not by much. At that point I could agree that Java and C# have different philosophies and Java will never get true operator overloading, but it doesn't matter much if the most important use cases are covered.

Re: Everything about Java 8

#150

Post by PySlice »

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…

> Thus, getters and setters should not be encouraged.

Damn, so why are they encouraged in Java? 11 out of 10 frameworks insist that you write getters/setters so properties can be accessed from outside.

Java designers need to get more practical. If getters/setters are unavoidable, I'd better have them without so much boilerplate in my code.

No need to go the C# way. Just enough to avoid repeating the name and type 3+ times each would be great.

Post reply on HN