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

Java 16

jdk.java.net

Post reply on HN
Print view View original

241–250 of 327 posts

Re: Java 16

#241

Post by ragnese »

kaba0 wrote: post #232
ragnese wrote: post #201

Earlier quoted context omitted.

"Data" is such an overloaded and vague term, anyway. Almost all classes have "data", so what the heck is a "data class"? Is it one that only has data (not behavior)? Nope- these can have arbitrary methods. So, I'm kind of glad they didn't use it. (But, to clarify, I really don't care what color the bike shed is) I'm more wondering why they didn't go with "struct" or "value class", especially because the latter is exa…

Because while in the end project valhalla will not call them value classes, it is a sort of an overloaded term. Structs/value types can be mutable, records are not. They are basically tuples with names. And as far as I know, while records have a sane default equals defined, they are still identity objects in that they are passed by reference.

> Structs/value types can be mutable, records are not.

Fair point about record fields not being reassignable (not the same as immutable for others reading this).

> And as far as I know, while records have a sane default equals defined, they are still identity objects in that they are passed by reference.

Well, sure. All non-primitives are passed by reference. That doesn't stop them from being referred to as value types.

But in light of your first point, I agree that choosing a totally new term probably makes sense.

Re: Java 16

#242

Post by avodonosov »

papercrane wrote: post #204
avodonosov wrote: post #187

Earlier quoted context omitted.

Even if `record` is a syntactic sugar, I'd better see a canonical constructor added to all usual classes. The constructor parameters are of types of all the fields, in the declaration order. In this case we could say class Point { public final int x, y; } instead of record Point(int x, int y) { } Usual non-record classes would benefit greatly from such a feature too. Actually, if class fields have different visibilit…

Adding a new canonical constructor to all classes would very likely have backwards compatibility issues, so we'd likely need some sort of opt-in mechanism. In the end the language designers decided that they wanted to give developers a way to create a very focused kind of object. This goes into the design motivations: https://cr.openjdk.java.net/~briangoetz/amber/datum.html Additionally, one less talked about benefit…

The opt-in (or rather opt-out) could be a presence of user-defined constructor.

The same way as with default no-arg constructor.

Interesting note about serialization. That could also be part of the base class.

Re: Java 16

#243

Post by hota_mazi »

kllrnohj wrote: post #215
hota_mazi wrote: post #208

Earlier quoted context omitted.

Who cares about Maven-the-app, we are talking about the portability of the JVM bytecode. There are gigs of JVM bytecodes stored on Maven Central and these bytecodes are being downloaded and run on macOS, Windows, Linux, and Android on a daily basis without a single change. The very same libraries. Unchanged. That's the very definition of portability. I don't understand why you keep shifting topics by bringing up irre…

There's no portability requirement to being on Maven Central. Maven Central regularly hosts non-portable bytecode - like every AndroidX library. And, again, none of those libraries run on Windows, Android, iOS, and web - the 4 major platforms by market share. At best you get half of those, but typically you don't even get that, and that's still only libraries . None of them are portable applications. It's trivial to…

Now you're being intentionally obtuse and moving the goal posts from your original claims just to score points.

You're not arguing in good faith.

Feel free to stick with your invalid views on portability, the rest of us JVM developers will keep enjoying the portability that this wonderful technology provides us.

Re: Java 16

#244

Post by kccqzy »

Erlangen wrote: post #14
java-man wrote: post #3

Why they decided to change the keyword rules to use "non-sealed" is beyond me. Surely, there might be other choices? Closed/unclosed? Unsealed?

It's the same story in C++, co_await, co_yield. The sole purpose is not to break other people's code.

C++ has had two-word keywords since the beginning, static_cast, dynamic_cast, etc.

What I truly don't like is C's propensity to add new keywords that begin with an underscore and an uppercase letter. Like _Bool, or _Atomic. (I know the rationale, these can't be used as identifiers due to UB, but it still looks weird to me.)

Re: Java 16

#245

Post by croo »

meddlepal wrote: post #44
Freak_NL wrote: post #38

Earlier quoted context omitted.

Java 8 → Java 11 → Java 17. Those are the LTS releases. If you want to follow a release cadence similar to Java 5 → Java 6 → Java 7 → Java 8, that's what you'll track. The intermediate releases can be used to test against, but adopting them too soon often means tackling lots of issues in your dependencies. And updating your application servers to a new major Java version every six months is not something you can do e…

If you're doing green field JVM developer and NOT using big frameworks like Spring or an app server it is pretty safe to use the intermediate releases.

Uh, probably just my narrow corporate world view but... is there any serious development in java NOT using Spring?

Time for me to learn so let me rephrase this question! Those who use java without EE or Spring framework, what are your go-to libraries? What are you using for DI / REST / ORM / Auth etc?

Re: Java 16

#246

Post by ptx »

hota_mazi wrote: post #208
kllrnohj wrote: post #203

Earlier quoted context omitted.

When you build Android you're not building it on Android, you're building it on Windows, MacOS, or Linux. Maven itself is not being run on Android or iOS. The Java code that powers Maven isn't portable. The AndroidX code hosted on Maven that everyone is pulling down for Android isn't portable, either. Your claim would be like saying that PHP is portable because every platform has a web browser that can talk to the se…

Who cares about Maven-the-app, we are talking about the portability of the JVM bytecode. There are gigs of JVM bytecodes stored on Maven Central and these bytecodes are being downloaded and run on macOS, Windows, Linux, and Android on a daily basis without a single change. The very same libraries. Unchanged. That's the very definition of portability. I don't understand why you keep shifting topics by bringing up irre…

Any libraries in the Maven repos that rely on JNI have to include platform-specific native libraries for each platform. For example, anything that uses Unix-domain sockets, which weren't supported in Java until this very release.

Re: Java 16

#247

Post by LordDragonfang »

cmckn wrote: post #196
victor106 wrote: post #120

Earlier quoted context omitted.

I used Java a lot and like some aspects. But I think C# is way ahead in some important ways and Java is playing catch-up

Not considering async/await (because I'm not really a fan), they're neck-and-neck in my opinion. I don't think C# has been as careful with its abstractions and the general aesthetic of the language to the degree that Java has; but in many cases you can almost compile a block of Java as C# and vice versa. I think the primary differentiator is what toolchain/ecosystem you prefer, and I'm solidly on the Java side of tha…

>I don't think C# has been as careful with its abstractions and the general aesthetic of the language to the degree that Java has

You say "careful", others would say "stubborn". The refusal to add things like operator overloading lead to a much less aesthetically pleasing language to read and write.

Re: Java 16

#248

Post by BoyRobot777 »

ragnese wrote: post #238
kaba0 wrote: post #233

Earlier quoted context omitted.

But I fear kotlin will fall in-between all the platforms they try to support, and will end up comparatively bad on all. Like, you can’t really target both your coroutines on each platform as well as project loom properly, same with project Valhalla and the like.

Why can't coroutines take full advantage of Loom's green threads on JVM and do other stuff on Native/JS/whatever? I generally agree that being multiplatform is a lofty goal. And as much as I like Kotlin, it clearly inherits some of Java's (IMO) deficiencies. I'm not sure why I'd want those deficiencies exported to my native code when I could use lots of other nice languages.

I think Loom can be abstracted away by Kotlin quite easily. Valhalla on the other hand won't work at all. You won't be able to have inline classes in android/older Java versions. Even more - specialized generics.

Re: Java 16

#249

Post by stevetodd »

jjjeii3 wrote: post #94

Java devs are like: Why bother to develop anything new if we can just copycat every single feature from C# without even changing their spec a bit... C# records released last year: record Book(string Title, int Id); New java records: record Book(String title, int id)

By being slightly behind, you get to learn from those languages that live on the bleeding edge. The laggards get to benefit from all the corner cases found and mistakes committed.

Re: Java 16

#250

Post by [deleted] »

croo wrote: post #245
meddlepal wrote: post #44

Earlier quoted context omitted.

If you're doing green field JVM developer and NOT using big frameworks like Spring or an app server it is pretty safe to use the intermediate releases.

Uh, probably just my narrow corporate world view but... is there any serious development in java NOT using Spring? Time for me to learn so let me rephrase this question! Those who use java without EE or Spring framework, what are your go-to libraries? What are you using for DI / REST / ORM / Auth etc?

[deleted]
Post reply on HN