| ▲ | treflop 7 days ago |
| Java has a great ecosystem. It’s well thought out and I can compile and run 10 year old projects no problem. In fact, I wish everyone had just copied Java’s model instead of inventing their own worse model. I love Python but it has a terrible package ecosystem with mediocre tooling that has only gotten worse with time. JavaScript has gotten better but it seems they are just re-learning things that were long figured out. When I see new package managers, I just see a list of problems that they forgot to account for. Which I find strange when there have been many package managers that you can learn from. Why are you re-inventing the wheel? |
|
| ▲ | demosthanos 7 days ago | parent | next [-] |
| In JetBrains's Developer Ecosystem 2023 survey, 50% of developers were still regularly working in Java 8 [0]—the exact kind of "stick with the old version of the runtime" solution described in TFA. [0] https://www.jetbrains.com/lp/devecosystem-2023/java/ |
| |
| ▲ | lucianbr 7 days ago | parent [-] | | Java 8 is 10 years old. If you had a project with a Java version that was recent 4 years ago (11 - 14), you could run it without any problems or changes. | | |
| ▲ | demosthanos 7 days ago | parent [-] | | Because they made the design choice to stop making large breaking changes to the language and tooling. Java 8 to 9 wasn't easier than Java 8 to 17 is, it's getting off of Java 8 that is hard because they made the choice to break so much in 9. Node does not promise indefinite backwards compatibility, which is a design choice that they've made that allows them to shed old baggage, the same way that the Java developers chose to shed baggage in 8->9. Neither choice is inherently better, but you do have to understand which choice a language's designers were making during the time window in question when you go to run it later. |
|
|
|
| ▲ | ahoka 7 days ago | parent | prev | next [-] |
| "Java has a great ecosystem. It’s well thought out and I can compile and run 10 year old projects no problem." We just had to workaround breaking changes in a patch version update of Spring Boot. Maybe it was true in 2005, but certainly not the case today. I know of products that are stuck in Java 1.8 and not because they are too lazy to upgrade. |
| |
| ▲ | cess11 7 days ago | parent [-] | | I've been involved in bringing real old Java 1.4 and 6 and whatnot up to 17 and from classic app servers into cloud, can take a bit of work but it's pretty straightforward, mostly switching out deprecated methods to their successors and copying over boilerplate config from similar applications. | | |
| ▲ | mleo 7 days ago | parent [-] | | Depends on the frameworks in use. I have done the same as you in bringing code that was originally started on 1.4 up to 17 and now 21 and it just took grunt work, but not too crazy since most of it was bog standard Java. However, some other projects around here using different application frameworks are stuck since the frameworks aren’t maintained or upgraded in ways that aren’t compatible anymore. Looking into old Java code, it is hard to remember a time before enums and what a pain that is to deal with int constants instead of typed constants. |
|
|
|
| ▲ | wink 7 days ago | parent | prev [-] |
| I am not sure you should put ant or maven as shining examples here, but I am kinda warming up to Gradle, at least without Groovy being involved. |
| |
