> 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/>
Wow, this would be a complete overturn about how JavaEE specs have always worked so far. There are literally a bunch of specs coming to my mind which always had optional parts init. Starting with CDI (EE parts were only required if those EE features were available already back in CDI-1.0). Then JPA and even JDBC XA support which is fully optional. etc. Is this just managers voting or really people who are also involved in writing the containers as well? LieGrue, strub > Am 13.10.2022 um 23:45 schrieb David Blevins <david.blev...@gmail.com>: > > 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 >>>> >>>> >> >
