Live data from Hacker News

Java 17 / JDK 17: General Availability

mail.openjdk.java.net

181–190 of 251 posts

Re: Java 17 / JDK 17: General Availability

#182

Earlier quoted context omitted.

Interesting but the "Isn't this just multiple return?" section seems to completely miss the point. I don't see any examples of what multiple-return would look like. And multiple-return is what I want. At first glance, it looks like this (sure, more powerful) pattern matching system is not going to satisfy my desire for a compact syntax that lets me do the equivalent of this typescript: const [foo, bar] = getMeTwoThin…

No, there is no tuple support yet in Java. That would require something like variadic generics or a special compile time syntax sugar for tuples as the sole use of variadic generics. With the pattern matching the best you are going to get is nasty boiler plate like var returnedTuple = getMeTwoThings(); if (returnedTuple instanceof MyTupleType(Foo foo, Bar bar)) { // Do something with foo and bar } else { // Not reach…

I think there is ongoing discussion to support

      var MyTupleType(Foo foo, Bar bar) = getMeTwoThings();
which IIRC may be even simplified to

      var MyTupleType(foo, bar) = getMeTwoThings();
EDIT: found it https://mail.openjdk.java.net/pipermail/amber-spec-experts/2...

     let Point(var x, var y) = aPoint

Re: Java 17 / JDK 17: General Availability

#184

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.

I would use records a lot more (pretty much everywhere) if I could easily derive new values from existing ones.

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

Re: Java 17 / JDK 17: General Availability

#185
post #117

Lately I have insight similar to 'what hardware improvements give, software bloat take it away', 'what JDK platforms give third party Java frameworks take it away. I have this misfortune of dealing daily with a nasty Java framework which converts compile time errors into runtime errors, single error trace with multiple stack traces , most of them being from framework itself. One thing that might improve situation is…

Dagger 2 is a fantastic lightweight DI framework that gets out of your way and keeps the errors to compile-time

https://github.com/google/dagger

After that you can throw in whatever libraries you want, dagger doesn't care.

Re: Java 17 / JDK 17: General Availability

#186
post #164
post #157

Earlier quoted context omitted.

And now it is the other way around. C# burning through the versions to catch up the versions (and not so much the content). PS: had to edit, was really just a note about the numbers not the content of the versions!!!

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.

Re: Java 17 / JDK 17: General Availability

#187
post #177

Earlier quoted context omitted.

C# has never had to play catch-up with Java, it's always been the other way around.

Ohhh.... C# was invented as a response to Java... So it had to play catch-up with Java - at it's inception...

Even worse: C# came as a response when Microsoft failed to apply their embrace, extend, extinguish tactic on Java like they did with Netscape[1].

In the end the case was settled out of court and MS agreed to pay more then 1 billion dollar to Sun. MS also agreed to license a whole slew of patents for use with .net.

[1] https://www.pinsentmasons.com/out-law/news/sun-sues-microsof...

Re: Java 17 / JDK 17: General Availability

#188
post #117

Lately I have insight similar to 'what hardware improvements give, software bloat take it away', 'what JDK platforms give third party Java frameworks take it away. I have this misfortune of dealing daily with a nasty Java framework which converts compile time errors into runtime errors, single error trace with multiple stack traces , most of them being from framework itself. One thing that might improve situation is…

There are plenty of frameworks. Check out Helidon, Quarkus, Micronaut as examples of modern frameworks. You might like them. They’re not bound to servlet API.

I should have clarified one unfortunate part of this is enterprise diktat. So I stand no chance when a snake oil salesman from VMWare tells CIO on which framework they provide support for.

Re: Java 17 / JDK 17: General Availability

#189

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?

Maven is the idiot proof one. Gradle doesn't have XML, but it's extremely easy to make your build scripts unmaintainable.

Re: Java 17 / JDK 17: General Availability

#190
post #140

as 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

Typescript has about as much to do with java as javascript. The similarities are at best superficial.
Post reply on HN