1. 3
  1.  

  2. 2

    There’s a lot of stuff to address in the document, but I get the feeling their complaints are largely misguided.

    Let’s go through one passage as an example.

    It has been posited that the presence of circular dependencies is an anti-pattern and a design error. The primary supporting argument is that all modules which form a cycle are logically one module.

    That sounds reasonable enough.

    However this at best applies only to limited cycles of a small fixed number of modules which come from the same author and are produced at the same time.

    Yeah, that might be!

    Modern, real world applications, even relatively small ones, now consist of dozens or hundreds of distinct pieces from a multitude of sources.

    Indeed they do. And this is where the author seems to be overlooking a problem.

    Maven is a big part of this: by allowing application dependencies to be managed automatically, the friction of doing so has been greatly reduced, and it has been observed that including substantial dependency graphs in an application as a common practice has increased apace

    Yes. Maven is a lot like NPM in this regard. Java and JavaScript applications all lug around reams and reams of dependencies, just because adding them has been so easy.

    Just slap on left-pad or commons-whatever and let Maven take care of downloading everything.

    So if the new module system curtails this mad proliferation of (largely pointless) dependencies, that’s not something to complain about.

    The only potential downside I can think of, is if people just can’t handle cleaning things up, and the module system will cause a major Python3 -like rift that weakens the whole ecosystem for ages.

    1. 3

      JPMS worries me a lot.

      I’ve worked at companies which have a “Not Invented Here” syndrome, and they wrote their own web servers, http clients, all sorts of things. I prefer to use apache http client, or jetty. I would find it difficult to write and maintain a correctly functioning http client, especially at the same time as actually doing work. apache-httpclient is ~33k lines of Java. The same is true of jetty, which is even more critical to our business (~43k lines of code). These figures don’t take into account the dependencies.

      I don’t agree that these dependencies are pointless. left-pad, yes. apache commons, maybe (big maybe), jetty-server, no way, http-client no way. They make me much more productive for my company.

      As for cleaning things up, yes, theoretically, this should be the way that things are written in the first place, but this will cause a lot of short/medium term pain. ALL of my dependencies have to be correctly modified. This modification won’t be back-ported to the versions that I use, so then I need to upgrade to the latest version. This may involve API changes. The wait for upgrade to all my dependencies is a pain which I already have to go through for Scala -Scalastyle still doesn’t have a 2.12 version because I’m waiting for a dependency to upgrade to 2.12.

      My attitude comes down to the same as was quoted:

      “Ok. [Forget] Jigsaw compatibility. If doing so requires use of Java 9 tools, I’ll have zero […] level interesting in support for next 2+ years” - Tatu Saloranta (Author of Jackson, WoodStox, ClassMate, TStore)

      I agree with Ceki Gülki when he said:

      If only the current JPMS incarnation had a convincig use case, JPMS’ barebones simplicity might be considered pure genius.

      1. 1

        I’ve worked at companies which have a “Not Invented Here” syndrome, and they wrote their own web servers, http clients, all sorts of things. I prefer to use apache http client, or jetty

        I use Jetty too, but I did write a tiny http client not that long ago :)

        But there’s a massive difference between writing your own Jetty and writing your own left-pad, or whatever some random commons-turdnugget from 1998 is supposed to accomplish.

        As for cleaning things up, yes, theoretically, this should be the way that things are written in the first place, but this will cause a lot of short/medium term pain

        The Java ecosystem has been lugging around an enormous pile of mostly pointless JARs in every single project, just because that’s what we ended up doing because Maven made adding dependencies so painless.

        (Note: Before Maven came along, we used to actually care about our dependencies because we had to manually place them under the WEB-INF/lib directory of a Java web-app)

        But the situation is pretty much exactly what the front-end world is like these days. Libraries like ‘left-pad’ or ‘is-array’ should arguably not exist, but they definitely shouldn’t be (transitively) adopted by everyone, to be hauled around forever and ever in every project.

        That’s just crazy. So if the Java 9 module system manages to “force” people into being careful and judicious about their dependencies, it will be a huge benefit for the Java ecosystem in the future.

        I’d much rather endure some short-to-medium term pain in exchange for long-term happiness, than keep enduring the dirty mess we’ve got on our hands now. I’ve been scraping together my own SaaS product, and never wanted to touch Node with a 10-foot pole.. but you just can’t use React without learning some bare minimum level of Webpack and having some Node-specific config files lying around even if you’re not actually using Node.

        I’ve still managed to avoid most of the craziness, but having to wrangle with all the solutions-in-search-of-problems has been a huge waste of time, and one that wouldn’t have happened if dependencies weren’t so easy to add.

      2. 1

        All this opposition to dependencies seems to be aesthetic rather than practical. Dependencies are a lot cheaper than they used to be, so it makes a lot of sense to use more of them and do less writing your own code. Even if it’s 10 lines, why write it yourself when a dependency will be less effort for you now and easier to maintain going forward?

        1. 2

          With Maven in particular, dependencies have an incredibly stupid cost, which can be trivially demonstrated with only two dependencies:

          • Project
            • DependencyA
              • Conflict:1.0.0
            • DependencyB
              • Conflict:2.0.0

          Uh-oh. If we assume correct semver, there’s no way to successfully use this project except to get lucky with the changes in Conflict between 1.0.0 and 2.0.0. Worse than that, the actual conflict will not manifest until runtime; Project successfully compiles against both DependencyA and DependencyB and the conflict won’t become apparent until A or B actually try to use a feature missing from whatever version of Conflict ends up on the classpath.

          This is made even worse because “correct semver” is a categorically false assumption for Maven projects; one that bites me often is Amazon’s AWS SDK, which frequently makes backwards-incompatible changes (often in the form of incompatible versions of transitive dependencies, making the problem very difficult to track down) between minor versions.

          (To be clear, the problem is mostly cultural. Tooling could and should make these conflicts easier to catch early, but the real issue is massive backwards-incompatible version churn.)

          Now, what’s the best way to solve this? Eliminating dependencies is one way, though as you point out the costs are very high. The proposal of Jigsaw (at least as far as I understand it, which is admittedly not very far) of letting A and B independently carry their own versions of Conflict is another. Enforcement of semver as far as possible and compile-time checking for version conflicts would at least make the problem easier to spot, though the unfortunate specter of runtime reflection makes it impossible to catch every problem. Ultimately I think the correct solution is to change the culture so people write libraries which are much more stable and versioned correctly, and major version conflicts are much rarer; but the difficulty of that solution borders on impossible.

          1. 2

            Even if it’s 10 lines, why write it yourself when a dependency will be less effort for you now and easier to maintain going forward?

            Why would a dependency be easier to maintain for me, than 10 lines of my own code that may never need to be changed?

            Sometimes a new version of ‘left-pad’ or whatever comes out, and then it’s downloaded over and over and over again all over the world, even though conceptually nothing has changed.

            The new version is supposed to do exactly the same thing as the old one, but it might even be broken somehow!

            It’s often a good idea to go through some effort in the short term, in exchange for benefits in the long term.