3 ms·

It's not just Java culture, though, it's also Java. For instance, you can't have "npm for Java," because that's not how Java works at a very fundamental level.

It's not just Java culture, though, it's also Java. For instance, you can't have "npm for Java," because that's not how Java works at a very fundamental level. Java gets gigantic monolithic framework libraries because Java's class loader works fundamentally differently from Node's CommonJS module system.

hyperpallium 8y ago
Please elaborate.
sonnyblarney 8y ago
Wha? I don't think so. An npm-like framework could work for Java. The difference between classloading and node.js 'require' module loader is not super relevant. Frankly - the reason that Maven and Gradle are more sophisticated is because many Java projects are massive compared to most JS projects, the amount of complexity, various kinds of packaging, testing etc. necessitates some inherent complexity in modules. Java modules tend to be a lot bigger as well. Again I think it's a cultural issue.
- bodas 8y ago
  npm works because you can have lodash v3 and lodash v4 existing at the same time, at runtime. Node sees two pieces of code at different locations on disk, and loads them twice, considering them to have no relationship. This means that a library can turn its API completely inside out and not cause dependency hell. Your dependencies can update their sub-dependencies in their own time. This means there's no pressures against releasing new updates, and leads to the beautiful and very productive chaos that is npm. Java is not designed to work this way.
  - RandyRanderson 8y ago
    > "you can have ... v3 and ... v4 existing at the same time, at runtime" That's exactly what Java ClassLoaders do...
  - step21 8y ago
    > the terrible chaos that is npm I don't get how anyone can call it beautiful and productive. Ever take over/inherit some 'older' node code and try to update it or even get to work... it is hell. Even worse if it is from the time when there were competing forks of nodejs, so you have to try to figure out which it prefers. And maybe even then it won't run. (probably because npm's version notation can be unpredictable, so npm install still installs a version that breaks something even though it shouldn't)
  - hyperpallium 8y ago
    The same class, loaded by different classloaders, is a different class. Thus, you can load different versions of the same library at the same time, by loading them with different classoaders. Even, the same version. Now, there's necessarily the problem of which one of them a particular piece of code wants to use, which is determined by which classloader loaded that piece of code. You also can (and routinely do) have a path of nested classloaders that load different things. Java was designed this way, right from the very beginning. The problems with java are: 1. somewhat verbose ("readable") 2. stuff hacked on (generics etc) 3. C-style configuration-over-convention 4. enterprise culture
- sseth 8y ago
  npm allows multiple versions of the same package - not ideal, but works. To do this in Java, you need multiple classloaders etc (basically what OSGi provides), but you are now in a different kind of hell. edit : I forgot to add that Java modules may address this, but i am now out of the Java ecosystem for quite some time.

hyperpallium 8y ago

Please elaborate.

sonnyblarney 8y ago

Wha? I don't think so. An npm-like framework could work for Java. The difference between classloading and node.js 'require' module loader is not super relevant. Frankly - the reason that Maven and Gradle are more sophisticated is because many Java projects are massive compared to most JS projects, the amount of complexity, various kinds of packaging, testing etc. necessitates some inherent complexity in modules. Java modules tend to be a lot bigger as well. Again I think it's a cultural issue.

bodas 8y ago
npm works because you can have lodash v3 and lodash v4 existing at the same time, at runtime. Node sees two pieces of code at different locations on disk, and loads them twice, considering them to have no relationship. This means that a library can turn its API completely inside out and not cause dependency hell. Your dependencies can update their sub-dependencies in their own time. This means there's no pressures against releasing new updates, and leads to the beautiful and very productive chaos that is npm. Java is not designed to work this way.
- RandyRanderson 8y ago
  > "you can have ... v3 and ... v4 existing at the same time, at runtime" That's exactly what Java ClassLoaders do...
- step21 8y ago
  > the terrible chaos that is npm I don't get how anyone can call it beautiful and productive. Ever take over/inherit some 'older' node code and try to update it or even get to work... it is hell. Even worse if it is from the time when there were competing forks of nodejs, so you have to try to figure out which it prefers. And maybe even then it won't run. (probably because npm's version notation can be unpredictable, so npm install still installs a version that breaks something even though it shouldn't)
- hyperpallium 8y ago
  The same class, loaded by different classloaders, is a different class. Thus, you can load different versions of the same library at the same time, by loading them with different classoaders. Even, the same version. Now, there's necessarily the problem of which one of them a particular piece of code wants to use, which is determined by which classloader loaded that piece of code. You also can (and routinely do) have a path of nested classloaders that load different things. Java was designed this way, right from the very beginning. The problems with java are: 1. somewhat verbose ("readable") 2. stuff hacked on (generics etc) 3. C-style configuration-over-convention 4. enterprise culture
sseth 8y ago
npm allows multiple versions of the same package - not ideal, but works. To do this in Java, you need multiple classloaders etc (basically what OSGi provides), but you are now in a different kind of hell. edit : I forgot to add that Java modules may address this, but i am now out of the Java ecosystem for quite some time.