3 ms·

I feel like some of these complaints, such as (edit: some of) those by redhat, could have actually been mentioned even before any development on jigsaw began.

I feel like some of these complaints, such as (edit: some of) those by redhat, could have actually been mentioned even before any development on jigsaw began. It's a bit odd to me that these really large complaints come out now, instead of much earlier in the stage of JDK9. Maybe even before any work would have been done on red hat. Such as noted here https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns?_sscc=t https://developer.jboss.org/blogs/scott.stark/2017/04/14/cri...: > Fragmentation of the Java community That seems like a valid concern, which could have been made much earlier. Or maybe they have but people decide to push on with jigsaw anyway? I did not really follow JDK9 development all that much, apart from the occasional blog. But it just feels to me like at least _some_ of these issues should have been raised much earlier.

bad_user 10y ago
I don't know the history of this, but it's entirely reasonable that this was a case of mismanaged expectations, a phenomenon that happens a lot in this industry. In other words, maybe they thought Jigsaw will evolve into an OSGi replacement and it didn't, while introducing migration challenges. It's reasonable because the current implementation is an evolution of the original plan and maybe it evolved in a direction that Red Hat eventually disagreed with. Of course, maybe this version was scaled back in order for it to be actually released, but note that the main complaint of the others voting No is that there's a lack of consensus on the open issues. The "fragmentation of Java's community" will happen regardless, upgrades to Java 9 and Jigsaw will be slow, much slower than to Java 8. Consider that there are companies still on Java 6 and 7 and both have reached end of life. Along with an ecosystem of libraries that still maintain backwards compatibility. If you're going to go through this migration pain, the benefit / cost ratio has to be worth it. Jigsaw has to solve big problems that Java developers face, to convince the community it's worth it, because projects and libraries have to be changed to support it, risking a very unhealthy fragmentation in that process.
lvh 10y ago
Just because they've been written up and summarized for the vote doesn't mean they weren't aired before. Jigsaw has been delayed again and again and again, and that's not because it was an easy process.

bad_user 10y ago

I don't know the history of this, but it's entirely reasonable that this was a case of mismanaged expectations, a phenomenon that happens a lot in this industry. In other words, maybe they thought Jigsaw will evolve into an OSGi replacement and it didn't, while introducing migration challenges. It's reasonable because the current implementation is an evolution of the original plan and maybe it evolved in a direction that Red Hat eventually disagreed with. Of course, maybe this version was scaled back in order for it to be actually released, but note that the main complaint of the others voting No is that there's a lack of consensus on the open issues. The "fragmentation of Java's community" will happen regardless, upgrades to Java 9 and Jigsaw will be slow, much slower than to Java 8. Consider that there are companies still on Java 6 and 7 and both have reached end of life. Along with an ecosystem of libraries that still maintain backwards compatibility. If you're going to go through this migration pain, the benefit / cost ratio has to be worth it. Jigsaw has to solve big problems that Java developers face, to convince the community it's worth it, because projects and libraries have to be changed to support it, risking a very unhealthy fragmentation in that process.

lvh 10y ago

Just because they've been written up and summarized for the vote doesn't mean they weren't aired before. Jigsaw has been delayed again and again and again, and that's not because it was an easy process.