HI,
As a Java EE developer, I have some idea to share. personally I think current status of Micro profile is not bad.
We have to consider there are a lot of enterprise applications, they work well.
I hop there is a base profile(maybe Web profile), then two profiles have their own missions: one for cloud native applications(light weight containers, such as Quarkus, etc), and one for traditional enterprise applications(run in the traditional application servers, such as GF, Wildfly , Open Liberty etc.
So I hope there are two routes is OK for me.
1. base profile-> Cloud native profile(maybe the new MicroProfile)
2. base profile-> Enterprise profile(maybe the new Enterprise Profile)
(3.base profile-> Full Profile(includes 1, 2))
For adopting new features, I think a sandbox/incubator mechanism is required, provides public preview(allow changes, and incompatibility) more frequently. Application server vendors can provide it in its products, and developers can response against it before it is frozen and finalized in the spec.
I noticed there are a lot of discussion about replacement of EJB. Personally, I do not think EJB is bad, for enterprise applications, it is a great choice. Like the `@Transactional`, make some EJB components work without EJB is good, such as schedule, mdb, lock etc.
As mentioned in former messages, why Spring/SpringBoot is the first choice of the Java newbie, personally, I have written a lot of Spring applications. For developers, it is easy to start a new application, it is easy to configure, run , and also easy to test using the popular test engine.
For Jakarta EE 10, I've read the plan and proposals, it is good. There are some points from my mind.
1. Erasing the gap between all specs is vital, united the IOC/Dependency Injection, Global exception handler, the new security context(instead of the one in EJB, jaxrs, webservice, etc), deprecating the duplicated the APIs as soon as possible.
2. Friendly configurations for different environments, easy to inject configuration values via `@Inject`, _expression_ language in annotation attributes etc.
3. Provides the configurations by programmatic approaches, esp the JMS configurations, like Spring `@Configuration`, configure everything(DataSources, Servlet WebApp Configuration, FacesConfig, JAXRS ResourceConfig, JPA EntityManagerFactory, JMS Connection Factory/Queue, Topic/JMSContext, etc ) via CDI `@Produces`.
4. Simplify the usage of JMS, provides more generic message sending and receiving, such as `JMSContext.send(a queue bean, message payload, acknowledge)`, and receive via CDI `@Observes`, easy to bridge messages to SSE, WebSocket, etc.
5. United application lifecycle events, can be listened by
CDI `@Observes`, like Spring. In my before experience, I encountered some issues like EJB, JPA initialization in different orders in some application servers which caused EJB `@Singleton` intiailzer does not work as expected.
6. Draft an embedded container SPI to vendors, and providing a portable API to developers to boot an embedded container in a single line code(possible to run application via main method, like Spring Boot), allow developers to package the application with container in a single jar. Simplify the testing container bootstrap and usage of Arquillian., easy to mock and replace some of beans when testing in container, etc.
