Earlier quoted context omitted.
bad opinion is bad I get gradle is a disaster (but that's more of a poorly managed and evolved DSL problem) But ... does anyone use Spock and think "groovy sucks"? Yeah, I doubt it.
I hate to be "that guy" but ... raises hand . Spock is also a DSL disaster that's trying to be ScalaTest ( https://www.scalatest.org/user_guide/property_based_testing ) but in a dynamic language. Every time I use it I have to re-learn the syntax. (I have the same issue with Gradle, so maybe it's just-me?)
Java 22 Released
111–120 of 178 posts
Re: Java 22 Released
#112Maybe my favorite feature in this release: https://openjdk.org/jeps/463 Finally solves the inscrutable Hello World program! Yes, it's just ergonomics for early beginners. But could be the difference in whether or not someone new to programming sticks with Java or not.
I 1000% agree. Though, a favorite early programming memory of mine was when static methods finally clicked and I went back and looked at all that boilerplate that meant nothing to me and it all became crystal clear what it meant and why it had to be like that.
Re: Java 22 Released
#113Earlier quoted context omitted.
Java 8 allows access to unsafe methods, which despite being meant for internal JDK use only, have been widely used in external projects. Newer Java versions do not permit the use of unsafe except for the JDK itself. It wasn't ever part of the public API that's promised to never break, and JDK developers were annoyed that it being used meant Java got perceived as unstable, and it's gone in more recent versions.
I thought the issue was not Unsafe methods (which are only just now starting to be marked for removal) but rather various bytecode weaving libraries like javassist. As the JDKs progressively enforce bytecode verification more strictly these libraries sometimes run afoul of the new restrictions. (I speak from a little experience here, managed a somewhat involved upgrade path from 7 to 8 way back in the day which had t…
Re: Java 22 Released
#114Earlier quoted context omitted.
There were already "user-mode" implementations of asynchronicity on the JVM for years (like Monix, cats-effect, Pekko (fka Akka), etc). Loom has a worse API, is hidden from the user (what's preemptible and what will cause OS thread starvation? who knows!), and effectively ends up infecting the whole JVM with its complexity. Go shares most of those downsides, but as a greenfield project (..heh) there's at least the ex…
If you consider Go to be "dead on arrival", I don't know what world you're living in.
Re: Java 22 Released
#115Earlier quoted context omitted.
I'm really happy they are reconsidering the syntax. Thanks for the link
It sound like they're only reconsidering the prefix, not the backslashes, or am I misreading it? So we're not getting "hello $name" but rather than STR."hello \{name}" they're now considering $"hello \{name}" .
Re: Java 22 Released
#116Earlier quoted context omitted.
I hate to be "that guy" but ... raises hand . Spock is also a DSL disaster that's trying to be ScalaTest ( https://www.scalatest.org/user_guide/property_based_testing ) but in a dynamic language. Every time I use it I have to re-learn the syntax. (I have the same issue with Gradle, so maybe it's just-me?)
My problem with gradle is I never use it enough to get familiar with it, once the problem is solved I promptly forget everything.
A "DSL" like SQL that you use hundreds of times a year you'll learn the model of.
A DSL like groovy that you use once for project setup (and for that you'll one-off it likely and stackoverflow the rest of the question) is not. And it isn't really natural, it's a bunch of arcane steps that at the end might superficially look a bit consistent, but still really isn't.
Groovy really needs an autocompleter or a generator. Or, well, as you say, you stackoverflow for everything outside the very vanilla basics of it.
But good luck getting the right version match to the syntax you need. Christ.
Re: Java 22 Released
#117Earlier quoted context omitted.
- String interpolation - triple-quote strings / blocks - minimal class boilerplate (this posting) - closures (Java closures are worse IMO) - usable hashbang for UNIX - I think java has strings in switch now, don't they? Do they have expressions? WAIT, does Java STILL force you to write getter/setters?
But Java has all those features...?
Java has the nullsafe operator now and the elvis too, doesn't it?
I don't use the spaceship operator much, implicit sorting works pretty well.
Groovy's closures have a lot less GOTCHAs. They simply work as expected, at least to me. Half the time I use java closures and I get complaints in compilation that I don't get in Groovy, but maybe they've improved closures more.
Groovy's GPars library is the bomb for concurrency/parallelism. I don't know if I could function in normal java constructs.
The .with keyword is a sneaky useful technique where you can declare a piece of data like:
"some cli command" .with { it.execute} .with { /* parse output */ }
It allows chained calls that flow naturally. Groovy generally allows pretty compact flowed calls which makes scripts a lot easier.
Groovy scripting with implicit vars is a lot easier than any java scripting, even with the "simplification" described.
The shorthand access/navigation of nested lists and maps, and the map / list literals (also taken by java at some point I think) are really nice to have. Also a + operator for lists and maps I use a lot
Groovy's ability to generically call methods without mucking through 10 lines of reflection is sometimes nice.
The auto-gen of getter/setters is a must have, I think Kotlin has those too?
CompileStatic lets me selectively use full java speed without groovy overhead.
In general, I like Groovy because it is typing-optional. Python and Javascript suck because they don't really have optional type enforcement. Java sometimes asks for too much typing. Groovy lets me select as needed.
The actual sane = for string assignment and == for sane string comparison is nice.
But honestly, Java with the listed features is a lot better. I'll probably still use groovy for doing what would normally done with bash (UGH) since I have a big CLI/scripting library base that handles argument parsing, json, encode/decode, encrypt/decrypt, zip/unzip, in nice compact syntax.
Groovy is basically a dead language now anyway. The world is overrun by JavaScript and Python, and AI looms to replace us all with horrid AI python or javascript glue code.
Re: Java 22 Released
#118Earlier quoted context omitted.
I see Manifold as a huge leap past previous tools Immutables or Lombok. I understand there's a use case where you want to add these language features to an existing code base. But for the most part if you want the language features on the JVM, you should probably just use Scala. That gives you a set of established patterns, best practices, libraries, and a community of users. If you want type safe SQL in particular,…
> just use Scala Scala is a dying language, anyone boarding that ship is making a mistake. Anyhow, I prefer Java supplemented with powerful features Scala doesn't have, such as type-safe SQL. > If you want type safe SQL in particular, you can pry JOOQ out of my cold dead hands. Jooq isn't bad, but it's not SQL, it's Java trying to be SQL. Manifold lets you write type-safe, native _SQL_ of any complexity directly in y…
Especially that you call it a dying language, when it just got reborn, and better than ever with Scala 3.
Re: Java 22 Released
#119Maybe my favorite feature in this release: https://openjdk.org/jeps/463 Finally solves the inscrutable Hello World program! Yes, it's just ergonomics for early beginners. But could be the difference in whether or not someone new to programming sticks with Java or not.
Maybe in another ten years they'll remove System.out.println and allow for a simple println to be used. Or maybe we'll all move to Kotlin by then.
Re: Java 22 Released
#120Earlier quoted context omitted.
> 8 reached EOL in the last year or two Java 8 is still under Extended Support until 2030 (and indefinite sustaining support). Java 11 left Premier Support September 2023. "Java SE 8 has gone through the End of Public Updates process for legacy releases. Oracle will continue to provide free public updates and auto updates of Java SE 8 indefinitely for Personal, Development and other Users via java.com". https://www.o…
Oh that’s right. My company didn’t want to pay the insane Oracle fees to keep getting support. I think it wasn’t even a discussion once the saw the number, but that’s basically a rumor. So we have to stick to OpenJDK which means 8 doesn’t receive security updates and is untenable.
Just for note, JDK 8 came from the same time as Windows XP. Sure, the attack surface is different, but if they have no plans on moving forward and doesn’t even want to pay for support, then frankly fck them. Then they just surprise pikachu when a bunch of their user data leaks.