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

Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

jvm-weekly.com

Post reply on HN
Print view View original

441–450 of 464 posts

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#441

Post by inigyou »

im3w1l wrote: post #370
inigyou wrote: post #173

Earlier quoted context omitted.

That's worse than null. Now every object has an invalid state. It works for Go because Go is trying to keep language complexity low. It has no good design principles behind it other than that. Also the zero value of a reference is null so you still haven't answered how a non-nullable reference field would work.

I think you should require the code to be written in such a way that the compiler can verify the value is never read before initialization. There might be some subtleties in how to do that but I don't think it should be insurmountable.

It's completely insurmountable. It basically means you can't call any functions during initialization. Including the one that creates the object you want to point your nonnull reference to.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#442

Post by inigyou »

wiseowise wrote: post #213
inigyou wrote: post #175

Earlier quoted context omitted.

Probably with hacks. Did you know a final field in Java can change its value? And I'm not talking about his reflection to make it non-final. With ordinary code only, you can read a final field before it's been initialized, so it still holds its default zero value. For example "final int x = calcX();" and have calcX print the value of x, it will be zero. There's a whole bunch of specification language describing how c…

Nothing stops me from sticking my dick into a blender either, yet it works fine for most of the things (the blender). Both Java’s notion of final and Kotlin’s nullability work great for 99.999 use cases and you really need to go out of your way to break them.

If you can get a null into a nonnull variable, it can propagate all over the program and people will be defensively checking for it everywhere - final is not like this.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#443

Post by gf000 »

slavapestov wrote: post #432
w10-1 wrote: post #271

A bit fuzzy and dramatic; luckily the original documents are quite readable: top-level page: https://openjdk.org/projects/jdk/28/spec/ JEP status: https://bugs.openjdk.org/secure/Dashboard.jspa?selectPageId=... I'd really like to see someone trace related developments in C#, Swift, Java, and Rust, since they all have been racing to catch up to hardware, and I believe they are cross-pollinating. (My concern is how all…

FWIW both Swift and Rust have had value types and generics that abstract over unboxed values since the start.

Not sure I would call them the same - not too familiar with Swift but for rust you probably mean types implementing the Copy trait?

But Java's value types are a higher level semantic feature, these objects may do a Copy or a Clone based on heuristics. So probably not the exact analogue but of course rust being a lower level language it can express where and when memory is allocated.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#444

Post by gf000 »

cogman10 wrote: post #438
geokon wrote: post #351

Earlier quoted context omitted.

I actually don't understand the tearing they're talking about. If the fields are final then you can't modify the Value Type anyway? And a simple write-lock bit for fat Value Types would solve everything while maintaining most of the performance benefits (both on read and write)

The problem is concurrent access. A write bit on the value doesn't really help as you have to check and update the bit using atomic instructions. But you'd also need to reserve that bit for every read as concurrent access wouldn't be safe. That's the tearing problem. It gets worse because things you can't generally do in the JVM can happen. For example, if your value class contains a reference to an object but that r…

References can't tear in Java, per the specification (long and double could actually, the spec only talks about references and 32-bit slots being tear-free - though actually almost all implementations have them atomic as it's practically free on 64-bit CPUs). That would basically make the platform memory unsafe so I'm fairly sure they would make sure references are always written atomically.

But tearing may still cause a logical issue of course. (Think of a date class where the day may still be 31 but the month was set to Feb on another thread).

Interestingly Go is memory unsafe on this issue, slices can tear and later code can read into an incorrect offset from the pointer. Java abstracts away pointers, so this issue is non-existant there.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#445

Post by wffurr »

cenamus wrote: post #422
wffurr wrote: post #401

Earlier quoted context omitted.

https://github.com/bytecodealliance/wasm-micro-runtime https://github.com/WebAssembly/wabt/blob/main/wasm2c/README.... ISTR Siemens uses wasm2c to compile Wasm for a bunch of embedded devices runninng Zephyr RTOS.

Fair point, but translating to C is almost cheating ;)

Sure, but it's a trick not available to most JVM languages.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#446

Post by pron »

egeozcan wrote: post #365
jayd16 wrote: post #359

Earlier quoted context omitted.

This is pretty funny... "All differences are opinions....except what .net did. Those are wrong!" I personally think Java continues to to waste a lot of time and come to a slightly more verbose and worse solution again and again. Structured concurrency is like c# async/await with less sugar. Streams are just LINQ but worse. It's probably exactly because of the "not like .NET! We must be different to explain being late…

As a person with a lot of .NET experience but has been working on other tech since 6 years, the wow effect I had from using LINQ has never been repeated with anything else. It felt like magic, maybe too much magic, but so useful nevertheless.

Java is getting that power in a different, more orthogonal way, IMO, through Project Babylon: https://openjdk.org/projects/babylon/

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#447

Post by chopin »

groestl wrote: post #400
63 wrote: post #305

Earlier quoted context omitted.

Many of us work on Java monoliths that started in the 2000s when it was in vogue and we still have to keep them chugging along on Java 8. Personally I'm familiar with all the new features that have come out in the last few years, but for my actual work, java is literally stuck in the past.

> we still have to keep them chugging along on Java 8 There's something else amiss here. Compared to other platforms, upgrading Java, even on complex codebases, has never been a nightmare for me.

The problem in a large codebase is keeping consistency when upgrading.

I upgraded a codebase of approx 100 kloc from Java 7 to Java 8 a couple of years ago. As I didn't want mixed patterns for the same thing throughout the code base I replaced most of the loops with their streaming equivalent. I had the luxury of having the budget for doing so.

Mixing patterns of newer language features alongside older ones can make the code base hard to read.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#448

Post by stickfigure »

pron wrote: post #331
stickfigure wrote: post #294

Earlier quoted context omitted.

It's a proposal for a proposal, fine. Consider this my proposed feedback. I don't think this syntax is desirable as currently proposed, and that one line under "future work" is doing far too much lifting. My sincere hope is that there are people closer to the process that also feel this way, they will provide similar feedback, and the next draft will be something completely different.

Except we like delivering features by pieces, so unless your proposal is to first deliver global flags with no instance-specific control and later add more control (and I think you're not suggesting that), I don't see any difference between what you're suggesting and what that draft is suggesting. That a one-line under "future work" is doing a lot of lifting is just how we usually do it (and it's okay, people always…

> how the site-specific nullability annotations could work

That's fine but it's still a bad choice. The problem is that it defaults to everything nullable and adds noise for non-nullable. This is backwards; in the overwhelming majority of software that people use Java for, non-null is the common case and nullability is the exception.

Kotlin and Typescript got this right. Nobody wants! to! write code! like! this! And they won't, so the feature won't get used and we're back to everything being nullable.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#449

Post by pron »

stickfigure wrote: post #448
pron wrote: post #331

Earlier quoted context omitted.

Except we like delivering features by pieces, so unless your proposal is to first deliver global flags with no instance-specific control and later add more control (and I think you're not suggesting that), I don't see any difference between what you're suggesting and what that draft is suggesting. That a one-line under "future work" is doing a lot of lifting is just how we usually do it (and it's okay, people always…

> how the site-specific nullability annotations could work That's fine but it's still a bad choice. The problem is that it defaults to everything nullable and adds noise for non-nullable. This is backwards; in the overwhelming majority of software that people use Java for, non-null is the common case and nullability is the exception. Kotlin and Typescript got this right. Nobody wants! to! write code! like! this! And…

> it's still a bad choice

Except there's no choice here. It's a draft of an exploration of a portion of a feature.

Drafts are ideas that have not even been submitted for consideration for inclusion in the roadmap. You can find drafts over ten years old that have long since been superseded by other ones or abandoned altogether: https://openjdk.org/jeps/0#Draft-JEPs. Some JDK engineers write JEP drafts when they feel they get close to something they would like to propose, while others write drafts for pretty much any idea they have.

> The problem is that it defaults to everything nullable and adds noise for non-nullable

It doesn't, though. Even if this draft ever becomes a JEP (and I don't know if it or anything like it will), in its present form or another, it would still, like most JEPs, describe only part of the feature. It's perfectly on point for one JEP to describe the explicit nullability annotations, while another describes the defaults. Smaller features than this have been split into two or three JEPs. This is just how Java features have been described and delivered for years now (see how many JEPs patterns were split into: https://openjdk.org/jeps/0).

It's perfectly okay to dislike some design, but I find it strange to assume, based on a draft of a portion of a feature that one of the most experienced and successful programming language design teams in the history of software is likely to get it wrong. Maybe wait until there's an actual proposal and a roadmap for the complete feature before critiquing it? It's like seeing a draft of some building's foundations by a prestigious architectural firm and saying, these idiots forgot to plan a roof.

Re: Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

#450

Post by donkeylazy456 »

pjmlp wrote: post #111
pfannl wrote: post #107

Earlier quoted context omitted.

C# often feels like Java with hindsight; Java feels like Java with 30 years of backward compatibility debt.

Hence why so many .NET projects keep being .NET Framework instead having migrated to modern .NET.

mostly they are sticking to .net standard 2.0 that is compatible both framework and modern.
Post reply on HN