On Sat, Jan 24, 2015 at 1:18 AM, Bill Shannon <bill.shannon_at_oracle.com>
wrote:
> 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.
>
I think that is the bare minimum we must do, otherwise we would have failed.
> 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.
>
Sorry but I strongly disagree with this vision. It took one decade to get
Java modules right. And the first thing the group did was to modularize its
own JDK, eating their own dog food, looking into the future (IoT) and
showing to developers that their modular system works. And this was a huge
amount of work. We must do the same! Our container (EE) must be modularized
internally. We can't keep on saying "Java EE is just for fat *real*
application, use something else for your IoT developments".
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 <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>