I gave 2 talks at devoxx (BE and FR) about value types & JEP 401, and I appreciated your article. Thanks.
Though, you cannot flatten an array of points made of 2 int because of null flag, it would require 65 bits and atomicity is favored. We might see ways to give up on integrity for a specific use case (there were some @LooselyConsistent internal annotation but this is very experimental)
This seemed like an interesting subject, was really looking forward to reading this article. I can even look past the AI generated images. But it became pretty clear that the entire text was fed through an LLM or worse.
Stop. Please stop letting the LLM write for you. Nobody wants to read that.
Eh, I understand anti-AI sentiment but I hate the vibe of this kind of accusations, especially with more time consuming pieces.
My workflow is that texts are written in polish in markdown and then translated 😊 Doing that for years and I was always transparent with that. Long before LLM was here - originally DeepL.
Very interesting deep dive. About anti-AI vibe, I think this kind of very accurate article is what do me appreciate professional writers: every clause is accurate; I don't care if or how much LLM help the author: the final article is perfect, and the author name is a guarantee. Thank you very much
What still surprises me the most is that classes like Integer become value classes. This seems to me like an unusal level of breaking change for Java. Yes, like you say, any code that relies on the identity of such an object is probably ill-advised – but still, if it follows the contract it’s supposed to keep working the same way. I could imagine there being lots of code relying on this, or using an Integer to synchronize on, whether or not that’s a good idea. Since people do all kinds of crazy things.
How has this been discussed in the Valhalla team, do you know? Will there be some kind of migration process where you will get warnings for a few versions when relying on these things?
To my embarrassment, I wasn't sure if it is AI writing until section 5, where it became too obvious. Maybe the author did more work on the first part of the article.
I trust that the author has relevant expertise but fell into a trap "AI worded it much smoother than me".
To comment on the subject, I am looking forward to the full implementation of this project. Apart from the performance gains, this change will also make writing some common code patterns easier and less verbose, and probably unlock many future improvements, which is a nice bonus.
This is clearly an AI slop article. Embarrassing.
If you think so 🤷
Hello, just to balance the negative comments.
I gave 2 talks at devoxx (BE and FR) about value types & JEP 401, and I appreciated your article. Thanks.
Though, you cannot flatten an array of points made of 2 int because of null flag, it would require 65 bits and atomicity is favored. We might see ways to give up on integrity for a specific use case (there were some @LooselyConsistent internal annotation but this is very experimental)
This seemed like an interesting subject, was really looking forward to reading this article. I can even look past the AI generated images. But it became pretty clear that the entire text was fed through an LLM or worse.
Stop. Please stop letting the LLM write for you. Nobody wants to read that.
Eh, I understand anti-AI sentiment but I hate the vibe of this kind of accusations, especially with more time consuming pieces.
My workflow is that texts are written in polish in markdown and then translated 😊 Doing that for years and I was always transparent with that. Long before LLM was here - originally DeepL.
Very interesting deep dive. About anti-AI vibe, I think this kind of very accurate article is what do me appreciate professional writers: every clause is accurate; I don't care if or how much LLM help the author: the final article is perfect, and the author name is a guarantee. Thank you very much
Thank you for a nice article.
What still surprises me the most is that classes like Integer become value classes. This seems to me like an unusal level of breaking change for Java. Yes, like you say, any code that relies on the identity of such an object is probably ill-advised – but still, if it follows the contract it’s supposed to keep working the same way. I could imagine there being lots of code relying on this, or using an Integer to synchronize on, whether or not that’s a good idea. Since people do all kinds of crazy things.
How has this been discussed in the Valhalla team, do you know? Will there be some kind of migration process where you will get warnings for a few versions when relying on these things?
Jep 390
You get warnings since jdk 16 for such usages
Ah, very nice! Thanks, I had missed that!
To my embarrassment, I wasn't sure if it is AI writing until section 5, where it became too obvious. Maybe the author did more work on the first part of the article.
I trust that the author has relevant expertise but fell into a trap "AI worded it much smoother than me".
To comment on the subject, I am looking forward to the full implementation of this project. Apart from the performance gains, this change will also make writing some common code patterns easier and less verbose, and probably unlock many future improvements, which is a nice bonus.
Cześć Artur, gratuluję pojawienia się na pierwszej stronie hacker newsa należy Ci się!
Obserwuję Twoje poczynania od Vived i muszę przyznać, że robisz świetną robotę!
❤️❤️❤️❤️