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
>>>
>>>
>
smime.p7s
Description: S/MIME cryptographic signature
