I understand where Adam in is coming from in terms of simplicity - I have wrestled with how to accommodate multiple profiles and simplicity as well. I do not think, however, that supporting multiple profiles makes for an inherently more complex platform. On the contrary.
If Jakarta EE can define a Core of absolutely necessary technologies (e.g. CDI) than profiles, which are, by design, interoperable with the core and other profiles can be defined and used as needed.
I like to think of the Core as the abstract class (sorry functional purists but I’m going OO on this analogy) and the profiles as interfaces that can be optionally implemented by vendors. The vendor implements a concrete version of the Core, the behavior of which is strictly specified and certified, and then zero or more of the profiles. When a profile is specified we ensure that the TCK for that profile requires interoperability with the Core and if all profiles work as specified with the Core than they will work together without compatibility issues. For the first time, we have full control of the specifications and - just as importantly - the TCKs.
The Core + Profiles approach allows the platform to evolve according to the needs of the industry instead of according to the needs of any one problem domain. Right now everyone is saying that SOAP-based web services are dead so we should ditch that, but in 2004 that opinion would have been viewed as moronic. What technologies today do we feel are critical that will be obsolete in 10 years? We don’t know. Profiles give us the flexibility to support technology and problem domains without constraining the platform as a whole.
1. From the usability, dev experience, we should aim for as few profiles as only possible.
My selling point for Java EE in the past was the simplicity. There was only one choice -- the Full Profile -- (there were no measurable advantages of WebProfile, so we never used that) what was appreciated by the developers. There were no unique "snow lake" project in the past what was good for long term maintenance and corporate developers self support. With the "one dependency" idea, even startups used Java EE with the "time to market" advantage. There was no evals or dependency fiddling. We started with use case implementation at the day one.
2. From the runtime vendor perspective, modular platform is easier to maintain, develop and is good for the ecosystem. So vendors should modularize the Java EE platform as far as it is useful. However this should be an internal implementation detail.
IMO we should have one "main profile" which comprises similar functionality to the "full profile" in Java EE (of course without SOAP :-)) which should cover the 80% of the main use cases. This profile could be implemented as a BOM (micropofile does that, what is really convenient to use).
Exceptional usecases (e.g. scenarios like NetFlix with 10k of microservice instances) could be covered by specific profiles.
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
