3 ms·

Not knowing what's going on in Java is a personal problem. The language and jvm have its own quirks but it's no less knowable than any other compiler optimized

by jayd16 7mo ago

Not knowing what's going on in Java is a personal problem. The language and jvm have its own quirks but it's no less knowable than any other compiler optimized code. The debugging and introspection tooling in Java is also best in class so I would say it's one of the more understandable run times. Gradle does suck and maven is ok but a bit ugly.

dionian 7mo ago
LLMs take the whole argument away. Yes, maven/gradle/sbt suck to work with. But now you can just generate it.
- dionian 7mo ago
  I've been using maven for 20+ years, gradle for 10? ant for 5 before that. sbt for 15. I've written custom plugins for all of them. I know them quite well, unfortunately. I use LLMs to maintain them now. I keep the build files simple. It was an inconvenience before, but a trifle now.
- computerdork 7mo ago
  Actually, I like Maven. It's perfect for code that is broken into medium-sized projects, which makes it great for service-oriented architectures (would have said microservices here instead, but think we're learning that breaking our services too finely down is generally not a good idea). Yeah, it seems like Maven is designed to build just one project with relatively little build-code (although, figuring out versioning of the libs used in your build can get tricky, but guessing this is how it is in most languages). It's still one of my favorites build tools for many situations.
- spopejoy 7mo ago
  LOL I wish. LLMs massacre gradle code all the time. Once you're past boilerplate generation and doing anything remotely unusual they can't stop hallucinating broken shit that they insist works.
ActorNightly 7mo ago
Lets look at Java in modern day. * Most mature Java project has moved to Kotlin. * The standard build system uses gradle, which is either groovy or kotlin, which gets compiled to java which then compiles java. * Log4shell, amongst other vulnerabilities. * Super slow to adopt features like async execution * Standard repo usage is terrible. There is no point in using Java anymore. I don't agree that Rust is a replacement, but between Python, Node, and C/C++ extensions to those, you can do everything you need.
- gf000 7mo ago
  > Most mature Java project has moved to Kotlin. Demonstrably false, not even close Re Gradle using groovy/kotlin: so what? Gradle is not a standard any more than Maven, and java is not primary used as a scripting language, so it makes sense that it has a different language for its config files? What's the deal here? Show me a language without vulnerabilities. It has virtual threads for quite some times and it is a much much better choice for most use cases than async.
  - ActorNightly 7mo ago
    >Demonstrably false, not even close Are you arguing that the Android Ecosystem uses Java? Because it most certainly moved to Kotlin, and will soon move even off of that. >Show me a language without vulnerabilities. There is a scale of vulnerability severeness in terms of severity and how the vulnerability was introduced. Most every language has libraries with bugs that can create vulnerability. Log4shell wasn't a bug - it was introduced intentionally without anyone at Apache looking at it and thinking that it was wrong, knowing that log4j is the most widely used logging library for java.
    - gf000 7mo ago
      > Are you arguing that the Android Ecosystem uses Java Now you are just arguing in bad faith. Who talks about Android, which historically lagged a decade behind OpenJDK and not particularly good at being up to date even today, so people moved to kotlin vs java without goddamn lambdas? Is that your argument? Especially that it's a tiny segment compared to the vastness of web backends. Are Google's, apple's, alibaba's backends, amazon cloud etc insignificant in your mind? And you may want to browse the list of vulnerabilities, there are plenty interesting ones.
computerdork 7mo ago
Actually, really like maven, it's focus on building in standard way is fantastic (but agreed, it look messy, with all its xml and necessary versioning).

by jayd16 7mo ago

dionian 7mo ago

LLMs take the whole argument away. Yes, maven/gradle/sbt suck to work with. But now you can just generate it.

dionian 7mo ago
I've been using maven for 20+ years, gradle for 10? ant for 5 before that. sbt for 15. I've written custom plugins for all of them. I know them quite well, unfortunately. I use LLMs to maintain them now. I keep the build files simple. It was an inconvenience before, but a trifle now.
computerdork 7mo ago
Actually, I like Maven. It's perfect for code that is broken into medium-sized projects, which makes it great for service-oriented architectures (would have said microservices here instead, but think we're learning that breaking our services too finely down is generally not a good idea). Yeah, it seems like Maven is designed to build just one project with relatively little build-code (although, figuring out versioning of the libs used in your build can get tricky, but guessing this is how it is in most languages). It's still one of my favorites build tools for many situations.
spopejoy 7mo ago
LOL I wish. LLMs massacre gradle code all the time. Once you're past boilerplate generation and doing anything remotely unusual they can't stop hallucinating broken shit that they insist works.

ActorNightly 7mo ago

Lets look at Java in modern day. * Most mature Java project has moved to Kotlin. * The standard build system uses gradle, which is either groovy or kotlin, which gets compiled to java which then compiles java. * Log4shell, amongst other vulnerabilities. * Super slow to adopt features like async execution * Standard repo usage is terrible. There is no point in using Java anymore. I don't agree that Rust is a replacement, but between Python, Node, and C/C++ extensions to those, you can do everything you need.

gf000 7mo ago
> Most mature Java project has moved to Kotlin. Demonstrably false, not even close Re Gradle using groovy/kotlin: so what? Gradle is not a standard any more than Maven, and java is not primary used as a scripting language, so it makes sense that it has a different language for its config files? What's the deal here? Show me a language without vulnerabilities. It has virtual threads for quite some times and it is a much much better choice for most use cases than async.
- ActorNightly 7mo ago
  >Demonstrably false, not even close Are you arguing that the Android Ecosystem uses Java? Because it most certainly moved to Kotlin, and will soon move even off of that. >Show me a language without vulnerabilities. There is a scale of vulnerability severeness in terms of severity and how the vulnerability was introduced. Most every language has libraries with bugs that can create vulnerability. Log4shell wasn't a bug - it was introduced intentionally without anyone at Apache looking at it and thinking that it was wrong, knowing that log4j is the most widely used logging library for java.
  - gf000 7mo ago
    > Are you arguing that the Android Ecosystem uses Java Now you are just arguing in bad faith. Who talks about Android, which historically lagged a decade behind OpenJDK and not particularly good at being up to date even today, so people moved to kotlin vs java without goddamn lambdas? Is that your argument? Especially that it's a tiny segment compared to the vastness of web backends. Are Google's, apple's, alibaba's backends, amazon cloud etc insignificant in your mind? And you may want to browse the list of vulnerabilities, there are plenty interesting ones.

computerdork 7mo ago

Actually, really like maven, it's focus on building in standard way is fantastic (but agreed, it look messy, with all its xml and necessary versioning).