As a java dev, I'm not sure Jigsaw helps in any way. Tooling has pretty much solved the classpath management issue. What would've been awesome is if modules were version aware, and code was allowed to depend on different versions of the same module, but that's not the case.
Now the private access thing is really being pushed by the java maintainers. They want the luxury to refactor internals without breaking anyone, so they want to make it so everything non public is 100% inaccessible in all contexts to users. I don't know that I agree with this necessarily. Especially now, the problem is they already shot themselves in the foot by allowing reflection on them in the past, so changing it back would break a lot of code for a lot of people.
The main problem with deprecating internals is the slow cycle of Java. They first released every year, then every two years, and now every three years, and the pace seems to be slowing down further. If they still made a new release every year, they could mark something deprecated in one release and then refactor it the next. But given that they spend years between releases they don't have that luxury. This is the age-old problem of going long between releases because it's hard to release, because you go long between releases, because...
I say this in all seriousness: java should emulate PHP. The current development model of PHP produces a stable product that optimizes for the needs of the user community, ships a major release once a year and welcomes outside contribution.
Jigsaw is not maven, nor gradle, the versioning problems should be solved by those tools. I'm getting sick of the multiple version dependency problem being brought up over and over again. That's one of the reason why OSGI is not widely adopted. You should watch some of the talks delivered by the jigsaw team.
> Jigsaw is not maven, nor gradle, the versioning problems should be solved by those tools.
Then why do we need Jigsaw at all? If the assumption is that you run Maven or Gradle anyway then what is left for Jigsaw to do? The dependency management and check will happen by those tools.
> the versioning problems should be solved by those tools
I'm not a Java developer; could you explain a bit about how Maven/Gradle solve this problem? My understanding is that what people want is something like what Node gives you—the ability to have both libfoo-1.0 and libfoo-1.1 loaded into the same VM at the same time without clashing. Do the build tools use e.g. name-mangling to achieve this?
A lot of the problems in the API land can be attributed to what I call the sandbox skills, or rather lack thereof. Those are skills that we were supposed to learn when we were kids and played in sandboxes. Things like how to share stuff, how much to share, how not to be too selfish and not sharing enough, etc. You get the idea :)
Now the private access thing is really being pushed by the java maintainers. They want the luxury to refactor internals without breaking anyone, so they want to make it so everything non public is 100% inaccessible in all contexts to users. I don't know that I agree with this necessarily. Especially now, the problem is they already shot themselves in the foot by allowing reflection on them in the past, so changing it back would break a lot of code for a lot of people.