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

New Features in Java 14

blogs.oracle.com

Post reply on HN
Print view View original

61–70 of 188 posts

Re: New Features in Java 14

#61

Post by int_19h »

reificator wrote: post #60
imtringued wrote: post #47

Earlier quoted context omitted.

> No that's not the key difference, because you can just call `unwrap()` and forget about it, which is effectively the same footgun as other languages. Are you sure? Each line of Java or Javascript can be equivalent to multiple `unwrap()` calls. You can't see them because the compiler is generating ([0]) them but they are there and there are many hundreds of thousands (or maybe even millions including dependencies) o…

Please do not quote posts out of context in order to make your argument seem stronger. > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith. I am well aware of the issues in other popular languages. You and I agree that there is an implicit `unwrap()` call in each dereference operation. The post I was responding to claimed that…

When you write unwrap(), you're handling them - by forcing a panic, but it's still a choice that you make.

Re: New Features in Java 14

#62

Post by nitrogen »

lmm wrote: post #55
tadfisher wrote: post #39

Earlier quoted context omitted.

Java lacks default arguments for functions, which makes that particular API infeasible without adding support for such. They could generate "withFoo" methods or even builder types, but that would butt up against developer preference, so it's probably best to leave it up to developers or a third-party library. Kotlin has a very similar feature in its data classes, FWIW.

Does Kotlin have anything to let you treat data classes in a generic way like you can do with Shapeless in Scala? That's where the real power comes IME - e.g. look at Circe where you can derive JSON encoders/decoders for arbitrarily nested case classes at compile time, so you have zero boilerplate but still get compile-time type safety that stops you from accidentally trying to serialise a file handle or semaphore.

There is the currently experimental kotlinx.serialization library that generates e.g. JSON codecs at compile time. Not sure if that fits the bill.

Re: New Features in Java 14

#63

Post by diegof79 »

nine_k wrote: post #56
skissane wrote: post #42

Earlier quoted context omitted.

> Java lacks default arguments for functions, which makes that particular API infeasible without adding support for such I really wish Java would add both default arguments for functions, and also support for passing function arguments by name. One of these days...

This goes against the very idea of method signatures in Java an overloads based on them. An attempt to add it will likely bring in way, way more backwards-compatibility pain than any benefits are worth. Writing simple methods with few arguments helps.

You can have named parameters and backward compatibility with method signatures, Groovy does that [1].

Ok, it cheats a little bit because named params are actually a syntax sugar for Maps. But other languages do the same (e.g. Python) and is very useful too. And if you can type check the map (as in Typescript) the functionality is equivalent to named params.

[1] http://docs.groovy-lang.org/latest/html/documentation/#_name...

Re: New Features in Java 14

#64

Post by Vax45 »

nine_k wrote: post #57
lmm wrote: post #54

Earlier quoted context omitted.

You can use named parameters if you're worried: val emily1 = Person(firstName="Emily", lastName="Maness", age=25) Scala's approach to constructors is a good example of convention over configuration; in Java 99.9% of classes have a constructor like: this.firstName = firstName; this.lastName = lastName; this.age = age; which is just ceremonial boilerplate that obscures the actual logic of what the class is doing (an ID…

Lombok solves this for Java.

I would try out Immutables before Lombok. It generates code using the standard annotation processor instead of modifying OpenJDK's AST tree.

Re: New Features in Java 14

#65

Post by vips7L »

riyadparvez wrote: post #49
dionian wrote: post #23

Earlier quoted context omitted.

it's always moved slow on purpose... one of the language's greatest features is backwards compatibility and stability it's purposefully dead simple. this is why many of us switched to alternative JVM langs ... Java can't keep up with the innovation other Langs have without breaking its philosophy of slowmoving/backwards compat

Not all features have to do anything with backward compatibilities. I agree with the fact that features should be added with caution cause new features can interact with existing features in a non-trivial way that will introduce lot of edge cases. But it's hard to see why a feature like text block would introduce more complexities.

Because once a feature is introduced it needs to be supported for eternity, every feature has to do with backwards compat. The language designers need to make sure the features are exactly what we want and need before introducing something half baked.

Re: New Features in Java 14

#66

Post by devonkim »

dionian wrote: post #23
redact207 wrote: post #18

"switch expressions", "text blocks". I haven't used Java for 15 years but it's one of the most mature languages out there. I'm surprised it's only just getting these pretty standard features now.

it's always moved slow on purpose... one of the language's greatest features is backwards compatibility and stability it's purposefully dead simple. this is why many of us switched to alternative JVM langs ... Java can't keep up with the innovation other Langs have without breaking its philosophy of slowmoving/backwards compat

At one point “simple” was not really a fair assessment of Java, especially if you had to do multithreaded / concurrent code back when we had broken primitives in the Java 3-5 days.

It’s moving along a lot faster now thankfully but if it was going this fast 20 years ago we may not have needed Kotlin or Groovy

Re: New Features in Java 14

#67

Post by hcarvalhoalves »

Sharlin wrote: post #15
rakoo wrote: post #9

Earlier quoted context omitted.

> Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem. I'm in no way a Rust expert, but I see a lot of code with Optionals, something like match sth { Some(v) => do_something None => nothing_to_do } This looks awfully a lot like if (something == null) { nothing_to_do } else { do_something } It might look more pleasant, but it doesn't "solve" anything, only shifts it in a d…

In Java you're passed a reference to an object. Might it be null? Can it be null? Who knows! Mostly you're just going to ignore the possibility and hope for the best. In Rust you're passed a reference to an object. Can it be null? No, it simply can't! There does not exist a magic "null" value for references. To represent the possible absence of a value, you explicitly encode it into the type system by using `Option `…

Just changed from having a bottom null type for all types to everything being a boxed Option type. It’s equivalent.

The actual difference is the reliance on pattern matching and the compiler enforcing coverage on those languages.

Re: New Features in Java 14

#68

Post by on_and_off »

mateuszf wrote: post #38

I wonder about records - they would be great for simplified implementation of immutability, but they seem to not provide a way to copy with a subset of modified fields - like in Scala: case class Person ( firstName: String, lastName: String, age: Int ) you could create an instance like this: val emily1 = Person("Emily", "Maness", 25) and then create a new instance by updating several parameters at once, like this: //…

kotlin has this too .. but java does not have named params. It would be a good addition imo (think Rect(left, top, ....) , especially associated with default params.

Alternatively, they could automatically generate a builder class for records.

As always in java, I guess that somebody will duct tape an annotation based solution on top of the language to solve this.

Re: New Features in Java 14

#69

Post by cxr »

Spinfusor wrote: post #28
aw1621107 wrote: post #25

Earlier quoted context omitted.

> The new license makes it almost impossible to use Java without some form of payment to Oracle. Do you have a source for this claim? It sounds a bit extreme, to say the least, and I had the impression OpenJDK was licensed using fairly standard terms.

It's mostly FUD: it's only relevant for the Oracle JDK; it doesn't apply to OpenJDK (or the other open distributions by other orgs).

It doesn't help that multiple Oracle/Sun folks—including people like McNealy—said under oath that they don't believe that the licensing permits you to make commercial use, even if you opt for the GPL version.

Re: New Features in Java 14

#70

Post by winrid »

smt88 wrote: post #37
Yhippa wrote: post #33

I've been doing mostly Java work in my career and I'm using more JS these days on the side. I'm envious of the rest, spread, and deconstruction functionality in ES6. Really, really, envious.

What would stop you from switching to Kotlin, which has those features and many more?

I was in a Java shop at one point where leadership said Kotlin would be too hard for the engineers to learn (they were all mostly fairly junior).
Post reply on HN