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

451–460 of 464 posts

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

#451

Post by ivolimmen »

jaen wrote: post #129
ivolimmen wrote: post #100

Earlier quoted context omitted.

Same for me. I have worked with Java since 1.2.2 and used .NET for something like 10 years (don't remember the versions). Most important differences are: -Java always has an API, .NET is about extending an existing application (Servlet API vs IIS) -Java has a nicer IO as .NET has bidirectional streams (You can't wrap streams in .NET). -Linq is nice but has a huge caveat: if a Linq provider does not implement it fully…

> -Linq is nice but has a huge caveat: if a Linq provider does not implement it fully to falls back to the .NET collections. So trying to 'Skip' and 'Take' on a ActiveDirectory will fall back to collections in memory and cause a crash on a huge AD in production (Yes had the pleasure). How do you expect this to work then? If the provider is bad, blaming LINQ for it makes no sense... You either have a high level of abs…

I mostly blame it on Linq but you are right it mostly because bad documentation on both the provider and the general stuff on how Linq works.

Yes Java does not have an alternative for Linq and jooq is a poor knock-off compared to this but then again: I do not care much for JPA/Hibernate.

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

#452

Post by ivolimmen »

Rohansi wrote: post #199
ivolimmen wrote: post #100

Earlier quoted context omitted.

Same for me. I have worked with Java since 1.2.2 and used .NET for something like 10 years (don't remember the versions). Most important differences are: -Java always has an API, .NET is about extending an existing application (Servlet API vs IIS) -Java has a nicer IO as .NET has bidirectional streams (You can't wrap streams in .NET). -Linq is nice but has a huge caveat: if a Linq provider does not implement it fully…

> .NET is about extending an existing application (Servlet API vs IIS) I don't think this is true anymore since ASP.NET Core. While you can still run under IIS but it's a more typical reverse proxy setup instead of running inside IIS. > You can't wrap streams in .NET You've always been able to wrap streams in .NET so I'm not sure what you mean by this

Yes ASP.NET core is a big improvement; I recently tried .NET again on my Linux machine and was able to run .NET and skip using Mono.

If we want to compress a file we normally just wrap the file ouputstream in a GZIPOutputStream so we add features by wrapping it.

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

#453

Post by int_19h »

homebrewer wrote: post #47
tomaytotomato wrote: post #32

A lot of the comments on here are a bit unfair on what is great work being done and even more awesome work (JEPs) in the pipeline for the future. If Java was a child, imagine it being brought up by loving parents for the first few years (Sun) then it was thrown in a garage with some other children and neglected by its evil guardian (Oracle) Neglected and unloved till JDK 8, its basically been playing catch up. So whe…

It was neglected during its last few years at Sun. Oracle started moving it forward at never before seen pace, while mostly maintaining backward compatibility (unlike .NET that "did things right from the start", which is what .NET Framework/.NET Core/.NET split/rewrite is according to some in this very discussion. And .NET had Java to copy and learn from, but still fucked up.) Same with MySQL, btw. "Dead" according t…

Ironically the worst parts of .NET today are the things it copied from Java and now can't get rid because of backwards compatibility (stuff like covariant yet mutable arrays, for example).

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

#454

Post by tsimionescu »

inigyou wrote: post #440
tsimionescu wrote: post #177

Earlier quoted context omitted.

Sorry, I misinterpreted your question to be about non-nullable value classes, not non-nullable classes more generally. For reference variables, it seems that the a priori best approach would have been to generate a compiler error if the field was read before it was written; since this ship has long since sailed with final fields, it seems that the same approach would have to be taken - the "not null able" guarantee o…

The compiler doesn't solve the halting problem so it doesn't know whether a field is read before it's written. If you allow a nonnull field to hold null at any point then it's trivial to leak that out and have nonnull variables holding null all over the program, which is obviously something to be avoided. Maybe you can say that if you read a nonnull field when it's null, that throws an exception. That might have its…

You don't need to solve the halting problem to prevent such access, not even close. You simply apply the same strategy as any other property you want to enforce - you prevent any use of the variable that can't be proven safe. You want to pass this in a call from the constructor to a function defined somewhere else where it might access a final/non-null able field that has not yet been initialized? Not allowed, only member functions that don't call other non-member functions allowed from the constructor.

Of course, as I said, this ship has long sailed for general Java classes. It would be far too big of a breaking change to add such a limitation today. However, we know for sure this could have been done in Java: this is exactly how record and now value classes work: any call that could expose un initialized fields is in fact disallowed.

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

#455

Post by tsimionescu »

usrusr wrote: post #183
tsimionescu wrote: post #155

Earlier quoted context omitted.

All of this would be valid, except that value classes still pretend that their fields can be private. This also has huge implications in a language that emphasises dynamic loading like Java. And it also flies in the face of all of the pretenses that ABI compatibility is sacrosanct and no feature that breaka it can be considered, that the design team often touts.

Why pretend? "private" on value types just means nothing to see here except when you happen to be one of the functions conveniently namespaced with the struct. But I'd say that GP's complaint about inequality leaking makes no sense anyways, because what could be more unequal than different implementation, or different internal state implying different behavior down the line? The public subset isn't some arbitrary int…

The JEP itself highlights the problem of == leaking private details, and recommends avoiding its use in favor of equals(). It also highlights the potential security risk because of this, noting that private fields of value classes should not be considered secret because of this (and the new identityHash method).

The JEP also gives examples of classes where == would return false for instances that would behave exactly the same from an external perspective. They give examples mostly revolving around strings and other reference objects as fields of value objects; and some weirdness around float and double NaN. There's also the classical case of caching, where an object may store the inputs to a complex calculation, but can also cache the result of said calculation - and asking for the value can either perform the calculation, or return the cached result (though Java value classes don't fit this too well, given their limitations of being immutable).

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

#456

Post by drzaiusx11 »

arein3 wrote: post #161
drzaiusx11 wrote: post #122

Earlier quoted context omitted.

They just decided to tackle non-nullable value types in a follow-on JEP. I don't think they're saying it's untenable. You don't eat the elephant in one bite and all that. That said, we've been gnawing on this limb for a while...

Ill be old when null safety will finally arrive This takes longer than game of thrones books

I still recall when java first came out, its all relative--but sure, a decade can seem like eons in software.

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

#457

Post by tsimionescu »

inigyou wrote: post #441
im3w1l wrote: post #370

Earlier quoted context omitted.

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.

...which is exactly how value classes and (after this JEP) records work. You are not allowed to call any instance methods before the call to `super()` (which happens implicitly at the end of the constructor for value classes and for records, unless you explicitly call it), and you are not allowed to call `super()` without first setting a value for all of your fields.

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

#458

Post by stickfigure »

pron wrote: post #449
stickfigure wrote: post #448

Earlier quoted context omitted.

> 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…

This is a strange conversation; you must be misinterpreting me.

I'm not saying that the people who wrote this are dumb, or that Java is a bad language, or that it's time to move to Kotlin, etc. I use Java every day. I pick Java for greenfield projects. I'm on Team Java.

I'm saying I don't like this proposal. I happily accept that this proposal might not become part of the Java language. That's great! I'm spending time writing this in public specifically to discourage it in some tiny way.

It would be fair to tell me "you should write this to the proposal writers directly". And I understand how the language snobbery on HN might make you feel defensive - I often feel that too. But I think my criticism here is valid.

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

#459

Post by kuhsaft »

petilon wrote: post #334
zoogeny wrote: post #328

Earlier quoted context omitted.

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.

If that's true then it is a significant improvement over structs in C#. But the distinction still matters. Value-vs-reference semantics affect equality, identity, nullability, arrays, collections, boxing, and performance. So this is not just an implementation detail. If a language hides that distinction at the use site, it increases the burden on the reader and makes code harder to reason about.

I don’t see how it’s an improvement over C# structs. C# structs are value types so they are copied when assigned to a variable like primitives. There is no ambiguity because it’s a struct.

To avoid copying you have to explicitly declare a ref variable/parameter.

You can get the same immutability as value classes by using ‘readonly struct’s or ‘readonly record struct’s.

Java value classes are stranger because they are heap allocated by default and are only flattened/scalarized/stack-allocated when certain conditions are met. It’s the same as a class, but with extra restrictions, so that the JVM can possibly optimize memory layout at runtime.

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

#460

Post by pron »

stickfigure wrote: post #458
pron wrote: post #449

Earlier quoted context omitted.

> 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…

This is a strange conversation; you must be misinterpreting me. I'm not saying that the people who wrote this are dumb, or that Java is a bad language, or that it's time to move to Kotlin, etc. I use Java every day. I pick Java for greenfield projects. I'm on Team Java. I'm saying I don't like this proposal. I happily accept that this proposal might not become part of the Java language. That's great! I'm spending tim…

> I'm saying I don't like this proposal

And I'm trying to tell you that this document is not what you think it is. It's a rough sketch of a building's foundations and your critique is about the roof. Even if this were to become a proposal, it's likely the matter of defaults of this feature will be covered by a different JEP, because Java features are usually broken down into multiple JEPs. What you're complaining about may be part of the feature, but it is not covered by this document. If this becomes a JEP and another JEP talks about nullabilty defaults, then you could criticise the selection of defaults, but that particular aspect of this feature is outside the scope of this particular document. So one, this is not a proposal, and two, you haven't seen the description of the part of the feature you want to criticise.

We are well aware that splitting features over multiple JEPs can invite such misunderstandings, but that doesn't change the fact that Java features are, at least currently, split over multiple JEPs. We are also well aware that if this does become a proposal, adding ! everywhere is not what we want, but we want to cover that aspect in a different document, as we usually do. Most Java users aren't confused by this because they don't read the JEPs at all, but such splits help focus the discussion on one aspect of a feature at a time. So your desire for a non-nullable default is very understandable, it's just not relevant as a critique of this document.

For example, the virtual threads JEP described a pinning limitation. We knew it reduced the applicability of that JEP and said as much. We just wanted to address it in a different JEP, and so we did (https://openjdk.org/jeps/491). Ever since the JDK switched to time-boxed, semiannual releases, this is how we've delivered features: in multiple pieces. The same applies to Valhalla.

Post reply on HN