Live data from Hacker News

JEP 401: Value Objects (Preview) merged to OpenJDK master

github.com

161–170 of 185 posts

Re: JEP 401: Value Objects (Preview) merged to OpenJDK master

#161
post #91
post #73

Earlier quoted context omitted.

Yeah - it's a bit non-intuitive you can change the value of a number. https://thedailywtf.com/articles/Disgruntled-Bomb-Java-Editi...

In Python 2 you could literally do True = False and of course in JavaScript undefined = "a string"

The terrifying part of this in Java, is that it applies program-wide, including to constants set before you changed the value

Re: JEP 401: Value Objects (Preview) merged to OpenJDK master

#162

Earlier quoted context omitted.

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

Classical object, object without identity, atomic value, and classical value are not simplifications that you’d want in other languages. Rust, Haskell, Python - none of them need or would benefit from any of this.

Because?

Re: JEP 401: Value Objects (Preview) merged to OpenJDK master

#163
post #55

Earlier quoted context omitted.

IMHO, the main reason why Spring is huge is because it has grown organically to encompass many of the business cases/issues that one may encounter in both depth and breadth. So the http framework supports almost everything you may ever need and there is integration with every database, middleware, infra like kubernetes. (One can debate about the quality of all the lesser used modules but the main modules are pretty o…

> or we needed integration with an unsupported database How difficult is/was it to add a custom integration?

Just adding the bare bones integration wasn’t that hard. The trick comes from ensuring all the observability is wired correctly, that it fits in the framework usage, works good with graalvm, and other “non-functionals”.

At this point the work is typically more than you want a single team to maintain. Unfortunately, in many large enterprises it is just easier and more efficient to grab a bigger framework than trying to organise sharing the custom integration in the organisation.

Re: JEP 401: Value Objects (Preview) merged to OpenJDK master

#164

Earlier quoted context omitted.

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

Show me where IStatusChangeEntityCreationManagerFactory is in the language. Or the standard libraries. Or anything like it

it's not, that's my point

Re: JEP 401: Value Objects (Preview) merged to OpenJDK master

#167

Earlier quoted context omitted.

Today it is a great language with a runtime that is unequaled. For heavy duty business backend server load, it is the standard choice, and rightfully so. Do I love Spring? No. Do I prefer Typescript for my little side projects? Yes.

Fortunately, there are plenty of mature alternatives to Spring these days.

What are those alternatives? I haven't touched Java for web development for a very very long time.

Re: JEP 401: Value Objects (Preview) merged to OpenJDK master

#168
post #166
post #165

Earlier quoted context omitted.

> Or anything like it

Spring isn’t the language or standard libraries.

Ok, it's possible that my bilingual ahh is misunderstanding the comment. Maybe we can try to come to an understanding?

I read that comment as "Show me where [long classnames] are in the language, standard library or ."

Spring is one of the biggest java libraries and quite widely used. I think it fits rather nicely, even if the example itself is fairly old.

Re: JEP 401: Value Objects (Preview) merged to OpenJDK master

#169
post #168
post #166

Earlier quoted context omitted.

Spring isn’t the language or standard libraries.

Ok, it's possible that my bilingual ahh is misunderstanding the comment. Maybe we can try to come to an understanding? I read that comment as "Show me where [long classnames] are in the language, standard library or ." Spring is one of the biggest java libraries and quite widely used. I think it fits rather nicely, even if the example itself is fairly old.

Yeah I just think you have a fundamental misunderstanding of what the ecosystem is. Spring is used less than you think.

Re: JEP 401: Value Objects (Preview) merged to OpenJDK master

#170
post #69
post #29

Earlier quoted context omitted.

Not for atomic writes, which is the important bit here. When dealing with concurrency the choice to make us will you allow tears when writing i.e. thread A writes aa and thread B writes bb. Will you allow the option of seeing ab or ba or only aa/bb. This is the thing that costs performance. Plus do you allow null which makes it harder too.

That being said, x86_64 has supported 128-bit atomic writes via cmpxchg16b for over a decade. Modern 64-bit ARM has several ways to do them as well. Probably still not widespread enough for OpenJDK to unconditionally assume it's supported, but I think we're getting there. (Is there "caniuse" for CPU features?)

cmpxchg16b can only handle 64bits data correctly because of ABA problem.
Post reply on HN