Java 9 Modularity: Are there some changes in ejb and ear deployment ?

[daniele licitra]

Hi to all and welcome to the authors of Java 9 Modularity: Patterns and Practices for Developing Maintainable Applications.

I'am developing EAR applications that runs on Wildfly.
I developed a set of EJB modules (for example GeoDataModule, AuthorizationModule, FinancialModule, ... ) that i put in my current EAR depending on the scope of an application.

Each time I update a module, I need to compile the module and the ear, then deploy the EAR on the server. Sometimes I update a <2Mb ejb module but I need to deploy a 60Mb EAR

In the quoted book, is there something about EJB and "boosting" of the procedure that I've explained?

There is another problem in Wildfly: if my GeoDataModule depends on GeoDataEntity.jar, the entity jar must be in the classpath. At this moment I add the jar to the EAR as a dependency or I put it as a module in Wildfly.
Does this system change in Java 9 with modularity?

[Narendran Sridharan]

we can deploy our applications as war or ear post-conversion of it as Java 9 Modules, but we cannot gain the benefit of modular deployment. Similar to OSGI deployment in containers like wildfly, Java 9 module deployment will require a special support from containers. Definitely delta deployment (deploying only changed modules and its dependents) should be possible in future.

[Paul Bakker]

For this to happen the Java EE specs will have to adopt Java 9 modules. In theory, a EJB or Servlet container could be implemented based on "Layers" as described in chapter 6 of Java 9 Modularity. Each WAR/EAR would be loaded in it's own module layer.
This will be a big change to the specifications and the ecosystem though, so it remains to be seen if and when that happens.

The real cause of your problems is the all-containing EAR however. The Java EE specs don't force you to deploy this way, and things could be a lot faster if you would deploy individual JARS/WARs. There is no need to wait for module support for this.