On 07/26/2012 10:19 PM, Reza Rahman wrote:
> +1. This basically restates what I was trying to suggest. That being
> said as Craig alluded to, this is a "nice to have" that is not worth
> sacrificing basic API innovation (e.g. component model alignment),
> technology adoption (e.g. HTML5, NoSQL, social media, etc) and basic
> stability (application servers that are lightweight, affordable and
> bug free).
My personal view is that modularity is /absolutely vital,/ not a
nice-to-have, and the lack of or (or rather the resulting PermGenSpace
classloader issues, class version conflicts, etc) were a huge problem
for me on Glassfish. For me at least the lack of modularity makes EE
platforms much harder to use, harder to learn, and less productive.
However, it has already been shown by AS7 to be possible to accommodate
a reasonable module system without specific support from the spec.
In my newbie opinion if you feel modularity is so vital to include in EE
7, you need to be collecting experts on OSGi, the JBoss module system,
and from Jigsaw. Bring them together to hammer out a realistic and
concrete plan. If that sounds a lot like forming a working group for a
new JSR, that's probably not coincidence ;-)
I would like input from the JBoss AS team on the challenges they
experienced and areas where the spec can make it easier or remove
roadblocks. Difficult interdependencies that need to be weakened through
an SPI, etc. Make EE 7 a "modularity ready" spec that can accomodate
Jigsaw if we see it in an 8.5 timescale, and can fit well into OSGi and
AS7 modules.
Right now we seem to have hand-waving and opinions with a notable lack
of concrete ideas/plans for how to usefully include modularity in the EE
7 scope. Rather than prematurely standardise on modularity without a
clear plan or the important experienced people from OSGi, JBoss and
Jigsaw here, I think it makes sense to leave it to implementers. Getting
modularity right isn't a small item you just tack onto a spec - and in
the Java world once something is standardized we're stuck with it for
good or ill, so it's /vital/ to get it right. Look at the mess with how
CDI injection overlaps with JSF, or the confusing mess with multiple
@ManagedBean annotations we may never be rid of. Do you /really/ want
to risk a half-baked module system that's standardised on before being
tried in the real world?
Comments from Jeff Genender also suggest that a module system wouldn't
be enough for many; they'd want complete pluggability./swappability of
even core modules like JTA. Making that possible would expand the task
to not only a module system but a big expansion of SPIs. Is that
realistic in the EE 7 time frame? What gets dropped to make room? Does
anybody have any definite ideas about where the SPI difficulties even lie?
I'll try to bug some JBoss folks to see if I can get some views from
people who've been in the trenches implementing modules. If others are
able to reach out to OSGi implementation people that'd be very
interesting. Since modularity appears to be a hot topic, let's get some
people who've built it in.
--
Craig Ringer