| ▲ | ivan_gammel 7 days ago |
| I still can open my decade-old Java projects, run build with modern Maven/JDK and get working code - in a few minutes. Two hours of dancing with a drum doesn’t feel acceptable to me. |
|
| ▲ | KronisLV 7 days ago | parent | next [-] |
| > I still can open my decade-old Java projects, run build with modern Maven/JDK and get working code - in a few minutes. Try any old Spring project, where anything newer than JDK 8 will be incompatible. The only saving grace is that JDK 8 is still available, but even it will eventually reach EOL. And then you look at JDK 11 projects and realize that they won't run on anything newer due to Lombok issues, so that's another thing to update and fix. I think the experience of code rot is universal and increases with the amount of dependencies you have. |
| |
| ▲ | mperham 7 days ago | parent | next [-] | | > I think the experience of code rot is universal and increases with the amount of dependencies you have. This is true but there's also a factor from the language/framework in use. Node is especially bad because of it generates huge package dependency trees. Go is especially good because of the large stdlib (which I use to minimize deps in https://github.com/contribsys/faktory) and excellent backwards compatibility. | | |
| ▲ | dilap 6 days ago | parent | next [-] | | Plus even if you were using lots of deps, the Go code would almost certainly keep working, thanks to minimal version selection and the Go module mirror. (And of course for maximum reliability, could even easily vendor deps with "go mod vendor".) | |
| ▲ | guappa 6 days ago | parent | prev [-] | | > Go is especially good because of the large stdlib Come on… compare it with what java and python have. | | |
| ▲ | blizdiddy 6 days ago | parent | next [-] | | Java can't even read/write json without third party libraries. Tell me a single thing that Oracle has added to the standard library. As far as I can tell, more and more of what was once standard is now getting offloaded and trademark-washed with the eclipse and apache foundations. | |
| ▲ | dartos 6 days ago | parent | prev [-] | | What does Java or Python have in their stdlib that go doesn’t? | | |
| ▲ | guappa 6 days ago | parent [-] | | Well python has syslog, mmap, just to name a couple of things. | | |
|
|
| |
| ▲ | nitwit005 6 days ago | parent | prev | next [-] | | Spring generates bytecode, and Lombok is a language extension. You're effectively writing code in another language that's very similar to Java. The company I work at has a ton of projects stuck on ancient spring versions and Java 8 (or Java 6 in one instance). They still insist on Spring despite being essentially unable to upgrade to a version newer than a decade old. | | |
| ▲ | KronisLV 6 days ago | parent [-] | | > Spring generates bytecode, and Lombok is a language extension. You're effectively writing code in another language that's very similar to Java. That's the reality of using the language in production projects. Same as how you're likely to see more than just Python or Node being used in projects that list them in the tech stack, because there's native dependencies and tooling used. |
| |
| ▲ | signal11 4 days ago | parent | prev [-] | | Old Spring versions < 6.1 are obsolete, so you do have to upgrade Spring in many scenarios as well. No security fixes for them unless you pay for support. |
|
|
| ▲ | andai 7 days ago | parent | prev | next [-] |
| I spent an hour or two figuring out how to even download Java, whether I need to give Oracle my home address, use a third party JDK etc. Then it turned out the standard built in GUI library I needed was no longer standard or built in. (I also used it ten years ago and it was a much better experience then.) |
| |
| ▲ | trinix912 6 days ago | parent | next [-] | | JavaFX? I’ve been there too, had to install it with maven and waste a few hours getting the maven xml just right for it to bundle the entire thing into a runnable jar (one that doesn’t require shipping extra files). Not the most convenient, but I get that they wanted to split it off the JDK release cycle. | |
| ▲ | sorokod 6 days ago | parent | prev | next [-] | | To save you time in the future: https://adoptium.net/en-GB/ Haven't used javaFX for a while but this is worth a shot https://openjfx.io | |
| ▲ | Suppafly 6 days ago | parent | prev | next [-] | | >I spent an hour or two figuring out how to even download Java, whether I need to give Oracle my home address, use a third party JDK etc. My son found a disk with some of my old java project from college 20 years ago and that's about what it took to run them, first figuring out how to even download java and then making some minor changes to get them running. I think we gave up trying to get the actual applet based ones to run. | | |
| ▲ | fian 4 days ago | parent | next [-] | | I know this is a late response, but for anyone curious you would need to use an official Oracle or Sun JDK/JRE from Java 8 or older. OpenJDK doesn't include support for applets. You also need a browser that has NPAPI. IE 11 was the most modern browser I am aware of that still supported applets. The old GUI framework mentioned in the GP might have been Swing. It is still included in most JDKs and allows for cross platform desktop GUI application development with no other dependencies outside the JDK. Finding documentation on how to do GUIs in Swing is getting increasingly difficult though. | | |
| ▲ | Suppafly 2 days ago | parent [-] | | IIRC Oracle makes it really hard to find the download. Admittedly we didn't spend more than an hour or two messing around with all of it and getting the applets to run wasn't a high priority or anything. |
| |
| ▲ | banku_brougham 4 days ago | parent | prev [-] | | applet. thats a name i havent heard in a very long time. |
| |
| ▲ | ivan_gammel 7 days ago | parent | prev [-] | | Well, I would spend probably similar time to get started on Pascal, which I used last time in the previous century. I would not blame Pascal for it though. |
|
|
| ▲ | demosthanos 7 days ago | parent | prev | next [-] |
| Maven, maybe, but Gradle absolutely not. If you don't have the exact version of Gradle that you used before, you're in for the same kind of misery documented above, with the same end state: just stick to the old version and deal with the upgrade later. |
| |
| ▲ | cypressious 6 days ago | parent | next [-] | | If you use the the Gradle wrapper, it will use the correct version and download it if necessary. If I'm not mistaken, that's the recommended approach. | |
| ▲ | ivan_gammel 7 days ago | parent | prev | next [-] | | Well, I‘m not talking about Gradle, right? Sometimes conservative choice is what gets the job done. | | |
| ▲ | demosthanos 7 days ago | parent | next [-] | | Right, I'm just clarifying for others who may not know the difference that Node doesn't have a monopoly on instability. There are a very small number of projects that specifically make it their goal to be backwards-compatible effectively indefinitely, and Maven is one of those. It's part of what people who hate it hate about it, but for others it's the main selling point. | |
| ▲ | lowboy 7 days ago | parent | prev [-] | | Well, the article is about npm, a package manager for node. Vendoring dependencies into source is a choice, albeit one that I don't often reach for. | | |
| ▲ | cesarb 7 days ago | parent [-] | | > Well, the article is about npm, a package manager for node. And Maven is a package manager for Java. The main difference IMO? The usual way to do things in Maven is to always use exact versions for the dependencies. When I specify I want some dependency at version 1.2.3, Maven will use version 1.2.3 of that dependency even if 1.2.4 or later already exists. | | |
| ▲ | lowboy 7 days ago | parent | next [-] | | Pinning to exact versions has been supported in npm for most, if not all of its life. That’s the usual way to do things in most teams working on app code I’ve been a part of (as opposed to library code where version ranges are preferable). | |
| ▲ | ivan_gammel 7 days ago | parent | prev [-] | | Maven is also stable and requires only JDK to run. You can unzip it to desired location and add to PATH - it will be ready to go in a couple of minutes. It will not build all old projects out of the box, of course. Specific versions of plugins may not be compatible with it or some dependencies may break on modern JDK. But chances of hitting this issue are much lower than in JS/NPM ecosystem. |
|
|
| |
| ▲ | trinix912 6 days ago | parent | prev [-] | | Might be an unpopular opinion but I like it that way. It means that I can pull an old Gradle version and the build should succeed. Unlike maven where I’ve been bitten by plugin xml syntax changes and such. |
|
|
| ▲ | jvanderbot 6 days ago | parent | prev | next [-] |
| `make` works pretty well on ... everything I've written that I kept since then. `cmake ..` otoh, tends not to. |
| |
| ▲ | jeroenhd 6 days ago | parent [-] | | `make` itself works fine, that hasn't changed in decades. That doesn't mean the tooling `make` scripts kick into gear still exist, or work, or do the same things, though. Makefiles don't fix the dependency on a fifteen year old C compiler. |
|
|
| ▲ | addicted 7 days ago | parent | prev [-] |
| If node saved you 8 seconds per working day over those 4 years, you’d still be ahead spending 2 more hours on that node project every 4 years. |
