[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-community] A Composable Platform Over Profiles
|
On Tue 18-05-01 19:02, Michael Remijan wrote:
> I argue that a better approach would be to define the platform as a palette of composable standards[1]
I completely support this but I don't think it takes it far enough. For an "enterprise" standard to survive in the coming years, I think it must become more "Spring like" meaning the standard must become a framework of libraries which development teams can import into their application in any combination they see fit. I truly believe if JakartaEE continues to develop specifications for a *server*, then it won't survive the coming years. Organizations just don't move their servers fast enough. They are slow to upgrade existing servers and forget about moving to a different EE server. Organizations typically are OK with updating libraries and frameworks - they don't care what's running inside the server - just as long as they don't need to update the server itself. It's not uncommon for me to see the latest and greatest frameworks and libraries shoehorned into 10+ year old EE servers because organizations can't move on their server technology. Granted, this is not all organizations. But, it is a huge appeal of Spring being able to bring in new features without server updates.
I think Java EE was going that way already. Do we have a list of
"library enabled" specs vs main() started container only specs?
Library enabled:
* CDI
* Bean Validation
* JPA
* <add your own>
Container only specs:
* <Add your own>
The second problem you raise is a way to mix and match different
versions of the specs together. I personally would love us to explore
such option. Note that Spring also has limits into what different
versions of "spec/products" they support but it is definitely loser
than what we are offering in Java EE.
One problem is the sig tests which would have to be significantly
relaxed in how we define compatibility.
Emmanuel Bernard
Chief Architect, Data
Red Hat
