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

91–100 of 464 posts

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

#91

Post by simonask »

gf000 wrote: post #35
sysguest wrote: post #22

Earlier quoted context omitted.

idk maybe java should adopt something similar to rust's "edition"?

Correct me if I'm wrong, but Rust editions are a source code-level feature. So given you have the source code of newer and older rust code, you can compile them together. That's materially distinct from Java's model of basically dynamic loading already compiled class files. Though class files do have "editions", and there are extra code to deal with different versions. But still, it should be possible to e.g. send a…

The important thing is that Rust editions affect semantics and name resolution. In such an analogy, JVM bytecode is the equivalent of Rust code - various semantics are baked in, but stuff like name resolution isn't (at least not completely).

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

#92

Post by jmyeet »

rf15 wrote: post #4

I appreciate the hard work that went into the things that did make it into Valhalla eventually, but: > The model was powerful, but also mentally heavy No it isn't! it is this interpretation that kills off the null-safety debate entirely. Saying you have a variable that cannot be null is not a mentally taxing distinction, especially since everything is labelled thoroughly. > The team, faithful to the lesson “simplify…

Java made several mistakes. It also made some questionable (yet often defensible) decisions. It's understandable. Type erasure was one I believe was a mistake. It's talked about in the article. Yes, you kept binary compatibility but you that created so many other problems such as not being able to use value types in generics. Notably, C# looked at that and said "nope". Type erasure is also hurting Valhalla here and the issue of value classes in generics is the second phase so is being pushed far into the future.

But a huge mistake (IMHO) was not having nullability part of the type system. You can still do this with type erasure.

Anyway, I read your comment as "nullability isn't complex" (paraphrased) but that's not the author's point. What's complex is having a value class and a regular class of every class and you don't necessary know which one you're dealing with at the language level.

C++ is a great example of this. You can create an object ont he stack or the heap and that's really what we're talking about with that proposal. And that's a nightmare. Combined with pointers it meant you never knew if you could free something or not and that ownership had to be passed around with vague comments like "// retains ownership".

Anyway, the whole article is a great tale of how difficult it is to retrofit things later and how difficult it can be to fix mistakes later (eg java.util.Date).

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

#93

Post by watt »

leiroigh wrote: post #63

I'll be interested in seeing the fallout of the (unavoidable) compat issue: If I have a function that has a value `x` that erases to `java.lang.Object` (e.g. a parametric function with no lower bound); then it used to be safe to check for nullity and then synchronize on the object. This is no longer safe: This can now throw `IdentityException` into your face. (it was _never_ a good idea) In other words, a lot of old…

You lost me at "I have a function that has a value `x`". How does function "have" a value?

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

#94

Post by inigyou »

jmyeet wrote: post #92
rf15 wrote: post #4

I appreciate the hard work that went into the things that did make it into Valhalla eventually, but: > The model was powerful, but also mentally heavy No it isn't! it is this interpretation that kills off the null-safety debate entirely. Saying you have a variable that cannot be null is not a mentally taxing distinction, especially since everything is labelled thoroughly. > The team, faithful to the lesson “simplify…

Java made several mistakes. It also made some questionable (yet often defensible) decisions. It's understandable. Type erasure was one I believe was a mistake. It's talked about in the article. Yes, you kept binary compatibility but you that created so many other problems such as not being able to use value types in generics. Notably, C# looked at that and said "nope". Type erasure is also hurting Valhalla here and t…

How would a non-nullable class field work in Java when it can be initiqlized by arbitrary imperative code that can read it while it's being initialized?

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

#96

Post by rob74 »

ahartmetz wrote: post #19

From the article: > In 1995, a memory access cost roughly the same as a CPU operation Uhm... no?! Here's a CS paper from 1993(!) about prefetching from cache(!!) because the cache was slower than the ALU. https://www.eecs.umich.edu/techreports/cse/93/CSE-TR-152-93.... It would perhaps make Java look a little bad to say that, in 1995, the prevailing attitude in certain circles was "If it's too slow, just wait for fast…

Yeah, when I read that, I thought "this guy was either born wayyy after 1995, or he doesn't know the first thing about computer hardware history, or both". 1995 was the year the Pentium Pro was launched, which was (one of?) the first CPU(s) to integrate the L2 (!) cache into the same package as the CPU - they were still separate chips, but the interconnection could be made faster by putting them into the same package.

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

#97

Post by cogman10 »

gf000 wrote: post #45
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…

> 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) Whether you like oracle or not, this is simply not a correct description of Java's history. It was brought up by loving parents, who due to financial problems had to put Java into a foster home where she was neglected. Bu…

Yup. I was around for and skeptical of the Oracle purchase of Sun. I was worried about what it would mean for Java.

The Java team has been delivering nice language and environment improvements regularly since Java 10.

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

#98

Post by jmyeet »

inigyou wrote: post #94
jmyeet wrote: post #92

Earlier quoted context omitted.

Java made several mistakes. It also made some questionable (yet often defensible) decisions. It's understandable. Type erasure was one I believe was a mistake. It's talked about in the article. Yes, you kept binary compatibility but you that created so many other problems such as not being able to use value types in generics. Notably, C# looked at that and said "nope". Type erasure is also hurting Valhalla here and t…

How would a non-nullable class field work in Java when it can be initiqlized by arbitrary imperative code that can read it while it's being initialized?

The type erasure version of this would look a lot like Hack [1]. So generic arguments would simply have a ? if they allow nulls eg List. The list itself couldn't be null unless it was ?List.

Now, one can argue that this is just smoke and mirrors with type erasure and it is but you can already put a Date into a List if you're so inclined because the JVM doesn't know the difference, hence type erasure. So this is no different.

I'm no JVM expert but from reading the article it seems like the chosen solution for value classes is to treat them all as a single L-type in the JVM where each primitive type is its own L-type. If I read the correctly, it means that if you have a Point value class then on the JVM level you'll be able to stuff any value class into there if you're so incline, just like with List.

Obviously we need to be concerned with fuzzing (moreso in C++) but here really we're just trying to have sensible defaults that aren't guaranteed because we can't design the language how we want from the ground up without making a new language.

Oh and there is a prosopal for this [2]. Personally, I prefer the Hack version.

[1]: https://docs.hhvm.com/hack/types/nullable-types/

[2]: https://openjdk.org/jeps/8303099

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

#100

Post by ivolimmen »

watwut wrote: post #17
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…

> particularly when compared to that of .net, where MS etc. mostly seemed to make the correct decisions from the start. Wut? I did worked on .net projects and all it achieved was making me like java a lot more then previously.

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 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).
  -Java's Eco-system is way bigger.
Post reply on HN