Antonio Goncalves wrote on 1/24/15 2:48 AM:
>
>
> On Sat, Jan 24, 2015 at 1:18 AM, Bill Shannon <bill.shannon_at_oracle.com
> <mailto: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".
There's effectively only one implementation of Java SE. If we modularize that
implementation, we're done.
Java EE is harder.
The vision of every Java EE application server being modularized in exactly the
same way might sound attractive, but it just doesn't seem practical. There may
be an interesting point between "all" and "nothing" that we can consider in Java
EE 9. But again, we'll need to get more feedback from vendors on this topic. I
expect that some vendors will aggressively module-ize their products even if we
don't require it, so mostly this is about what we can standardize and /require/
all vendors to support.
>
>
> 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.
What might be possible is to allow Java EE vendors to provide modules of their
own choosing, so that their customers can assemble a runtime with exactly the
modules they need, even though those might be different modules than another
vendor provides. Requiring all vendors to provide exactly the same modules is
the hard part.
We also have to consider how these various possibilities interact with the range
of products we intend to allow with Java EE. There's a bunch of questions we'll
have to answer in order to decide how or if the spec can require support for
"java -jar".
If you have a Java EE product that supports clusters, what would it mean if you
were required to be able to start your server with "java -jar"? Does that only
work for a single instance? Does that only work for the admin server? Are you
required to be able to start each cluster member in this way?
If you were building a Java EE PaaS cloud service, would you want to be required
to provide something that starts your service with "java -jar"? Wouldn't you
want to be in charge of starting and stopping your service? Maybe you don't
want to provide a way to run your server outside your own data center?
Maybe we're getting into the realm of things that justify new profiles? Maybe a
new "lightweight container" profile would require "java -jar", only require
support for a single server instance with a single application, and require
support for a specific set of modules?
Again, lots of interesting ideas to talk about in Java EE 9!