On 2018-05-04 4:09 PM, Bill Shannon
wrote:
Next, it wasn't clear to me whether this was formally done so I'd
like to nominate Mike as the chairperson for this group and the
leader of these meetings. Eclipse needs to own and manage the
process we're defining so Mike seems like the right person to lead
this group.
Why thank you. That's an unexpected honor. I need to think about
this a bit.
I'm
still trying to understand whether we're defining a process to
replace the JCP, or whether we're defining a process that can and
will only be used to define the Jakarta EE platform. If the
former, most of the discussion about profiles belongs elsewhere.
And we would need to allow for the possibility that a new spec
would be defined but not included in the Jakarta EE
platform. Think of the Portlet and related specs in the JCP;
would we want to allow for another ecosystem of specs perhaps
related to but not part of Jakarta EE? Expanding the platform to
include every spec ever defined means the platform will grow
without bound, placing a significant burden on vendors that ship
full platform implementations. Making every new thing optional
means they're not really part of the platform because applications
can't depend on them.
I had never quite thought of it that way, but from the perspective
of the Eclipse Foundation we are defining the former: a spec process
to replace the JCP. The initial use case will be Jakarta, but we
have already been approached by projects in other areas of Eclipse
(e.g. IoT) who are interested in also having a formal spec process.
So I believe that this definitely goes beyond Jakarta EE.
Diving
into the profile issue a bit, let me provide some background on
the Web Profile and my opinion on what we should do going
forward...
The Web Profile was primarily a response to the complaints we
heard from developers that Java EE is too big and heavyweight.
(I've never fully understood why Java SE isn't also too big and
heavyweight given that it's much larger than Java EE, but so be
it.) The Web Profile allowed Java EE to compete more directly
with "roll your own" solutions based on (e.g.) Tomcat.
Secondarily, the Web Profile allowed additional vendors to enter
the Java EE ecosystem by lowering the barriers to entry. Given
the consolidation we were seeing in the Java EE vendor space it
seemed important to enable new vendors to enter this space, thus
encouraging competition in this space.
This all made sense in the Java EE 6 timeframe. Since then, my
thinking has evolved. With the introduction, finally, of a module
system in Java SE, it makes more sense to me to address the
complaints of Java EE / Jakarta EE being "heavyweight" by dividing
the platform into modules and allowing users to choose the modules
they need for their application. A vendor would be required to
provide the complete set of modules defined by a platform, but a
user of the vendor's product would consider the product more of a
box of "Lego" bricks from which many different runtimes could be
assembled. Several others said the same thing in the meeting and
in the separate jakarta.ee-community thread.
Profiles define what vendors must provide and thus what things the
brand can be associated with. If there's a different profile for
the different collection of things each vendor wants to provide,
then you've destroyed any value in the platform. Three profiles
is probably fine, five profiles seems like an extreme upper
limit. And I don't think profiles need to be concentric circles.
It was clear in the discussion that there's no agreement on what a
"core" profile would be so I wouldn't even consider that. Again,
profiles are more for vendors than for developers so we need to be
clear what additional vendors are being enabled by the definition
of additional profiles.
All the stuff above is very interesting background, and I agree with
it. In particular I agree with the statements that profiles are for
vendors, and that we need profiles to define platforms.
Profiles should be defined by a separate spec. Defining them in
the platform spec means you have to update the platform spec to
define a new profile. That results in gratuitous updates to the
platform (and corresponding RI and TCK) or the inability to define
a profile based on existing component specs. And while it might
not be a requirement, it seems perfectly reasonable for there to
be a profile TCK that tests the interactions between specs.
Yes.
Finally, I agree that the intent should be to define a collection
of specs that integrate to form a coherent platform. Still,
there's value in being able to use many of the specs
independently. There doesn't need to be a name for each
interesting collection of specs. If the implementations of the
specs all come from a single vendor's Jakarta EE product, then you
know that you're still writing a Jakarta EE application even if
you only use a few of the specs. You can choose just the specs
you need, adding or subtracting based on your application
requirements. If the implementations of the specs come from
multiple vendors and you're assembling them yourself, that's fine,
but that's not Jakarta EE and there doesn't have to be a name for
the collection you assembled. And it's up to you to make sure
they work together.
Yes.
Looking forward to a pointer to Mike's document so I can provide
more direct feedback on it...
I am writing this in an airplane with no wifi (the horror!), but
will be sharing that link shortly. My apologies for the delay.
|