I did not get the feeling that the original authors were trying to promote their existing systems over Jigsaw. My impression was more the were trying to run their existing systems on top of Jigsaw and were frustrated that they couldn't get their existing use cases to run on Jigsaw due to missing features.
For example to the best of my knowledge JBoss does not promote JBoss Module for anything other than the implementation of WildFly / JBoss EAP. Users of WildFly / JBoss EAP should only need to know about JBoss Module when they want to extend WildFly / JBoss EAP or access or hide internals of WildFly / JBoss EAP. Normal applications should have no need for this. Also JBoss discontinued OSGi a long time ago, they created JBoss Modules because they were unhappy with OSGi.
I do not agree with Mike Hearn on the altruistic motives of Oracle. Jigsaw seems to be entirely driven by Oracles vision for the JDK and everybody else second. Which is fine as long as we're talking about a module system for the JDK but suboptimal when we're taking about a module system for applications. Many of the design constraints in Jigsaw are only presents because of requirements for the JDK.
Jigsaw seems to be entirely driven by Oracles JDK team with input of other teams (WebLogic, GlassFish, ...) ignored. To be honest I do not see how Oracle can deliver on a modular Java EE 9 in the time frame they have communicated (two years).
To give you an example for what I perceive as NIH-syndrome from the Oracle side people have been trying for years to tell Oracle how Spring works and trying to get an answer from Oracle how they expect it to work in Jigsaw. The issues here are really basic and apply to many other frameworks as well, namely runtime class generation and frameworks reflecting on user code. The current state is to get Spring to run on Jigsaw either a JVM option or Unsafe is required. Any framework doing runtime class generation is having to do this. If anything Jigsaw is causing a proliferation of Unsafe.
Oracle keeps changing fundamentals of Jigsaw while it has supposedly been "feature complete" for months.
2 comments
[ 3.0 ms ] story [ 12.0 ms ] threadFor example to the best of my knowledge JBoss does not promote JBoss Module for anything other than the implementation of WildFly / JBoss EAP. Users of WildFly / JBoss EAP should only need to know about JBoss Module when they want to extend WildFly / JBoss EAP or access or hide internals of WildFly / JBoss EAP. Normal applications should have no need for this. Also JBoss discontinued OSGi a long time ago, they created JBoss Modules because they were unhappy with OSGi.
I do not agree with Mike Hearn on the altruistic motives of Oracle. Jigsaw seems to be entirely driven by Oracles vision for the JDK and everybody else second. Which is fine as long as we're talking about a module system for the JDK but suboptimal when we're taking about a module system for applications. Many of the design constraints in Jigsaw are only presents because of requirements for the JDK.
Jigsaw seems to be entirely driven by Oracles JDK team with input of other teams (WebLogic, GlassFish, ...) ignored. To be honest I do not see how Oracle can deliver on a modular Java EE 9 in the time frame they have communicated (two years).
To give you an example for what I perceive as NIH-syndrome from the Oracle side people have been trying for years to tell Oracle how Spring works and trying to get an answer from Oracle how they expect it to work in Jigsaw. The issues here are really basic and apply to many other frameworks as well, namely runtime class generation and frameworks reflecting on user code. The current state is to get Spring to run on Jigsaw either a JVM option or Unsafe is required. Any framework doing runtime class generation is having to do this. If anything Jigsaw is causing a proliferation of Unsafe.
Oracle keeps changing fundamentals of Jigsaw while it has supposedly been "feature complete" for months.
Mike Hearn also seems to confuse AOT and jlink.