[dead]
JEP 401: Value Objects (Preview) merged to OpenJDK master
101–110 of 185 posts
Re: JEP 401: Value Objects (Preview) merged to OpenJDK master
#102I feel lonely in that: I mostly love Java as a language. The lack of value types is the biggest impediment to certain types of performance. I am really looking forward to this evolution of the language.
I don’t do programming for a living (i manage infrastructure) but i have a very fond memory of java from the earliest days of my career.
I really really think that java is weighted down by all the ceremonial enterprise stuff that has accumulated over the years.
Lightweight frameworks are somewhat recent, otherwise you really couldn’t print a text/plain http response without bringing up a whole application server and a whole ecosystem of libraries (j2ee)
Also… the build system situation is still shit
Re: JEP 401: Value Objects (Preview) merged to OpenJDK master
#103Earlier quoted context omitted.
Of particular note, all 1-byte Integers are interned, there is a pool of small Integers from -127 127 which are reused whenever possible. I learned this the hard way, when a C++ JNI extension I was working on accidentally overwrote the pooled value for zero, and all hell broke loose...
Yeah - it's a bit non-intuitive you can change the value of a number. https://thedailywtf.com/articles/Disgruntled-Bomb-Java-Editi...
Such hacks will slowly stop working (without explicitly allowing it from the command line.)
In this example, it would throw an IllegalAccessException, because java.base doesn't open java.lang.
Re: JEP 401: Value Objects (Preview) merged to OpenJDK master
#104I feel lonely in that: I mostly love Java as a language. The lack of value types is the biggest impediment to certain types of performance. I am really looking forward to this evolution of the language.
java the language is amazing the problem with it is entirely cultural. why is `IStatusChangeEntityCreationManagerFactory` everywhere? and why are the frameworks so huge and all encompassing? i think batteries included rails-style frameworks are great, but when i wrote Java, it didn't feel like rails at all none of these are language problems
There's always this comment on every Java post. I expect the average HN member to be someone on the team who is either leading their projects or plays a significant role in driving the design of the software. You set the culture for your own projects. I've lead the development of some massive Java apps and all have had simple and clean architecture. I've never seen IStatusChangeEntityCreationManagerFactory or anything like it even once in any of my projects, but perhaps that's because the last time I used Spring was ~17 years ago. Most of my recent projects are using Quarkus, which is still a relatively large framework. But our codebase is designed in such a way that we're not tightly coupled to Quarkus.
I have seen a surge of overly complicated PRs now that we're in the AI era, but it's our job to be the gatekeeper and push back on this crud from entering the codebase. And that's likely true of any language.
Re: JEP 401: Value Objects (Preview) merged to OpenJDK master
#105I feel lonely in that: I mostly love Java as a language. The lack of value types is the biggest impediment to certain types of performance. I am really looking forward to this evolution of the language.
I've said this before but I'll say it again: The worst part of Java is Java programmers.
For most of my career, I thought I hated Java, primarily because every piece of Java code I had ever worked with was overly verbose across a million different files to do things that would take like ten lines of code in any other language.
Then I actually started looking at all the features for Java 8, 11, 17, and 21, and realized: NO! Java actually gives lots of really great tools and language features that allow you to write relatively pretty, terse, performant code. Record types help cut down on a lot of boilerplate stuff, the streams API allows for pretty work over lists, sealed interfaces mostly solve my itch for ADTs, virtual threads are genuinely pretty impressive bits of engineering, and for the stuff that isn't built in, Vert.x and Disruptor do a pretty good job filling in the gaps.
Once I learned all that, I was kind of mad at people still writing code like it was 1999, but also started to enjoy writing Java. It helps that by this time I was already senior and staff level, meaning I was given much more leeway in how code was written (so the poor junior engineers are stuck/blessed dealing with my code using all the shiny new features).
Re: JEP 401: Value Objects (Preview) merged to OpenJDK master
#106Previous HN discussion on project Valhalla: https://news.ycombinator.com/item?id=48595511
Re: JEP 401: Value Objects (Preview) merged to OpenJDK master
#107Earlier quoted context omitted.
What I love the most is the sheer amount of thought and philosophy put into Valhalla. It transcends the binary understanding of object vs value and actually defines 4 distinct buckets: 1: Classical Object 2: Object without identity 3: Atomic Value 4: Classical Value (Tearable) Each bucket has clearly defined performance characteristics and semantic constraints. So depending on the nature of your data, you can always…
this comment reads like a parent who can’t help but love their child unconditionally and uncritically. That’s a lot of complexity a lot of other languages don’t even need. It’s great Java designers have managed to shoe horn something in, but it’s all because of misdesigns 30ish years ago mispredicting of computer architecture.
Your comment makes no sense to me, but I must grant that there is a lot of bad reporting about Valhalla and I’ve been following the mailing lists for well over 7 years now.
Nothing, absolutely nothing about the design is a compromise that would detract from the project if it was for any other language.
You could judge them for bringing “complexity to an easy topic” but it really is far from that and the idea of a value type being a distinct dichotomy from an object is just a convenient tradition.
The push for immutability and value-ness has been going on for a long time and the motivation of the project was to bring performance benefits that align with semantic statements about the underlying data type. Which is of course a more nuanced take than “go value, go faster”.
Re: JEP 401: Value Objects (Preview) merged to OpenJDK master
#108Earlier quoted context omitted.
From what I gathered the core problem is flattenability. It is backed by a dynamic array and you would need real templating to remove the indirection.
They are researching to have immutable arrays. Also multifields (stack allocated arrays as fields in value classes). So, there is a possibility.
The problem is not that the array is mutable, but that the size of the array may differ for different strings. (In fact, it usually* does differ if the string length is different).
This makes it impossible to flatten - as the VM needs to know the total size when creating the memory layout for a class...
* (with a small exception: if the strings use different coders, one can be twice as long and the backing arrays would still have the same size)
Re: JEP 401: Value Objects (Preview) merged to OpenJDK master
#109Earlier quoted context omitted.
this comment reads like a parent who can’t help but love their child unconditionally and uncritically. That’s a lot of complexity a lot of other languages don’t even need. It’s great Java designers have managed to shoe horn something in, but it’s all because of misdesigns 30ish years ago mispredicting of computer architecture.
While I agree with the comment being overly-praise-y, this is complexity that any multithreaded language with mutability and reasonable sanity/safety desires (but without intrusive compile-time rules a la Rust) has; others just might pretend some of the options don't exist / aren't desirable. (..and value objects, as landed in the PR, doesn't yet have tearable objects)
I think it really highlights how important it was to have atomicity and integrity by default because even here people will handwave away any such concerns as if they don’t exist.
Re: JEP 401: Value Objects (Preview) merged to OpenJDK master
#110Earlier quoted context omitted.
You can opt out of atomicity and make your type tearable, achiving the same performance as on any other platform. This is the correct default as the vast majority of developers using value types will not be aware of tearability, being taught that "value types are safe for parallel programming" without knowing nuances.
Yeaaah. They are going to introduce approaches for the programmer to decide if tearability is allowed or not. Already there are internal annotations for fields and types to enable it that probably will become a language feature in future.
The Java way was always to let library designers decide how a type is used. I personally think this is the sensible one.