[javaee-spec users] Re: [jsr366-experts] Re: Fwd: Re: One container to rule them all

From: Antonio Goncalves <>
Date: Sat, 24 Jan 2015 19:08:20 +0100

I love this sentence "*it's essentially the app that owns the AS*"


On Sat, Jan 24, 2015 at 6:00 PM, arjan tijms <> wrote:

> Hi,
> On Sat, Jan 24, 2015 at 11:48 AM, Antonio Goncalves
> <> wrote:
> > We can't keep on saying "Java EE is just for fat *real*
> > application, use something else for your IoT developments".
> I strongly agree with this.
> This comes up often in discussions about Java EE; the idea about
> *real* applications or the *one and only right way*.
> In that vision, which originated in J2EE, there's always a somewhat
> untrusted team of developers and a trusted team of Ops. The
> Application Server is installed once, and developers are not even
> allowed near it. The Ops team maintains the server and all
> "resources", such as data sources, JMS destinations, thread pools and
> security modules. The developers are not allowed to create any of
> those resources themselves, and *at most* are allowed to put a comment
> or readme.txt somewhere, which the Ops team is then to interpret in
> some way (which is a often brittle) and if the team is lucky, create
> the resource in the right way (and if the team is unlucky, weeks or
> even months of creating tickets can be needed to get a trivial task to
> be done).
> Nothing can ever be upgraded in this vision, since there are always at
> least 10 totally different applications running on said AS, and it's
> always impossible to update or test at least a few of those. IMHO the
> idea that "Java EE can't be upgraded" has its roots in this vision.
> The vision also talks about roles like bean providers, application
> assemblers, application deployers etc.
> Even if there are indeed places that work like this, it's by far not
> the only way. Indeed, for IoT deployments, where I have a lightweight
> AS with a small app for home automation deployed to a raspberry pi,
> this somewhat mandatory assumed division of roles does not make any
> sense at all. In that case there is no untrusted developer and trusted
> ops, since there's only me. There's no need to define a data source
> outside the application and provision a database for which the
> password needs to be hidden from the untrusted developer, since
> there's only a tiny embedded H2 database, etc.
> It's funny perhaps that IBM, which is maybe most known for its very
> large WebSphere installations and its many tools for supporting the
> mentioned old J2EE vision, is also the one creating a lightweight Java
> EE runtime (Liberty) that does focus greatly on being suitable for
> IoT. See e.g.
> But even for somewhat more traditional usages of Java EE, such as a
> web app, the strict dev/ops division and the single installed AS is
> not a given at all. At and before that the AS is
> basically just a library to us. We keep its source in our git repo,
> and whenever anything changes to it we can deploy it just as we would
> deploy an application archive (war/ear). Since we have a strict rule
> of 1 application per AS and can trivially deploy a new or modified
> version of the AS, it's essentially the app that owns the AS, instead
> of the other way around.
> Long story short; having a "java -jar javax.enterprise.Container
> command" deployment model would fit a lot of alternative use cases. A
> fixed monolithic installed AS that's shielded from developers is
> absolutely not the only viable model.
> Kind regards,
> Arjan Tijms
> >
> >
> >> 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.
> >
> >
> >
> > Java SE modularization is a bet on the future (create your own JVM with
> your
> > needed modules) we must do the same for Java EE. I know it's a huge
> effort
> > for implementors, but it's the only exit for Java EE if we want it to be
> > alive in 10 years (and when I say alive, it's not about keeping old
> > applications up and running, it's thinking about Java EE everywhere, in a
> > Linux environment, in a mobile phone, in a fridge...). "Java EE
> > specification is composed of a large number of other specifications".
> > Exactly, that's why we must go further. The Java EE contract should be
> > "bundle the specs you need, we make sure they all work together, link
> them
> > all together, build your own app server, and deploy it in a chip in your
> > fridge with just a java -jar javax.enterprise.Container command".
> >
> >
> >> 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.
> >
> >
> >
> > Yes, I would like to ear what vendors say. Java EE lost its momentum
> years
> > ago, still hasn't recover from it, we must look into the future. I think
> > Java EE 8 should start making some steps toward its own modularization
> (at
> > least imposing SPIs and making sure it works in Java SE, and an umbrella
> > Container API). Profiles are also a first step, but their are not enough.
> >
> > My 2 cents
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France

Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <> | Twitter
<> | LinkedIn <> |
<> | Paris
JUG <> | Devoxx France <>