5 ms·

It does quite a lot. I suspect it basically breaks Maven, since Maven jars aren't valid for Jigsaw. It also breaks code that does things like poke private membe

• TeMPOraL 9y ago
  > It also breaks code that does things like poke private member variables in other people's classes. > I also think it'll be worth it. Yeah, it's fun to stick to abstract design principles, until an important dependency in your project refuses to play ball, in a way that cannot be trivially fixed by simply subclassing something and calling it a day. In a language like Java you essentially have three options - submit an issue and wait months (or years) 'till it gets resolved, fork the project now (if open source) and deal with costs of supporting your own version, or just poke at an appropriate private static variable somewhere and have a working version deployed in an hour. I know which one I prefer.
  • kpil 9y ago
    Seems like the least important thing to plug. Everyone that do this knows they're in deep shit anyway, but this is taking away their paddle.
    • didibus 9y ago
      But why take away my paddle? Let me have a working solution right away, and when you push an update that breaks my code, let me also deal with fixing it. I'm not dumb, I understand the risk of depending on private APIs.
      • lomnakkus 9y ago
        > But why take away my paddle? Because there are upsides -- a major one being proper implementation hiding and (not sure if this made it in:) "classpath" isolation. > I'm not dumb, I understand the risk of depending on private APIs. Well, you knew the risks, so I'm not sure why you're so upset that Java 9 precludes you using what were ultimately private APIs. It's not possible to have it both ways.
        • kpil 9y ago
          I understand that it's impossible to both implement a rule and not implement a rule, but what is actually the benefit of disabling this? All nerd sleeps safe at night confident that no one changes their private variables? Does this mean that things like jmockit's deencapsulation stops working?
          • moomin 9y ago
            I think the answer is that it allows them to optimise libraries.
          • didibus 9y ago
            There is none, appart from making the Oracle employees life easier. They don't have to deal with the backlash of breaking customers by accident when touching private APIs, so it gives them more liberty. They decided to take the blow in one go, instead of spread over time. Now, the blow was bigger then they thought, so they've retracted and spread the change over Java 9 and 10, by making 9 an optional setting, and saying 10 will be the cutoff. In an ideal world, it makes sense. This is defensive programming, they're protecting themselves against unplanned usages of their libraries. That's always good when you're a maintainer. You know how annoying it is when you're trying to change and improve things and you realize you can't because someone was using your stuff in a completely dysfunctional way and now you'd break them if you proceeded. But in a practical world, the world of business especially. You should also know that part of the popularity of your software comes from all those use cases users have managed to somehow satisfy without you explicitly planning and building them. Take those away, and your software also loses a lot of value, until you reimplement all these use cases in a more sane way. Tjis will take time, and your customers might move on to something else. We'll see how this impacts Java.
            • lomnakkus 9y ago
              I'm not going to try to convince you, but getting classpath isolation would be a huge deal for my use case. (We could theoretically do OSGi or similar, but that's quite a heavy-handed approach to what should be a simple -- even "default" -- thing).
  • vbezhenar 9y ago
    I think you can always extract module in question into your module. Might be just an additional step during the build.
  • rictic 9y ago
    It just occured to me that the second and third options are more similar than they initially appear. In both cases you've taken responsibility for the library in a new way. It's no longer a breaking change for the library authors to break you if you're messing with private state, so you'll need to do some vetting of all changes to the library.
    • x0x0 9y ago
      True, but generally you can pin a dependency version in a way you can't pin a jdk version, because people expect your code to run on the latest jdk.
• pbh101 9y ago
  Since it can be disabled at the command line on JVM startup, I don't think the breakage will be that painful.
  • emidln 9y ago
    I, for one, enjoy when my language's runtime is broken by default.
• needusername 9y ago
  > I suspect it basically breaks Maven, since Maven jars aren't valid for Jigsaw. What do you mean by that? Maven JARs are just normal JARs downloaded with Maven. They are therefore valid in both the classpath and the module path (as automatic modules). Jigsaw modules are just normal JARs with a module-info.java, there is nothing preventing you form managing them with Maven. In fact in already have several of them in Maven Central, they went through the SonaType quality check without issues. In fact the compiler plugin will detect if a dependency in a modular JAR and if so put in the module path rather than the classpath (the javadoc plugin does not yet).