81–90 of 258 posts
Earlier quoted context omitted.
There's no real reason to use java for new development in 2021.
Err... Not defending Java, but does .NET support Linux at all?
No, seriously, we need the same thing for .NET
I’ve tried more than once to learn Java I find it very confusing. This website resolves one of the issues. The other issue I have is that most Java tutorials use IntelliJ, or some other IDE, which makes it difficult to figure out what a non IDE workflow actually looks like, some managing dependencies is confusing. I wonder if c# and mono is better in this respect
Java often uses IDE but there are tools to run a REPL. Groovy had this before Java got it. You can use it to write Java, since Java code is Groovy. It comes with a GUI console into which you can type and evaluate too, or you can write script files and run them. It's not as fashionable nowadays as it used to be (now it's Kotlin, Scala, etc.) but it works great and can be useful for learning Java too.
I’ve tried more than once to learn Java I find it very confusing. This website resolves one of the issues. The other issue I have is that most Java tutorials use IntelliJ, or some other IDE, which makes it difficult to figure out what a non IDE workflow actually looks like, some managing dependencies is confusing. I wonder if c# and mono is better in this respect
Earlier quoted context omitted.
There's no real reason to use java for new development in 2021.
Err... Not defending Java, but does .NET support Linux at all?
I've never heard of Adoptium Eclipse Temurin before. It looks like all releases were just within the last few months, but this is the recommendation? Seems a bit strange.
Earlier quoted context omitted.
There's no real reason to use java for new development in 2021.
Then use Kotlin, and take advantage of the jvm and the ecosystem, and avoid basically all the stuff you listed about the java language. "no real reason" is a stupid take. I could list multiple, but a big one is that there are hundred java developers for each dotnet developer in my city. The java env is well tested and well understood, if anything one should argue why not use it instead of a hip and trendy alternative…
In what way? It's slower and has less features than the .NET runtime.
> "no real reason" is a stupid take. I could list multiple, but a big one is that there are hundred java developers for each dotnet developer in my city. The java env is well tested and well understood, if anything one should argue why not use it instead of a hip and trendy alternative.
So, your only credible excuse for using java is inertia from boomers and middle managers refusing to adapt from the standard of the early and mid 2000s?
I'd like to see more of a rationale for not using Corretto on non-AWS servers. What's wrong with it?
The general guidance is always use the last LTS release unless there is a specific feature in the non LTS releases that you can’t wait for. So any new development should target 17 at this point. Unless you want serious long term pain then you shouldn’t be more than one LTS release behind. So if you are not running on JDK 11 or later you should be strongly thinking about upgrading.
My point is that migrating to new releases isn't always trivial, especially the more complicated and complex a project gets. If i knew that i'll run if compiled successfully, then it wouldn't be too bad, but with the amount of reflection, dynamic class loading etc. that frameworks like Spring favor, my workflow to date has been fixing a bug, building and running, something else breaking, fixing that bug, building and running, something else breaking, realizing that i cannot fix this because upgrades to the logic would be inherently "lossy" due to a mismatch of what the new framework versions provide, making it so that breakages that aren't covered by tests will also be created and so on ad infinitum.
Sometimes it makes me wonder why JDK 9 onward just didn't have a compatibility module: "Here, install this to have all of the old Java classes that were removed from the standard library after JDK 8 and retain that old functionality for software projects that would otherwise be stuck in development hell short of a full rewrite." Or something like that for Spring Boot, that lets you use web.xml instead of having to use hacks to load its contents and register all of the servlets, with half of them not working anyways, because some class names were changed along the way.
Software doesn't always age beautifully.
Furthermore, it feels like new runtime and package versions are made in ways that accidentally break backwards compatibility with no clear ways to avoid this.