Jigsaw was what held up the Java 9 released, due to some members rejecting the proposal. It was changed and revoted upon, but it's hard to follow what was modified to make it acceptable.
Is there anywhere the design goals and constraints for modules are? I'd really like to know how they ended up in their current form.
> Jigsaw was what held up the Java 9 released, due to some members rejecting the proposal.
That was only a few weeks. If you check the official release schedule http://openjdk.java.net/projects/jdk9/ Jigsaw was supposed to be feature complete a year before that vote happened. Jigsaw was simply not close to ready when it was merged to master. And yes, Oracle still claims it hit every milestone on that schedule.
> It was changed and revoted upon, but it's hard to follow what was modified to make it acceptable.
Not much really. Basically Oracle called their bluff. At that point is was really too late as Jigsaw was already merged to master and more or less touched every part of the JDK.
> Is there anywhere the design goals and constraints for modules are? I'd really like to know how they ended up in their current form.
Not really, it was really just Oracle making things up as they went. For the past ten years Mark Reinhold would give talks at Java conferences what the module system comping in the next Java version was supposed to do and every year the content was different. For example they have no good explanation while they mashed the module declaration into a .class file, basically everybody except Oracle thinks it's a bad idea but the just went with it anyway. They claim "reliable configuration" as a goal but without versioning that's meaningless.
> They claim "reliable configuration" as a goal but without versioning that's meaningless.
Versioning is not currently built into Jigsaw, but Jigsaw provides all the building blocks necessary to support it in third-party tools.
> For the past ten years Mark Reinhold would give talks at Java conferences what the module system comping in the next Java version was supposed to do and every year the content was different.
Plus the entire development was done in the open, in an open source project with an active mailing list and frequent prototypes.
> Versioning is not currently built into Jigsaw, but Jigsaw provides all the building blocks necessary to support it in third-party tools.
If I need third-party tools to validate my dependency graph at compile time and at runtime to ensure "reliable configuration" then why do I need Jigsaw at all? That's the current state of affairs with Java already, Jigsaw provides no value.
> Plus the entire development was done in the open, in an open source project with an active mailing list
Ostensibly. There is a difference between having an open mailing list (where people could give feedback and get a superficial thank you before getting ignored) and a readonly repository and actual open development. Quite frankly I find it telling that in 2017 we have to stress that there was and open mailing list and readonly repository. The most important thing, the decision process, was completely intransparent and all Oracle/Sun internal.
> and frequent prototypes.
Which weren't useful because none of the frameworks, libraries and tools would support it.
me guessing,
i see at least two constraints that doesn't work well with a text file. The current format allows user defined annotations and the compiler find all packages of a module and automatically insert them into the module-info (you only define the exported package not all the packages).
Is there anywhere the design goals and constraints for modules are? I'd really like to know how they ended up in their current form.