Oh man, I feel old.
Java 17 / JDK 17: General Availability
201–210 of 251 posts
Re: Java 17 / JDK 17: General Availability
#202Earlier 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.
I find records super useful! You can not only express things like a Point(x, y) easily, but you can also wrap primitive types like integer to give values semantic, behavior and typesafety. Records are the perfect fit for value types as used for example in Domain-driven Design.
Re: Java 17 / JDK 17: General Availability
#203Earlier quoted context omitted.
There are some funny ways to work with records. I can recommend this article: https://benjiweber.co.uk/blog/2020/09/19/fun-with-java-recor...
Still way too much typing compared to lombok's @Value @With.
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/...
Re: Java 17 / JDK 17: General Availability
#204Earlier quoted context omitted.
There are some funny ways to work with records. I can recommend this article: https://benjiweber.co.uk/blog/2020/09/19/fun-with-java-recor...
Still way too much typing compared to lombok's @Value @With.
TBH both approaches are just poor design of the object model. The one from my link is a clever but inefficient way to manipulate records (reflection), the one with Lombok is creating redundant interfaces without business meaning. A record with few business methods is lean enough and ensures that only valid transitions can happen.
Re: Java 17 / JDK 17: General Availability
#205I would like to ask a question, in order to elicit the detailed and considerate comment that HN is known for. It's not intended to inflammatory in any way shape or form! I am not a Java developer. I am one of those users who has a bad memory of using Java desktop apps in ~2001 where they ate a ton of ram, seemed horrendously slow, and had example "Hello Worlds" that are reminiscent of Enterprise FizzBuzz [1]. At some…
> memory of using Java desktop apps in ~2001 where they ate a ton of ram, seemed horrendously slow,
Note that the horrible end user experience of running java programs (or java plug-ins in the browser) back in the day, never was indicative at all of how it's for running on servers and those kind of workloads. The stuff I've written in java for backends have been blazingly fast (compared to python for instance) and with much better tooling. So devs choose java/jvm because it works well, despite some shortcomings in some areas.
Btw, I think you'd find today's java desktop apps to be snappier than you'd think (especially compared to electron for instance). Bundling the jvm removes the hassle of having to install something separate and version issues. And AOT compilation and the new modularity of the stdlib makes the files smaller and quicker to load.
Re: Java 17 / JDK 17: General Availability
#206Earlier quoted context omitted.
For a while, there were some nitty, edge case, "UFO" types of differences between OpenJDK and the Oracle JDK. But that's mostly been resolved. Oracle owns "Java", that is the name, the trademark, etc. In that sense, OpenJDK is "not" "Java". But operationally, this is moot. But it has impact in other areas. What was originally "Java Enterprise Edition" was transferred over to the Eclipse Foundation, but they couldn't…
> All of the JEE packages were "javax.enterprise.". Oracle wouldn't give up the "Java" part in order to not dilute its trademark, so now its the "Jakarta Enterprise Edition", and all of the packages are being renamed to "jakarta.enterprise.". I mention this just as an example of the hoops the community going through, even today, over what's happening with java. That is quite a change, and probably not very backwards…
No, it's not at all. But, since that code needs to run in a formal container (app server) environment, the app server makers do classloader and renaming shenanigans to be able to load code from the earlier toolkits.
But, yea, it was a big clod to drop in the churn.
Re: Java 17 / JDK 17: General Availability
#207as a node dev, I see people using typescript with node. I wonder why don't those people just use java ? and let us clay potters shape plain js to our will. rather than pollute the node ecosystem with typescript
When you drop the pot, get a job and work with an entire team on a single project - you learn to appreciate the safety of types
yeah, types in js e.g flow are useful in quickly learning the codebase but end of day you end up fighting the tooling. instead of the tooling to help you. I prefer inferred types such as what F# or Elm have.
Re: Java 17 / JDK 17: General Availability
#208I haven't touched Java since 8 but I'm itching to get back in it. Any good overviews of Java since 8 and what was added?
https://advancedweb.hu/a-categorized-list-of-all-java-and-jv...
Only missing stuff from 17, but that's a short list.
Re: Java 17 / JDK 17: General Availability
#209Earlier quoted context omitted.
Still way too much typing compared to lombok's @Value @With.
TBH both approaches are just poor design of the object model. The one from my link is a clever but inefficient way to manipulate records (reflection), the one with Lombok is creating redundant interfaces without business meaning. A record with few business methods is lean enough and ensures that only valid transitions can happen.
Eh? This is pretty good:
Colour changed = colour.withRed(5);