6 ms·

Here is maybe some reasoning behind the no votes Concerns Regarding Jigsaw(JSR-376, Java Platform Module System) https://developer.jboss.org/blogs/scott.stark/

• halestock 9y ago
  A rebuttal: https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d36dd6f https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d3...
  • mcguire 9y ago
    A highlight: "Following links with enticing sounding names like “Where to start” simply gives you a bunch of links to off-site tutorials written by implementation vendors, none of which are any good. There is also a list of five different books on the topic. This developer experience is not excellent. But mostly it’s complicated because its design is genuinely enormous." Five books? That's horrible. (By way of introduction, I've spent a good deal of time with OSGi and none at all with JBoss or Jigsaw. I am more-or-less out of the Java environment at this point.) Ok, here's the deal: OSGi looks big and complicated. Part of that is due to the fact that it's been around for like 20 years and part is due to people trying to do fancy things with it in the Java environment, where everyone else is trying to do fancy things with basically incompatible magic. (Virgo[1] waves desolately from off in the distance.) [1] http://www.eclipse.org/virgo/ http://www.eclipse.org/virgo/ In reality, OSGi isn't that bad. I learned it mostly from reading (part of) the spec, which isn't the worst as far as specs go. OSGi is fundamentally a generic container; if you're familiar with servelet lifecycles and have used Tomcat to deploy and undeploy web apps, you're familiar with about 60% of OSGi, which is a subset of that. The other 40% of OSGi's fundamental complexity is built around the sole purpose of allowing an application to depend on a library A, which in turn depends on version X of library B, while at the same time the application depends on library C, which itself depends on version Y of library B. (The other 10% of OSGi's fundamental complexity is the "services", which are double-plus fun extra features that make life better in many ways. But we can ignore them here since we're talking about modularity.) Doing that sort of thing is hard. Doing that in Java, where everything uses reflection, dynamic code generation, and classloader magic, is not so much hard as terminally bizarre. Personally, I view a module system as an aid for the programmer: it prevents stuff that you shouldn't touch from leaking into stuff that you should touch. As a result, both OSGi (and, I think, Jigsaw) fail badly as module systems: If it waits until runtime to blow chunks, it's not helping the programmer. But, in the Java environment, modularity in my sense is impossible. (It's also unwanted, but that's a rant about Java developers for another day.) Anyway, when you say, "oh, they're just whining that their system didn't win", you are right, sort of. But on the other hand, "their systems" have spent a long time dealing with the insane, Sorcerer's Apprentice-type nuttiness that is the rest of the Java ecosystem, and it appears that Jigsaw is just ignoring that nuttiness, that the majority of Java programmers use, and enjoy, every day. Which was the major worry from the OSGi community when the Jigsaw project was announced. As an amusing aside: version numbers. OSGi has a moderately complicated semantic versioning [2:PDF] system to support that fundamental goal up there. OSGi version numbers look like major.minor.micro.stringy, with specific rules for bumping the major, minor, and micro numbers. Jigsaw originally started out with an incompatible version number format, apparently due to the fact that Java versions have a fixed constant major number of 1. The current [State of the module system] for Jigsaw says, [2] http://www.osgi.org/wp-content/uploads/SemanticVersioning1.pdf http://www.osgi.org/wp-content/uploads/SemanticVersioning1.p... > A module’s declaration does not include a version string, nor constraints upon the version strings of the modules upon which it depends. This is intentional: It is not a goal of the module system to solve the version-selection problem, which is best left to build tools and container applications. The Jigsaw requirements[3] go further to say, > Multiple versions — It is not necessary to support more than one version of a module within a single configuration. > Most applications are not containers and, since they currently rely upon the class path, do not require the ability to load multiple versions of a module. Container-type applications can achieve this, when needed, via dynamic configuration, as outlined above. > Version selection — The process of configuring a set of modules need not consider more than one version of any particular module. > In other words, this specification need not define yet another dependency-management mechanism. Maven, Ivy, and Gradle have all tackled this difficult problem. We should leave it to these and other build tools, and container applications, to discover and select a set of candidate modules for a given library or application. The module system need only validate that the set of selected modules satisfies each module’s dependences. [4] http://openjdk.java.net/projects/jigsaw/spec/reqs/02#non-requirements http://openjdk.java.net/projects/jigsaw/spec/reqs/02#non-req... Therefore, Jigsaw is explicitly free to be incompatible with OSGi or any other existing container system. Yay. TL;DR: It's not so much that someone else's system didn't win, but that Jigsaw doesn't care that Java is a big, giant, hairy bundle of nasty and that fact is likely to make everyone's life harder. P.S. For OSGi information, I strongly recommend Neil Bartlett. His OSGi in Practice and blog posts are exceptionally good and he is very helpful and friendly in the OSGi community, as I recall. He's also on the Jigsaw experts group. And one of the Concerns regarding Jigsaw contributors. http://njbartlett.name/osgibook.html http://njbartlett.name/osgibook.html
    • geodel 9y ago
      I do not know of any big OSGi success apart from eclipse. At one point Spring put a lot of effort and then they dump all that at eclipse project after not seeing much traction. Apache has bunch of OSGi related projects and they do not seem very popular compared to straightforward Java/EE components. For my applications I see some value in Jigsaw specially modular images. Despite being available for long time OSGi still is some esoteric technology without mass developer appeal whereas Jigsaw seems to have potential to be really useful to lots of developers. It is rather sad that OSGi people keep piling on Oracle for not using their barely successful technology.
      • chopin 9y ago
        I worked a good deal with OSGi and think it is sad that it didn't get more traction in the server world. I once adapted a jetty container to use OSGi dependencies instead of packaging all dependencies into a single war file. I gained wonderfully light weight deployment units and the possibility to patch dependencies without touching downstream modules.
        • mcguire 9y ago
          I used the SpringSource server (later known as Eclipse Virgo) as a sort of "platform as a service" for enterprise apps. It could deploy anything from plain war files up to OSGi-aware apps that could access custom services for configuration, db access, authentication/authorization, and so forth. Worked rather well, with decent uptime and no hair pulling on my part. The down side was that OSGi requires modularization, which exactly no Java developers to my knowledge had any experience with. Plus OSGi modularity is entirely done at runtime and Spring's tooling to try to support it was incredibly flakey. Conversations went like: "My app works fine on my dev box but blows chunks when I try to deploy it." Me: "You have to be explicit about whay you are depending on in your app's manifest." "I see your lips moving, but all i hear is barks, grunts, and squeals." "Sigh. I'll fix it." I can't really see jigsaw making the situation any better, especially since it explicitly ignores versioning and containers.