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

41–50 of 182 posts

Re: Everything about Java 8

#41

Post by pjmlp »

stelonix wrote: post #18
pcote wrote: post #11

Earlier quoted context omitted.

Why? Sure, overloading a "+" operator can be elegant looking. But the aesthetic gain vs. maintainability doesn't seem to be worth the tradeoff 99% of the time. I certainly wouldn't want to be the one who has to debug the thing because someone accidentally side effected one of the "operands".

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.

That is what I keep repeating when people complain about operator overloading.

It is just symbolic names, like doing abstract mathematics with letters instead of numbers.

Except for C, Java and Go, all the remaining mainstream languages allow for symbolic names in the functions/methods.

I never understood what was the big deal.

Re: Everything about Java 8

#42

Post by pjmlp »

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.

Google is yet to even add support for the Java 7 language constructs.

Re: Everything about Java 8

#44

Post by pjmlp »

stelonix wrote: post #29
mikeash wrote: post #23

Earlier quoted context omitted.

It seems to me that it's a cultural problem more than anything. People know that they shouldn't take an existing, well-known method name and repurpose it for something completely different. But somehow a lot of people think it's OK to repurpose an operator to mean something completely different just because it's convenient. C++ being the classic example. I think it depends a lot on the languages. Operator overloading…

"But somehow a lot of people think it's OK to repurpose an operator to mean something completely different just because it's convenient. C++ being the classic example." Do you have any data to prove such assertions? A C++ STL operator chosen more than a decade ago is not enough statistical data for one to have such a narrow-minded vision and say these bold statements. Maybe you need to check all the nice C++ librarie…

The common example people pull off the hat with C++ is the use of Which I personally never had a problem with.

Re: Everything about Java 8

#45

Post by trailfox »

j-m-o wrote: post #5

As a daytime Java developer who dabbles in Scala on the side, these changes look great. The inclusion of a Joda Time style time library is long overdue as well. I just wonder how many years before there's adoption from the general Java community.

As a daytime Scala developer who seldom uses Java anymore these changes are nice, but a far cry from what I get in Scala.

Re: Everything about Java 8

#46

Post by pjmlp »

swift wrote: post #21
stack0v3erfl0w wrote: post #9

I recently started developing in Java and the thing I find most irritating is the lack of operators overload.

In my opinion good uses of operator overloading are ones that preserve the mathematical properties of the operator, so that the operator is in some sense "the same operation", just for different types. By this standard "+" for string concatenation isn't a great choice since string concatenation isn't commutative, but addition is. The same can be said for using "*" for matrix multiplication. If you define these kinds…

Quite a few languages allow the use of operators, or special characters if you prefer, as names.

Without any restriction, except for a few basic ones.

Re: Everything about Java 8

#47

Post by twic »

microtonal wrote: post #36
davesims wrote: post #14

With the ability to add static methods and default implementations to an interface, what is now the practical difference between that and an abstract class?

- A class can only inherit from one abstract class, but can implement multiple interfaces. - An interface cannot have member variables.

Also, an abstract class can have a constructor (and instance initializers, and initialization expressions for its fields), which an interface can't. That means an abstract class can do work when it is created.

Although it's probably a good idea not to do too much work - a factory method would be better for that.

Re: Everything about Java 8

#48

Post by 727374 »

eranation wrote: post #27
spartango wrote: post #22

Woah, that streaming abstraction looks really slick, especially given that it can be automatically parallelized. The idea of doing a one-line parallel map-reduce that is collection.stream().parallel().map(operation1).reduce(operation2); is surprisingly cool imo. And the availability of streams across the collections framework allows that they can be used in routine programming.

Yep, Java 8 starts to look a lot like Scala

It looks like C# 3 (2007)

Re: Everything about Java 8

#49

Post by pifflesnort »

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 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-dependent failures to creep into the system.

The unexpectedly-unwound-stack problems that Java's compiler is highlighting are still there, just hidden.

Better, in my mind, to not use unchecked exceptions at all.

Re: Everything about Java 8

#50

Post by spullara »

aardvark179 wrote: post #33
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…

Give the desire for lambdas to enable more simple concurrent programming, and the added complexity mutating the external variables in the implementation, I think they made the right choice. If you _really_ have to mutate those variables then put them into a final array, and alter the entries in that, the same can be used if you need to do an effective pass by reference.

The Atomic* classes are also good choices.
Post reply on HN