Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

151–160 of 185 posts

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

#151

Post by DarkNova6 »

germandiago wrote: post #66
daviddoran wrote: post #61

Earlier quoted context omitted.

I used to love Java mostly for its batteries-included well designed standard library. Despite the verbosity of the language itself. But over time the language has really evolved a lot and gotten a lot more pleasing to the eye (in my opinion).

At some point I thought there was no way back compared to C#. But nowadays I see the language improved a lot, avoided async/await and added virtual threads, added records, now Valhalla, decent lambdas and tons of quality of life improvements. In the meantime C# became a monster of 2000 ways to declare properties init get, set, backed, not backed, stackalloc, structs, etc. And I know it is done for performance: but Ja…

[dead]

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

#152

Post by stickfigure »

dionian wrote: post #132
stickfigure wrote: post #130

Earlier quoted context omitted.

This is specifically Spring culture, not Java culture in general. I don't tend to see this outside of Spring. Maybe back in the J2EE days, but that community seems to be more or less dead. Java is a big tent. Yeah there are some parts that deserve this kind of mockery. The Rails equivalent is over-metaprogramming. "I solved it with method_missing." I've worked on code like this in real life. TBH I'd rather have the i…

I**Factory existed long before spring came around

I-prefixing interfaces is a practice from Microsoft's COM, and to this day still isn't part of Java culture, despite the efforts of subversive dotnet renegades.

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

#153

Post by paulddraper »

stickfigure wrote: post #130
merlindru wrote: post #39

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

This is specifically Spring culture, not Java culture in general. I don't tend to see this outside of Spring. Maybe back in the J2EE days, but that community seems to be more or less dead. Java is a big tent. Yeah there are some parts that deserve this kind of mockery. The Rails equivalent is over-metaprogramming. "I solved it with method_missing." I've worked on code like this in real life. TBH I'd rather have the i…

Yeah, Ruby code bases are generally harder to maintain than Java ones.

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

#154

Post by paulddraper »

stickfigure wrote: post #152
dionian wrote: post #132

Earlier quoted context omitted.

I**Factory existed long before spring came around

I-prefixing interfaces is a practice from Microsoft's COM, and to this day still isn't part of Java culture, despite the efforts of subversive dotnet renegades.

Yes, more common is

  Manager     // interface

  ManagerImpl // class

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

#155

Post by jameslars »

timmg wrote: post #15

I 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.

You are definitely not alone. I love Java and I will always defend it. Java's perception is tainted by baggage from decades ago.

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

#156

Post by nogridbag »

parallax_error wrote: post #24

Really cool, shame that strings can’t be fully indistinguishable like Integer despite their immutability

One misconception I had was that with value objects we could simply use `==` for comparison. But it looks like there's lots of gotchas with this especially if the value class has String fields for one or more fields. For example, comparing two ZonedDateTime value objects may be fine with == because I believe the JDK team ensured the Strings that represent the ZoneIds are always the same reference.

We have tons of wrapper classes in our codebase which seem ideal as value objects. For example, instead of passing around "String emailAddress", we have a wrapper class EmailAddress. While we can now make our EmailAddress class a value object, we cannot do "==". Unlike ZoneId in which there's a fixed set and you can intern all ZoneIds in the string pool, email addresses are unique and trying to intern all email addresses would be a bad idea. So it seems like using .equals is here to stay even for these types of basic classes.

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

#157

Post by inigyou »

inigyou wrote: post #88
ivolimmen wrote: post #41

Earlier quoted context omitted.

I personally would never compare the two. Someone said: java to JavaScript is like car to carpet. And I completely agree with that.

as ham is to hamster

as ant is to antidisestablishmentarianism

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

#158

Post by vlovich123 »

DarkNova6 wrote: post #107
vlovich123 wrote: post #93

Earlier 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.

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.

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

#159

Post by germandiago »

pron wrote: post #141
germandiago wrote: post #90

Earlier quoted context omitted.

It depends on how you look at it. C++ is very different since it is native. Java is a VM. This affects lots of decisions in weird ways. But in essence both commit to backwards stability at the end. C++ goes for performance, JVM for a more full-featured bytecode vm, etc. but still.

The JVM goes for performance, too, only with an emphasis on the performance of larger programs. It's designed to address some of the serious performance issues that large C++ programs tend to suffer from (I originally made the switch to Java because it was getting hard to keep the large C++ applications we were working on fast enough; Java does some optimisations that are hard for a C++ compiler).

Well, yes. True that for long-running apps JVM seems to be tuned.

I meant the kind of "perf-to-the-instruction" thst native can generate vs other considerations.

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

#160

Post by speed_spread »

vips7L wrote: post #147
speed_spread wrote: post #140

Earlier quoted context omitted.

That will not happen for backward compatibility reasons but a new build tool with a modern CLI would be nice. One that's declarative like Maven (without the XML) and doesn't require an upgrade for every new JDK version like Gradle (screw Gradle).

Maven 4 provides alternative build file syntax with extensions: https://github.com/maveniverse/mason

Is this better than the previous polyglot extension?
Post reply on HN