Antonio Goncalves wrote on 01/18/15 03:20:
> What's the point of defining more profiles ? More modularity ? It will come
> with EE 9.
We're a long way from EE 9, but it looks like we have a mismatch in expectations
already...
Once there's a module system in Java SE, what I'm expecting in Java EE is that
we will define how to package an application composed of modules for deployment
to a Java EE app server. And we'll define how to deploy "shared modules" for
use for applications. We likely will also define the modules (names, version
numbers, whatever) that the Java EE app server must appear to support, for use
in dependency references from applications.
What I *don't* expect to do is require that all Java EE app servers be delivered
as a specific set of modules that customers can pick and choose from to assemble
a runtime containing only the modules they like. Doing that is a *HUGE* amount
of implementation work. Even assuming every Java EE app server was already
modular in this way, there's no reason to believe they've all defined the same
modules.
On the other hand, note that the Java EE specification is composed of a large
number of other specifications, most of which are defined to work on Java SE
with few dependencies on the others. You can build a runtime by combining
implementations of many of these specifications. You might be missing many of
the common facilities defined by the Java EE platform specification, but for
simple applications that might be good enough.
Obviously this will be an interesting discussion to have when we get to Java EE
9. We'll be especially interested in what the Java EE vendors have to say since
they will bear the burden of whatever we decide.