5 ms·

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

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.

demosthanos 2y ago
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.
- ivan_gammel 2y ago
  Well, I‘m not talking about Gradle, right? Sometimes conservative choice is what gets the job done.
  - demosthanos 2y ago
    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 2y ago
    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 2y ago
      > 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.
      - ivan_gammel 2y ago
        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.
      - lowboy 2y ago
        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).
- trinix912 2y ago
  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.
- cypressious 2y ago
  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.
KronisLV 2y ago
> 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.
- signal11 2y ago
  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.
- mperham 2y ago
  > 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 https://github.com/contribsys/faktory) and excellent backwards compatibility.
  - dilap 2y ago
    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 2y ago
    > Go is especially good because of the large stdlib Come on… compare it with what java and python have.
    - dartos 2y ago
andai 2y ago
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.)
- ivan_gammel 2y ago
  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.
- trinix912 2y ago
  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.
- Suppafly 2y ago
  >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.
  - banku_brougham 2y ago
    applet. thats a name i havent heard in a very long time.
  - fian 2y ago
    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.
addicted 2y ago
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.
jvanderbot 2y ago
`make` works pretty well on ... everything I've written that I kept since then. `cmake ..` otoh, tends not to.
- jeroenhd 2y ago
  `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.

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.

demosthanos 2y ago

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.

ivan_gammel 2y ago
Well, I‘m not talking about Gradle, right? Sometimes conservative choice is what gets the job done.
- demosthanos 2y ago
  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 2y ago
  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 2y ago
    > 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.
    - ivan_gammel 2y ago
      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.
    - lowboy 2y ago
      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).
trinix912 2y ago
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.
cypressious 2y ago
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.

KronisLV 2y ago

> 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.

signal11 2y ago
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.
mperham 2y ago
> 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 https://github.com/contribsys/faktory) and excellent backwards compatibility.
- dilap 2y ago
  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 2y ago
  > Go is especially good because of the large stdlib Come on… compare it with what java and python have.
  - dartos 2y ago

andai 2y ago

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.)

ivan_gammel 2y ago
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.
trinix912 2y ago
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.
Suppafly 2y ago
>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.
- banku_brougham 2y ago
  applet. thats a name i havent heard in a very long time.
- fian 2y ago
  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.

addicted 2y ago

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.

jvanderbot 2y ago

`make` works pretty well on ... everything I've written that I kept since then. `cmake ..` otoh, tends not to.

jeroenhd 2y ago
`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.