Hi David, I guess SE section == SeContainer and not build time (= not runtime server job by design ;)) so I assume the point is "an EE container does not need SE bootstrap classes". There is the same thing in JAXRS AFAIK.
That said the build time API has a challenge: it is not portable between build and run phase so it can NOT be implemented by any container - without repeating it is not needed at all technically, oops I did ;). Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 13 oct. 2022 à 23:46, David Blevins <david.blev...@gmail.com> a écrit : > Thanks Romain and Mark for the insights. Note, if something like this > happens again, let me know. When wearing the day-job hat we do get a vote > on if specs should go final. > > In terms of Jakarta EE 10, it strangely looks like the Jakarta EE 10 > Platform spec is still using CDI 3.0 while the Jakarta EE 10 Core Profile > uses CDI 4.0. Not sure how we'll work that out on the TomEE side. > > The Core Profile spec says CDI lite is required: > > "Jakarta Contexts and Dependency Injection (CDI) 4.0 (CDI Lite > section)" > > > https://jakarta.ee/specifications/coreprofile/10/jakarta-coreprofile-spec-10.0.html#required_components > > Whereas the optional section says there are some classes that are not > required: > > "The Java SE section of the CDI 4.0 specification is not required for > Core Profile > implementations. Only Full CDI implementations are required to support > the (CDI) > Java SE API classes." > > > https://jakarta.ee/specifications/coreprofile/10/jakarta-coreprofile-spec-10.0.html#optional-components > > Do you have any insight as to what "Java SE" classes are excluded and if > that eliminates the need to implement the APIs we don't like? > > Unrelated side note that annoys the heck out of me: the Spec Committee > literally had a vote that no specs could have optional parts (I voted -1 on > that) and then now I'm looking at an "Optional Components" section in the > new Core Profile spec. <face-palm-emoji/> > > > -David > > > > On Oct 13, 2022, at 8:14 AM, Mark Struberg <strub...@yahoo.de.INVALID> > wrote: > > > > To be very clear: imo the CDI-4.0 spec should never have been released > that way. Sorry for the hard words. > > > > The whole part of the 'cdi-lite' is actually not a subpart of CDI but > extends CDI with a (partly vendor specific) build time api. Which is also > not really technically necessary imo. So far Helidon, Meecrowave, > micronaut, etc managed to run on Graalvm quite fine without this api. > > > > Here is my PR which got rejected. It proves that there is no technical > requirement to have all this crap in the same spec api jar! > > https://github.com/jakartaee/cdi/pull/582 < > https://github.com/jakartaee/cdi/pull/582> > > > > > > My personal approach would be the following: > > 1.) Enhance our geronimo-jcdi spec api to include the few new changes > they made to BeanManager etc. > > > > 2.) Take the official cdi api (with the lite parts) and 'extract' those > lite parts into an own jcdi-lite-api.jar > > > > 3.) provide a maven plugin and standard CDI Extension to handle the lite > parts. This is perfectly doable! > > > > 4.) It is even possible to support the whole non-reflection features by > using a dedicated ScannerService etc. > > > > That way almost no code change to OWB would be needed. Almost all of the > changes could be done via an Extension. That way OWB would still remain > quite small and not get as bloated as other implementations. > > > > > > It's actually a shame that those changes got pushed so hard despite a > lot of EG members heavily objecting with good arguments! > > > > LieGrue, > > strub > > > > > > > >> Am 13.10.2022 um 08:25 schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > >> > >> Hi David, > >> > >> It is not about perf but about the cdi "lite" part (build time spec). > >> We explained why it was unecessary technically on cdi bugtracker and > >> requested that at least it was excluded from cdi spec jar and considered > >> another subspec since it is fully unrelated to CDI but it got rejected > by a > >> few pushing their vendor API to the spec. > >> > >> The idea is to not expose an API we'll not support I guess and bundle > >> properly the API. > >> > >> Romain Manni-Bucau > >> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >> <https://rmannibucau.metawerx.net/> | Old Blog > >> <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > >> < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > >> > >> > >> Le jeu. 13 oct. 2022 à 02:47, David Blevins <david.blev...@gmail.com> a > >> écrit : > >> > >>>> On Jun 2, 2022, at 12:03 PM, Mark Struberg <strub...@yahoo.de.INVALID > > > >>> wrote: > >>>> > >>>> I had an idea about how we could implement CDI-4.0 without all the > >>> overhead it brings. > >>> > >>> Can you elaborate on the overhead you're concerned about? (not a > challenge > >>> -- I'm not very familiar with the details yet) > >>> > >>> > >>> -David > >>> > >>> > > > >
