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

321–330 of 464 posts

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

#321

Post by tadfisher »

inigyou wrote: post #175
wiseowise wrote: post #141

Earlier quoted context omitted.

How can Kotlin do it?

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…

Kotlin works around this by not exposing the backing field directly; a "field" becomes a "property" which has a getter and setter under the hood. Attempts to read uninitialized properties are compile-time errors. You can turn these into runtime errors using the "lateinit" keyword.

Kotlin still has a hole where you can run code in "init" blocks which are executed sequentially on object construction; in one, you can call a function that is defined after an unmodifiable property, and it will see the uninitiailized value.

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

#322

Post by ZenDroid »

mike_hearn wrote: post #160
wiseowise wrote: post #141

Earlier quoted context omitted.

How can Kotlin do it?

A lot of the language rules are required to make its approach to nullability work. Hence odd keywords like "lateinit var".

`lateinit var` was not added to Kotlin to handle nullability, but to address specific Android design where system components like Activity cannot realisticly initialize fields in their constructors. Outside of Android it shouldn't be too commonly used.

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

#323

Post by petilon »

I understand the rationale for value classes, but the implementation is flawed.

What will this code print:

   Point a = new Point(10, 10);
   Point b = a;
   a.x = 100;
   System.out.println(b.x);
Until now the answer was obvious. Now with the addition of value classes, the answer depends on whether Point is a value class or a reference class. So readability suffers with this design.

This is a violation of the principle of uniformity. In The Psychology of Computer Programming, Weinberg explains that uniformity is a psychological principle which says that users/programmers expect that things that look similar should do similar things, and conversely that things that look different should do different things.

If a programming language lets two constructs look nearly identical at the use site while having meaningfully different semantics, it increases the cognitive burden on the reader. Programmers must inspect the type declaration or rely on tooling to understand whether assignment, equality, identity, and mutation behave like ordinary reference objects or like values. That can make code harder to reason about and maintain.

This could have been fixed by requiring the use of the "value" keyword not just at declaration time but also at use time like this:

   value Point a = new Point(10, 10);
   Point b = a;
   a.x = 100;
   System.out.println(b.x);

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

#324

Post by mike_hearn »

ZenDroid wrote: post #322
mike_hearn wrote: post #160

Earlier quoted context omitted.

A lot of the language rules are required to make its approach to nullability work. Hence odd keywords like "lateinit var".

`lateinit var` was not added to Kotlin to handle nullability, but to address specific Android design where system components like Activity cannot realisticly initialize fields in their constructors. Outside of Android it shouldn't be too commonly used.

"lateinit var" predates Android's adoption of Kotlin by years and was added because fields initialized after construction by frameworks are common in many contexts, but having nullability in the language makes that annoying.

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

#325

Post by za3faran »

rf15 wrote: post #14
andyjohnson0 wrote: post #12

Earlier quoted context omitted.

> The whole attitude and process around this and the other topics gives me very little faith that Java can be steered in a sensible direction here. I agree. The stewardship of Java seems rather lacking - particularly when compared to that of .net, where MS etc. mostly seemed to make the correct decisions from the start. Does Java even have any value or mindshare at Oracle nowadays? The company seems to be a datacentr…

How .net got so many things right where java did not is a mystery to me, but appreciated (it has its own flaws, of course). Java, in my understanding, is still of core relevance to Oracle, and tied into a lot of contracts that require very little effort from them to maintain. But you are correct in observing that they want to be a datacentre/compute business more and more these days; they may have in fact overcomitte…

What things are you referring to? Especially after the many features that Java gained after Java 8.

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

#326

Post by Joker_vD »

petilon wrote: post #323

I understand the rationale for value classes, but the implementation is flawed. What will this code print: Point a = new Point(10, 10); Point b = a; a.x = 100; System.out.println(b.x); Until now the answer was obvious. Now with the addition of value classes, the answer depends on whether Point is a value class or a reference class. So readability suffers with this design. This is a violation of the principle of unifo…

Eh, still kinda murky. How about

    value Point a = new Point(10, 10);
    value Point b copy= a;
    a.x uniq= 100;
    System.out.println(b.x);
Now it's much more obvious that cloning/copying takes place, and mutating a field won't affect fields of any other objects.

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

#327

Post by andrepd »

mattstir wrote: post #144

> But the difference in memory is fundamental. The JVM can now store the values themselves in the array, laid out densely one after another: 8 bytes per point (plus a possible null flag), in a contiguous block. No headers per element. No pointers. No jumping around the heap. How much was this article proof-read? Didn't they just get finished talking about how heap flattening won't work for objects with > 64-bit repre…

I've been sadly using too much Claude not to immediately recognize this verbal construction...

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

#328

Post by zoogeny »

petilon wrote: post #323

I understand the rationale for value classes, but the implementation is flawed. What will this code print: Point a = new Point(10, 10); Point b = a; a.x = 100; System.out.println(b.x); Until now the answer was obvious. Now with the addition of value classes, the answer depends on whether Point is a value class or a reference class. So readability suffers with this design. This is a violation of the principle of unifo…

I believe that the statement `a.x = 100;` is invalid since Record types are immutable.

That is, the situation you are afraid of should be impossible.

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

#329

Post by Joker_vD »

Dylan16807 wrote: post #266
smokel wrote: post #209

Earlier quoted context omitted.

18446744073709551616 possible values and you can't spare 1 for null? :) TIL that Rust has NonZeroU64 which you can combine with Optional to get the required behaviour with only 64 bits per entry. [1] [1] https://doc.rust-lang.org/std/num/type.NonZeroU64.html

Especially because signed integers aren't symmetrical. Reserve INT_MIN and you get 8 billion NaN values and multiplying by -1 always gives you a valid location.

Ah, INT_MIN. If I had a nickel every time I saw an implementation of inttostr/strtoint that don't properly handle it, I'd probably have about $5. So I too thought about possibility of it serving as a NaN of signed integers... but I doubt we'll see it any time soon.

Also, apparently, shifting a negative number to the left is UB in C.

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

#330

Post by andrepd »

rayiner wrote: post #275
wongarsu wrote: post #274

Earlier quoted context omitted.

I learned that exact style of writing in a marketing workshop, pre-AI. It's effective, satisfying, and a random third thing I can't be bothered to come up with right now. As a proportion of all easily crawled text on the internet, a lot of it will be random marketing copy. That influenced the writing style of early AIs, and since then everyone has trained at least partially on transcripts from every other AI chatbot

Oh my god did we inadvertently train AIs on idiotspeak.

No, we actually trained it on standardised tests https://marcusolang.substack.com/p/im-kenyan-i-dont-write-li...
Post reply on HN