On Fri, Feb 6, 2015 at 9:30 PM, Bill Shannon <bill.shannon_at_oracle.com>
wrote:
> 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>
> 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.
>
I'm not saying to modularize it now. I'm sayinh Java EE 8 should take first
steps for modularization : having one single central container and
mandating specification to have an SPI, is a first step I think. Also
starting to think of a lifecycle of events that go through each provider.
>
> 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?
>
As you know, there is no cluster defined in Java EE (
http://antoniogoncalves.org/2014/11/21/there-is-no-cluster-in-java-ee/).
Most of my customers don't use clusters, they use hundreads of single
stateless instances that need to start quickly. And again, looking at the
future of IoT, we should first focus on starting a single instance vs
clustering.
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?
>
Profiles will disapear once we decide that each spec has an SPI, can be
orchestrated through a single Container API and follows a defined
lifecycle. Then, we will be able to bundle whatever specs together and
create our own Java EE Container (such as creating our own JDK in the
future).
>
> Again, lots of interesting ideas to talk about in Java EE 9!
>
Yes, but in my point of view, Java EE 8 should start creating the building
blocks. For me, SPIs + a well defined Container API and event lifecycle
would be great. Java EE is mostly about adding new specifications. I think
we should also look at our internal : the way it should be structured to
get an homogenize platform.
--
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>