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

Java 17 / JDK 17: General Availability

mail.openjdk.java.net

Post reply on HN
Print view View original

231–240 of 251 posts

Re: Java 17 / JDK 17: General Availability

#231

Post by samus »

nlitened wrote: post #86
geophile wrote: post #18

Earlier quoted context omitted.

I think this statement has been true since about 2014. Structs are nice, as they allow for control over locality, to a degree that is simply not possible in Java currently. But there is a second effect, which is possibly more important: If I can move gigabytes of my data into arrays of structs, then 1) I greatly reduce memory requirements (far fewer pointers), and 2) I greatly reduce the amount of work that GC has to…

> If I can move gigabytes of my data into arrays of structs, then 1) I greatly reduce memory requirements (far fewer pointers), and 2) I greatly reduce the amount of work that GC has to do. As an aside, and not to say that Valhalla is not needed (I am looking forward to it very much, along with Loom), I’ve recently learned that for many use cases (not all) when you want gigabytes of struct arrays, a bunch of equal-si…

The semantics of primitive types should make it possible for the JVM to apply this optimization automatically. Maybe controlled via an annotation. But no clue whether it's on the roadmap.

Re: Java 17 / JDK 17: General Availability

#232

Post by carimura »

cstuder wrote: post #162
carimura wrote: post #72

Earlier quoted context omitted.

Thanks for the Dev.java mention. Our team is excited to launch the site. We focused on minimal design (similar to Inside.java) and heavy on content, mostly learning material to start. More to come soon. Feedback here is welcome!

The RSS-feed seems to be missing: https://dev.java/feed.xml (Linked in the footer.)

doh... no RSS feed yet, removed.

Re: Java 17 / JDK 17: General Availability

#233

Post by jamesfinlayson »

gigatexal wrote: post #183

The biggest hinderance to me adopting Java for anything meaningful was the build system. Too much XML and complexity. Maven for packages, ugh. Just give me a modern package manager. Does such a thing exist that is idiot proof?

Gradle lets you write your build config in Groovy or Kotlin. The possibility for complexity is there but I've found it mostly just works and is reasonably simple - for home projects my gradle.build files are typically 50 lines or so.

Re: Java 17 / JDK 17: General Availability

#234

Post by samus »

hashmash wrote: post #64
mabbo wrote: post #51

Earlier quoted context omitted.

> Language > Pattern Matching for instanceof (16) > Records (16) > Restore Always-Strict Floating-Point Semantics (17) > Sealed Classes (17) > Switch Expressions (14) > Text Blocks (15) This is what excites me. Records, switch expressions and sealed classes are all excellent and even better together. Along with pattern matching switch statements, Java is finally losing a lot of cruft people complain about.

I'm trying to find a good use case for records, but the best I can come up with is using it for composite hashmap keys. I suppose when combined with sealed classes and pattern matching features at some point it might be more useful, but what is the main use for records right now? Given that they're immutable and have no convenient way to be copied when modified, I find them quite tedious to use.

For example,

* tuples (complex numbers, points, dimensions, colors, IP addresses),

* database query results,

* stateless beans for DI frameworks where it cuts down on the verbosity of using constructor injection (actually a slight misuse)

* composite natural keys in database modeling

The immutability can help to enforce API contracts and proper service layering. A common problem in legacy code is modules communicating with each other by modifying objects that were passed as arguments.

Eventually, Project Valhalla will introduce the possibility to declare records as primitive, which will also reduce the overhead of Wither methods.

Edit: Building web APIs should also benefit from records because the argument and result types are only supposed to be created and read, not modified.

Re: Java 17 / JDK 17: General Availability

#235

Post by samus »

stickfigure wrote: post #212
BoyRobot777 wrote: post #203

Earlier quoted context omitted.

This will be solved[1]: record Point(int x, int y) {} Point p = new Point(1, 2); Point pp = p with { x = 3; } [1] https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

Interesting. It's ok. It seems like they're adding this syntax just to avoid extra copies eg, `p with {x = 3, y = 4}` instead of `p.withX(3).withY(4)`. I really don't mind the later. My gut feel is that records break encapsulation and will make refactoring slightly more difficult than the equivalent lombok value class. But if this gets more people making objects immutable, I'm all for it.

The perfect transparency of the underlying data is rather the whole point of records. Tempered by immutability, records should be a useful tool for modeling data where encapsulation is not required. Note that it is still possible to add methods that can perform computation on the underlying data.

Re: Java 17 / JDK 17: General Availability

#236

Post by samus »

geodel wrote: post #87
hashmash wrote: post #64

Earlier quoted context omitted.

I'm trying to find a good use case for records, but the best I can come up with is using it for composite hashmap keys. I suppose when combined with sealed classes and pattern matching features at some point it might be more useful, but what is the main use for records right now? Given that they're immutable and have no convenient way to be copied when modified, I find them quite tedious to use.

So one thing peculiar in Java is public records have to be in their own files. Now I wanted to treat records as less ceremonial than classes to organize code. I'd have liked to have a dozen or so records in a file along with some basic operations on them but it is not possible have multiple records without that many files. I know the answer is always use IDE and all but it causes more context switches than scrolling…

It's a core restriction of Java that there can only be one public class in each file. Nesting records inside a class would solve the issue. It's not that pretty though because only lower-casing the class name would create the illusion of it being a package.

Re: Java 17 / JDK 17: General Availability

#237

Post by samus »

cmckn wrote: post #160
pgwhalen wrote: post #126

Earlier quoted context omitted.

You won’t be stuck, you just need to add some command line flags when running your application, as a way of acknowledging these packages are breaking encapsulation.

“Some” as in dozens (for my apps, at least). It’s a solution, but not a great one. The projects I depend on will have to remove such usages eventually to avoid awful UX (and avoid punching holes in encapsulation).

For server application, this is a one-time administration effort. If you are concerned about `--illegal-access=allow`: yes, you should strive to get rid of it before security auditors blow an artery because of it.

Desktop applications are usually not delivered as bare JARs, but with wrapper binaries or scripts, where such flags are supposed to go.

Re: Java 17 / JDK 17: General Availability

#238

Post by metaltyphoon »

jsiepkes wrote: post #186
x0n wrote: post #164

Earlier quoted context omitted.

Catch up to what? The JDK 17 JEP list reads like a list of things that were added to dotnet years ago.

Thats kind of a hyperbole. .net didn't add support for macOS on ARM64 years ago. .net also didn't implement 2D rendering on macOS via Metal. etc. As a matter of fact .net didn't even support any other platform then Windows until recently.

Also hyperbole, dotnet supported other platforms years ago via mono.

Re: Java 17 / JDK 17: General Availability

#239

Post by pjmlp »

rnikander wrote: post #46

I'm guessing that Loom (lightweight threads) is not in this yet. It looked like a nicer way to handle "async" code, but I wonder about the implementation difficulty.

Basically if you look at the JEPs related with networking infrastructure from the last set of releases, they have been rebuilding the whole JVM to be Loom-able.

Naturally this will take several releases.

Re: Java 17 / JDK 17: General Availability

#240

Post by GreenToad »

cesarb wrote: post #97

I understand wanting to remove the overcomplicated Security Manager, but we have one use case which, as far as I can see, has not been mentioned at https://openjdk.java.net/jeps/411 : we install a custom security manager to prevent the software, when run on a developer machine, from accidentally connecting to non-localhost network addresses (we actually use a whitelist). I wonder how we'll do that after Java 17.

It looks like jep 418, when delivered, might be used for that.
Post reply on HN