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

121–130 of 188 posts

Re: New Features in Java 14

#121

Post by vbezhenar »

vips7L wrote: post #65
riyadparvez wrote: post #49

Earlier quoted context omitted.

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.

They failed few times (checked exceptions, raw types, plenty of JDK classes like Vector, Date, LinkedList and so on) yet we survived.

Re: New Features in Java 14

#123

Post by thu2111 »

lmm wrote: post #73
nitrogen wrote: post #62

Earlier quoted context omitted.

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

Looks like it's doing annotation processing at compile time? The trouble with that is that you end up with "magic" code like calling methods that don't appear to exist, and in order to be able to work on the serialisation itself (e.g. to add a new format) you have to understand the "magic", because there isn't a good intermediate abstraction. The great advantage of Shapeless is that all the "magic" is in the library…

It's not annotation processing, it's a compiler plugin with IDE support. So pretty deeply integrated. It avoids some of those issues.

The kotlinx.serialisation design is pretty nice. It's basically what you describe. The compiler generates generic code that can call into a variety of "codecs" but they don't have to actually be serialisation specific. So there are codecs for JSON, protobufs, CBOR etc but you can also do arbitrary object graph transformations with the framework. A deep clone being a simple hello-world type example. I've never used Shapeless but it sounds pretty similar in some ways.

https://github.com/Kotlin/kotlinx.serialization

Re: New Features in Java 14

#124

Post by vbezhenar »

dmitriid wrote: post #97

Can't understand the need for records when C# solves the problem of boilerplate with regular classes and some syntactic sugar.

Apparently immutable classes in a functional streams is a new hotness and nobody uses POJOs anymore. They'll slap pattern-matching on top of that, to complete the circle.

I completely agree as I, myself, see very few instances where I could use records in my code. But properties to remove getter/setter boilerplate? That would remove thousands of LoC. But it's not hot.

Fashion-driven development, that is.

Re: New Features in Java 14

#125

Post by thu2111 »

Sharlin wrote: post #98
hcarvalhoalves wrote: post #67

Earlier quoted context omitted.

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.

Huh, what? You don’t need or want most values to be potentially absent.

Yes, the difference is a combination of types being non-null by default and compiler enforced checking.

This doesn't require an option type. Option types are actually quite awkward compared to language integration. Kotlin doesn't use an Option type yet still delivers all the same benefits as Rust/Haskell's approach, with benefits (e.g. zero overhead, integrated syntax). Note that Option type overhead isn't merely about heavyweight syntax and the need for the compiler to successfully scalarise: using language integration around standard null pointers means the CPU spends no time on checking the 'maybe' branch. If the type system wasn't violated and a value is present, it's used immediately without any additional instructions or code bloat. If it's not then that will trigger a page fault at some point in the CPU pipeline and transfer control to an exception handler. If the type system indicates nullability and you need to actually do more than just unwrap it, then you have to take a branch of course but it's fully inlined and cheap.

Re: New Features in Java 14

#126

Post by Jenz »

leibnitz27 wrote: post #118

negative instanceof is a disaster I posted a bit about it here http://www.benf.org/other/cfr/java14instanceof_pattern.html it was first noted https://twitter.com/tagir_valeev/status/1210431331332689920 here but the main thing is that if the 'taken' conditional is guaranteed to exit, then scope hiding happens, if not, not. But in java if (true) { throw new Exception(); } is not guaranteed to exit. So: https://github.c…

Ooops

Re: New Features in Java 14

#127

Post by vbezhenar »

leibnitz27 wrote: post #118

negative instanceof is a disaster I posted a bit about it here http://www.benf.org/other/cfr/java14instanceof_pattern.html it was first noted https://twitter.com/tagir_valeev/status/1210431331332689920 here but the main thing is that if the 'taken' conditional is guaranteed to exit, then scope hiding happens, if not, not. But in java if (true) { throw new Exception(); } is not guaranteed to exit. So: https://github.c…

Looks like a bug. But anyway should be easily detectable by a static analysis and reported as a warning, so not a big deal in practice, even if working as intended.

Re: New Features in Java 14

#128

Post by thu2111 »

lmm wrote: post #59
benibela wrote: post #17

Earlier quoted context omitted.

And you can write sth.unwrap() in Rust, and then it panics when it is null. Kotlin solves it much better. sth?.do_something() ?: nothing_to_do

Panicing is the right thing to do: fail-fast is much better than silently continuing in an invalid state. If the None state is valid then don't call unwrap() (which you should almost never use, because if None was not a valid state then why were you using an Option in the first place?), call a function that lets you handle both cases, e.g. unwrap_or.

It's sometimes the right thing to panic, in which case use the !! operator to cast away the nullness and get an NPE at that point (now a helpful one as the new Java feature is really a JVM feature!)

With this new feature I'd argue the Java/Kotlin world now has the best handling of optionality of any language, anywhere:

• Pleasant, concise syntax for handling optionality. Not bolted on with an option type.

• Highly efficient translation to machine code. No boxing, no unnecessary branching in the unwrap/!! case.

• Excellent interop with older code written in OOP languages that don't represent nulls in the type system.

• But that older code can be annotated with @NotNull and @Nullable to retrofit the information; within Java IntelliJ will statically analyse these and add warnings where an NPE/panic would occur, when such code is used by Kotlin the annotations cause the types to be correctly derived as nullable or non-null.

• The large wealth of libraries that want to explore object graphs continue to work without being distracted by option/maybe types (e.g. serialisation, UI binding)

• On the rare occasions where you do need to unwrap and you got it wrong, you now get an error message that breaks down the sub-expression where the null pointer occurred, so there's no incentive to break up long chains of dereferences just to get better debugging in case of failure.

That's a featureset around optionality that's hard to match.

Re: New Features in Java 14

#129

Post by leibnitz27 »

vbezhenar wrote: post #127
leibnitz27 wrote: post #118

negative instanceof is a disaster I posted a bit about it here http://www.benf.org/other/cfr/java14instanceof_pattern.html it was first noted https://twitter.com/tagir_valeev/status/1210431331332689920 here but the main thing is that if the 'taken' conditional is guaranteed to exit, then scope hiding happens, if not, not. But in java if (true) { throw new Exception(); } is not guaranteed to exit. So: https://github.c…

Looks like a bug. But anyway should be easily detectable by a static analysis and reported as a warning, so not a big deal in practice, even if working as intended.

Nope - the if condition is not considered in flow analysis. Read the end:

https://docs.oracle.com/javase/specs/jls/se8/html/jls-14.htm...

"14.21. Unreachable Statements It is a compile-time error if a statement cannot be executed because it is unreachable.

This section is devoted to a precise explanation of the word "reachable." The idea is that there must be some possible execution path from the beginning of the constructor, method, instance initializer, or static initializer that contains the statement to the statement itself. The analysis takes into account the structure of statements. Except for the special treatment of while, do, and for statements whose condition expression has the constant value true, the values of expressions are not taken into account in the flow analysis."

Re: New Features in Java 14

#130

Post by thu2111 »

vbezhenar wrote: post #119
devonkim wrote: post #66

Earlier quoted context omitted.

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

I guess one of the reasons was abundance of hardware platforms and operating systems back then. Threads were not very native to UNIXes. Nowadays it's basically x86_64 and ARM with Linux/Windows which are much more mature.

I think the issue being referred to was the lack of a rigorous memory model. But that wasn't a failing of Java. Java was one of the first to get such a model, most languages/runtimes have never even tried at all.
Post reply on HN