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

421–430 of 464 posts

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

#421

Post by dpark »

How are people still defending type erasure? Sure, it was “defensible” in the sense that there were reasons the choice was made. But it was clearly a bad choice (to many people at least) when it was made and the effects are still rippling through the ecosystem. With the benefit of hindsight, it’s even more clear that the naysayers were correct and the harm to the Java ecosystem from type erasure is worse than the harm from creating parallel libraries would have been.

If sane generics had been introduced, the non-generic collection types would be a historical oddity by now and we wouldn’t be talking about how a future enhancement is going to undo the erasure decision.

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

#422

Post by cenamus »

wffurr wrote: post #401
cenamus wrote: post #267

Earlier quoted context omitted.

Yeah I didn't mean it as praise for Java (SE, ME, or whatever), but I don't think you're better off finding embedded WebAssembly jobs

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 ;)

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

#423

Post by sroussey »

aardvark179 wrote: post #403
sroussey wrote: post #368

Earlier quoted context omitted.

https://github.com/oven-sh/WebKit/pull/249

Although the work being done to enable multiple threads in JS is impressive I think it will be hard to make robust in many casss without locks, or fairly strict limits what operations can be performed on objects shared between threads. The property lookup and modification process in JS is complex enough as is, is not specified in an atomic kind of way, and has many opportunities for user code to be run as part of acc…

https://tc39.es/proposal-structs/

Structs, Shared Structs, and Synchronization Primitives

There are a few things that would be required to make it all work, this would be one of them.

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

#424

Post by cogman10 »

pjmlp wrote: post #407
kuhsaft wrote: post #405

Earlier quoted context omitted.

Yeah, that’s a different issue. Statically-typed languages, including type-erased languages, are fine on the CLR. Dynamically-typed languages are a different beast. I suppose DLR would be comparable to GraalVM/Truffle. The difficulty of implementing a dynamically-typed language directly on the CLR and JVM are about the same. Though, it would probably be more efficient on the CLR with access to lower level operations…

DLR inspired the addition of invokedynamic opcode on the JVM, which is actually the foundation for how lambdas get generated, many still think nested anonymous classes are used. GraalVM already handles LLVM bitcode, much cooler than plain MSIL. And here there is another example where Java ecosystem ends up being better. MSR had a compiler framework similar to GraalVM, called Phoenix, it was going to replace VS, LLVM…

> many still think nested anonymous classes are used.

Anonymous classes are still used (sometimes). It simply depends on the circumstance of the lambda.

For example, this will result in a new anonymous class being generated.

    void foo(String s) {
      stream.filter(i->s.equals(i));
    }
The class gets generated to capture the `s` variable. Indy gets used in the `filter` method because the incoming lambda or method reference could be several types of method calls. For example, a constructor, an instance method, or a static method (I believe there are few more in the JVM bytecode).

What won't generate a new anonymous class is this sort of lambda

    stream.filter(i->"foo".equals(i));
That will generate a new method on the parent class which ultimately gets called. Since nothing is captured it can be directly called without a new instance being created.

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

#425

Post by gf000 »

Panzerschrek wrote: post #373

> we want the JVM to be able to treat them as efficiently as primitives. They want basically to solve the main Java design flaw with (almost) everything is a reference paradigm. C++ and Rust have had value-types from day one. > 64 bits, including the null flag So, this basically makes every value-object optional, adds extra overhead and makes code less safe to null pointer dereference errors. > but a class with, say,…

That's like going to a steak bar and saying that this place sucks after the pre-dinner snacks.

Java JEPs are piecemeal, there is plenty other JEPs building on top.

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

#426

Post by mrkeen »

gf000 wrote: post #380
tsimionescu wrote: post #190

Earlier quoted context omitted.

The whole point of using Optional/Maybe is to prevent the possibility of accidemtally creating nulls. If you don't make mistakes, then nullability is not a problem. If you do make mistakes, then a class that only helps when you don't make mistakes is basically useless. This also has significant impact for serialization/de serialization - a classic place where you get unexpected nulls, that Java Optional/Maybe don't h…

Disagree. Types are both for the compiler, as well as for the developer. Maybe types are implicit documentation telling the developer that it is meaningful in the application that this field can have a None state. That's a huge code smell to ever set null to an Optional/Maybe and code reviews, linters, nullness analyzers all should/will flag such. Like I have never ever had an NPE from an Optional being null. Sure, c…

This is what your choices are with regard to communicating to the compiler and other developers.

Use a regular class to signal that you may or may not have a value.

Wrap it in an optional to signal that you may or may not have a value.

See the problem?

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

#427

Post by WorldMaker »

pjmlp wrote: post #392
WorldMaker wrote: post #354

Earlier quoted context omitted.

IronPython did just fine with reified generics.

Actually no it didn't, DLR was created exactly to support dynamic languages on the CLR. Nowadays largely abandoned, and I think not everything survived the transition from .NET Framework into modern .NET.

The DLR is just a shared library. It never changed anything about the CLR under the hood nor did it change anything about how Generics worked in the CLR (being the most relevant part of the thread here). IronPython could instantiate Generics just fine, and did just fine working with them.

The DLR is not "abandoned" so much as "complete". Everything did survive the transition into modern .NET and IronPython 3.4.2 runs just fine on .NET 6+ [1]. (For those trapped on the ugly side of the Python 2/3 split, even IronPython 2.7.12 runs on .NET 6.) Most of the "magic" of the DLR is shared with C# Linq in interesting ways (the System.Linq.Expressions AST) and sort of "has to survive" if only to properly support IQueryable (and wilder relatives like IQbservable, the Q is not a typo) even if most people aren't actively using DLR languages today (nor that much usage of C#'s `dynamic` keyword).

IronPython is a community supported (truly open source) language so doesn't get as much attention now as it did in the brief "first party" support era, so some may call that "abandoned" but F# has always lived in that gray space where it is primarily "community supported" more than "officially supported" by a dedicated team at Microsoft.

[1] https://github.com/IronLanguages/ironpython3/releases/tag/v3...

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

#428

Post by pjmlp »

WorldMaker wrote: post #427
pjmlp wrote: post #392

Earlier quoted context omitted.

Actually no it didn't, DLR was created exactly to support dynamic languages on the CLR. Nowadays largely abandoned, and I think not everything survived the transition from .NET Framework into modern .NET.

The DLR is just a shared library. It never changed anything about the CLR under the hood nor did it change anything about how Generics worked in the CLR (being the most relevant part of the thread here). IronPython could instantiate Generics just fine, and did just fine working with them. The DLR is not "abandoned" so much as "complete". Everything did survive the transition into modern .NET and IronPython 3.4.2 runs…

The addition of dynamic, and JIT being aware of IDynamicMetaObjectProvider also mattered.

Even though most of the communication around dynamic was about COM support and Excel.

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

#429

Post by pjmlp »

cogman10 wrote: post #424
pjmlp wrote: post #407

Earlier quoted context omitted.

DLR inspired the addition of invokedynamic opcode on the JVM, which is actually the foundation for how lambdas get generated, many still think nested anonymous classes are used. GraalVM already handles LLVM bitcode, much cooler than plain MSIL. And here there is another example where Java ecosystem ends up being better. MSR had a compiler framework similar to GraalVM, called Phoenix, it was going to replace VS, LLVM…

> many still think nested anonymous classes are used. Anonymous classes are still used (sometimes). It simply depends on the circumstance of the lambda. For example, this will result in a new anonymous class being generated. void foo(String s) { stream.filter(i->s.equals(i)); } The class gets generated to capture the `s` variable. Indy gets used in the `filter` method because the incoming lambda or method reference c…

I had another idea given Brian's talk on the matter.

Never bothered to actually look into the generated bytecodes.

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

#430

Post by kuhsaft »

kuhsaft wrote: post #417
torginus wrote: post #5

I know its a faux pas in the Java world to acknowledge the existence of .NET, but how does this differ from .NET structs? Value types, generic specialization, boxing - a quick skim makes it looks like they picked the same choices.

The C# equivalent to Java ‘value class’ would be a class with a struct encapsulated for data. The data is flattened and allocated on the heap like Java. Similarly, escape analysis could stack allocate the class at runtime, and they can be scalarized like C# structs. Java ‘value class’ only flattens if the total size of the class data fits within an atomic read/write op. You can force it to flatten, but you may have t…

Even closer would be a C# ‘readonly record struct’. Though, it would be allocated on the stack unless you box it.
Post reply on HN