bean-discovery-mode="annotated-plus-singletons"?

[sixcorners]

Is your feature request related to a problem? Please describe.
Singletons is not a bean-defining annotation. Would be great if they were.

Describe the solution you'd like
If they can't be made bean-defining annotations outright then what do you all think of adding a bean-discovery-mode that includes them?

[Ladicek]

I think we could make @Singleton a BDA in a bean archive that has beans.xml. The issue is, I think, we don't have a well defined concept for such a bean archive.

[sixcorners]

I guess I don't presently have a well defined concept for a bean archive. I thought it was a jar or directory that has a META-INF/beans.xml file.

[manovotn]

I think we could make @Singleton a BDA in a bean archive that has beans.xml. The issue is, I think, we don't have a well defined concept for such a bean archive.

That would be a bit awkward between implicit/explicit archive. That being said, I would love @Singleton to be bean defining. I have always considered it to be the "gotcha" annotation when you operate in annotated mode.
Perhaps we should revisit that idea and see how breaking it would be (i.e. if there are actual usages nowadays where it would clash).

I thought it was a jar or directory that has a META-INF/beans.xml file.

You don't always need beans.xml; in CDI Full there is a concept of implicit bean archive based on just having annotations present, see https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0#bean_archive_full

[Azquelt]

I'm not sure of the background for @Singleton not being a bean defining annotation. I'm guessing it's to do with being part of Jakarta Dependency Injection which is also used by other frameworks like Spring and Guice?

In CDI Full, I think that an option to make Singleton a bean defining annotation would be similar to setting bean-discovery-mode=all and using <trim/>.

Update: It's similar, but not the same. <trim/> allows all types to go through type discovery and have ProcessAnnotatedType events fired, and then removes classes which don't have scope or bean defining annotations. In contrast, making @Singleton a BDA would not change the fact that only classes with a BDA are discovered.

I think we could make @Singleton a BDA in a bean archive that has beans.xml.

Two things bother me about this

• In CDI Full, not having a beans.xml is the same as having one with bean-discovery-mode=annotated or (since CDI 4.0) having a blank one. I'd rather not create an additional difference here.
• The number of different behaviours around beans.xml across different CDI versions and between full and lite is already complex and I'd prefer not to make it more complex.

[Ladicek]

I'm not sure of the background for @Singleton not being a bean defining annotation. I'm guessing it's to do with being part of Jakarta Dependency Injection which is also used by other frameworks like Spring and Guice?

Exactly.

I think we could make @Singleton a BDA in a bean archive that has beans.xml.

Two things bother me about this

• In CDI Full, not having a beans.xml is the same as having one with bean-discovery-mode=annotated or (since CDI 4.0) having a blank one. I'd rather not create an additional difference here.

• The number of different behaviours around beans.xml across different CDI versions and between full and lite is already complex and I'd prefer not to make it more complex.

Agree with the sentiment, but we really shouldn't make @Singleton a BDA in an archive that doesn't contain beans.xml. We've been there (I think that was around CDI 1.2 / 2.0?) and made quite a mess.

[Azquelt]

Agree with the sentiment, but we really shouldn't make @Singleton a BDA in an archive that doesn't contain beans.xml.

I'm in agreement there. The main thing that concerns me is making the presence of a beans.xml file sufficient to make @Singleton a BDA because this would be a change of behaviour in a very common scenario and makes migration to a new CDI version more difficult.

Adding a new option to beans.xml is less worrying to me.

[Ladicek]

Agree with the sentiment, but we really shouldn't make @Singleton a BDA in an archive that doesn't contain beans.xml.

I'm in agreement there. The main thing that concerns me is making the presence of a beans.xml file sufficient to make @Singleton a BDA because this would be a change of behaviour in a very common scenario and makes migration to a new CDI version more difficult.

Makes sense. I'd honestly be in favor of rejecting this issue, as adding another option to beans.xml just to be able to turn @Singleton into a BDA is a big price for relatively small gain.

[manovotn]

Agree with the sentiment, but we really shouldn't make @Singleton a BDA in an archive that doesn't contain beans.xml.

I'm in agreement there. The main thing that concerns me is making the presence of a beans.xml file sufficient to make @Singleton a BDA because this would be a change of behaviour in a very common scenario and makes migration to a new CDI version more difficult.

Makes sense. I'd honestly be in favor of rejecting this issue, as adding another option to beans.xml just to be able to turn @Singleton into a BDA is a big price for relatively small gain.

After the discussion that took place yesterday in the CDI call, I tend to agree with rejecting the issue.
Changing the default behavior to discover singletons would be too disruptive not just because of Jakarta Inject spec being used elsewhere but also for existing CDI code.
The introduction of another opt-in knob does not seem worth it to me as most people wouldn't even know it exists and it is a lot of hassle for little gain (similarly to trim option we have in beans.xml).

[sixcorners]

I think there are spec violating implementations of CDI that make Singleton a BDA right now for what it's worth. Is it a lot of work?

[manovotn]

I think there are spec violating implementations of CDI that make Singleton a BDA right now for what it's worth.

Such as? I don't think they would be passing the CDI TCK but I might be wrong on that account.

Is it a lot of work?

To add the switch? I don't suppose so, it is more so that it won't see much usage as users won't know about it and even today you can simply create a CDI stereotype with @Singleton in it and use that instead - stereotypes are bean defining. And from a user perspective that's just about as much work as setting a beans.xml property 🤷

[sixcorners]

quarkus but they don't promise to follow the spec.

[Ladicek]

I don't think this is tested in the TCK (there's only one occurence of @Singleton and that class also has a stereotype annotation), so ArC (Quarkus) might do this inadvertently even in the strict mode. But the intent of the strict mode has always been to be CDI compatible, so if ArC treats @Singleton as BDA in the strict mode, that's a bug.

It is indeed true that @Singleton is a BDA in the default mode, but that has never intended to strictly follow the CDI specification.

[manovotn]

I don't think this is tested in the TCK (there's only one occurence of @singleton and that class also has a stereotype annotation)

Yes, I too checked this later. And we (actually, you) only added that fairly recently :)

Maybe we are just not seeing the scenario in which this switch would be valuable.
@sixcorners if you don't mind me asking, what exactly is the use case you have? I.e. where would having the opt-in config choice be better/more convenient that using the stereotype?

[Ladicek]

If we really want to do something about this, my personal preference would be to add

@Singleton
@Stereotype
@Retention(RetentionPolicy.RUNTIME)
@interface SingletonScoped {
}

That is a bean defining annotation, specifies the @Singleton scope, and works today. The only thing we might do is to add it to CDI proper.

[manovotn]

If we really want to do something about this, my personal preference would be to add

@singleton
@stereotype
@retention(RetentionPolicy.RUNTIME)
@interface SingletonScoped {
}

That is a bean defining annotation, specifies the @Singleton scope, and works today. The only thing we might do is to add it to CDI proper.

Well, you already know I am +1 for that since I brought that up in the meeting as well :)