I'm not marking this as a draft, because I went through the entire specification and I believe I updated all relevant places. Reviewing that would of course be very much welcome :-) Similarly, any opinions on the open questions in the commit message (copied into the PR description) would also be very much welcome.

Namingwise, "standby" really grates, not just because it's clumsy, but mostly because it is an adjective that is used here as a noun, where its counterparts, "stereotype" and "alternative", are both nouns.

I understand why we can't use "default" and I understand that names are hard. Nevertheless, getting them right in specifications is really important.

Maybe "backstop" (it's a noun, like alternative and stereotype; among its definitions is "something that bolsters")? "Exemplar" ("one that is typical or representative"; mild yuck)? "Template" (not quite right, overloaded meaning, but captures the "starting point" nature of the issue)?

Standby is also a noun, see https://en.wiktionary.org/wiki/standby and many other places. I'm not saying I like it a lot, but I like it a lot more than all other things I could come up with, including "default bean".

Namingwise, "standby" really grates, not just because it's clumsy, but mostly because it is an adjective that is used here as a noun, where its counterparts, "stereotype" and "alternative", are both nouns.

I understand why we can't use "default" and I understand that names are hard. Nevertheless, getting them right in specifications is really important.

Maybe "backstop" (it's a noun, like alternative and stereotype; among its definitions is "something that bolsters")? "Exemplar" ("one that is typical or representative"; mild yuck)? "Template" (not quite right, overloaded meaning, but captures the "starting point" nature of the issue)?

I am aware we have @Default already, but I still find using @DefaultBean much more self explanatory than any of the options discussed so far. Simply because every developer knows what "default" means instantly as we are all aware of default configs and/or other uses which are similar in their nature.

As for proposed names - "Template" I agree is too overloaded to convey clear meaning and "Exemplar" is too close to saying its an "example bean" which is IMO not the case.
"Backstop" is an interesting one - on that note I am also thinking of @BackupBean or perhaps @Backfill.
There is also @FallbackBean which makes sense in CDI sense but clashes with MP FT perception of it.

If we didn't have @Fallback in MicroProfile Fault Tolerance, I would have called this "fallback" in an instant. "Backup" is quite overloaded, but "backfill" seems nice.

(Still hung up on naming.) What if they were called "backing beans"?

(Still hung up on naming.) What if they were called "backing beans"?

That's kind of what I tried suggesting with @Backfill.
"backing bean" seems a tad long to me. Well, anything that goes @{something}Bean feels awkward.

I'll keep thinking. Another problem I have with "standby" is that it sounds like something that could be energized or activated or enabled or switched on at any point for any reason, which isn't really what this is. This is a default—something that is used when other options don't exist or can't work—but we just can't use that word.

Another requirement the name has, if we're trying to keep the spirit of the specification, is something that answers the question, "What kind of bean is this?" (A managed bean, a producer bean, an alternative bean, a synthetic bean….) So I agree with you that in general XYZBean, as some kind of descriptor, if it can be avoided, should be avoided.

What about "failsafe" (as a noun)? Something that keeps the system from breaking when (in this case) nobody else supplied The Thing That Was Supposed To Be There? Then you can talk about failsafes and alternatives in the same sorts of sentences.

What about "failsafe" (as a noun)? Something that keeps the system from breaking when (in this case) nobody else supplied The Thing That Was Supposed To Be There? Then you can talk about failsafes and alternatives in the same sorts of sentences.

Failsafe is way too close to fallback (fault tolerance) IMO; it is another "overloaded" term.
Also, the alternatives are slightly different in behavior and we should highlight that difference if possible so as to avoid confusion.

BTW is there a reason why you don't like @Backfill? I am not a native speaker so just curious if there is something wrong with it.

Failsafe is way too close to fallback (fault tolerance) IMO

OK; I think we agree to disagree on this particular one.

BTW is there a reason why you don't like @backfill? I am not a native speaker so just curious if there is something wrong with it.

Understood. Backfill has connotations of uselessness. It is the stuff—usually material unsuitable for any other purpose—you put back in a hole you just dug.

Failsafe is way too close to fallback (fault tolerance) IMO

OK; I think we agree to disagree on this particular one.

Fair enough,
But note that there are scenarios in which it is perfectly fine to not define any custom bean and just stick with the standby/default one and in such case the fail safe doesn't really fit the meaning for me.
It should really be a "default bean that users can override if need be"
Naming is hard 🤷

BTW is there a reason why you don't like @backfill? I am not a native speaker so just curious if there is something wrong with it.

Understood. Backfill has connotations of uselessness. It is the stuff—usually material unsuitable for any other purpose—you put back in a hole you just dug.

That's the noun meaning, but as a verb it should mean:

to temporarily or permanently fill a position that has become available

Which is what brought my attention to it.

Right; I understand. You asked if there was something wrong with it and the noun version is definitely problematic and its bad connotations would occur to native speakers relatively quickly. Put as slang: it leaves a slightly bad taste in the mouth.

It should really be a "default bean that users can override if need be"

Two words that fit that definition fairly closely are "prototype" and "archetype". ("Archetype" feels more like "example", but something that is a "prototype" can be a thing that makes copies of itself (not how it would be used here), or a default that could be used or extended.)

Example: an archetypal frob is a frob that stands on its own and serves as a worthy example to emulate or override if you wanted, but it's by definition good on its own. Seems pretty close.

Another example: a prototypical frob is a frob that represents an average frob distilled from other frobs out in the world that might impose variations on the prototype. Also sounds pretty close.

A prototype is also something that typically could benefit (and maybe should benefit) from some improvement (i.e. users could supply their own) but could be relied on as-is if there's nothing better. That sounds pretty close.

I'd personally not use prototype, because it is a Spring scope that is very similar to (but not exactly the same as) @Dependent. (I actually have an implementation of the prototype scope in CDI in the ArC test suite. It's quite simple.)

Overall, it is my opinion that the best words (default or fallback) cannot be used, so we gotta settle with something slightly awkward. To me, standby or backfill sound reasonable, as well as spare or reserve. I might also be fine with last resort, but with the ability to use priorities, certain "last resorts" wouldn't really be "last" :-)

I'd personally not use prototype, because it is a Spring scope that is very similar to (but not exactly the same as) @Dependent. (I actually have an implementation of the prototype scope in CDI in the ArC test suite. It's quite simple.)

Overall, it is my opinion that the best words (default or fallback) cannot be used, so we gotta settle with something slightly awkward. To me, standby or backfill sound reasonable, as well as spare or reserve. I might also be fine with last resort, but with the ability to use priorities, certain "last resorts" wouldn't really be "last" :-)

How about @DefaultBean or FallbackBean?

I would prefer a single word that goes well with "bean". If you have to add "bean" to the term itself, you declare defeat :-)

I would prefer a single word that goes well with "bean". If you have to add "bean" to the term itself, you declare defeat :-)

How about Backup?

Backup, Fallback and Default have all three been mentioned earlier and were either discarded later or didn't get any traction. See also #874 (comment)

To me, standby or backfill sound reasonable, as well as spare or reserve.

I really like "Reserve" - something kept back unless it is needed. In some ways it's better than "Default" because having more than one reserve makes sense whereas having more than one default doesn't.

The typesafe resolution steps would then be:

• first look for the highest priority enabled alternative bean
• if there are none, look for a normal bean
• if there are none, look for the highest priority reserve bean

Reading that back, it makes intuitive sense to me.

I'm ok with "Standby" but it has a bit more of a connotation of something ready and waiting to take over a responsibility if something goes wrong, which isn't quite how this feature would work.

Ooh, I very much like reserve. Certainly much, much better than standby. Well done.

@manovotn any thoughts about reserve? :-)

@manovotn any thoughts about reserve? :-)

I think there were better options but reserve is good enough for me.
So if you are OK with it too, I think we have found a name we can agree on :)

@manovotn raised an interesting question on the call today: what about alternative beans declaring reserve producers / reserve beans declaring alternative producers? Have to think more about it, but it feels wrong on the first sight and should probably be a definition error.

what about alternative beans declaring reserve producers / reserve beans declaring alternative producers?

Certainly I am not defending the practice, but my immediate thought was: well, this is ugly and asking for trouble, but it probably should be permitted in some way. What leads you to think it would have to be illegal?

I'm not saying it has to be illegal. I'm saying it should be illegal, because it's probably a user error.

Added an extra commit (to be squashed if agreed upon) that makes it impossible for alternatives (resp. reserves) to declare reserve (resp. alternative) producers.

Just FYI, my force-pushes recently didn't change anything in this PR, I just rebased on latest main.

I agree, so I squashed the two commits. It is my firm belief that alternatives declaring reserve producers and reserves declaring alternative producers is meaningless and should be forbidden. If someone ever comes with a meaningful, well, meaning, we can reconsider.

One more thing: if we allowed alternatives to declare reserve producers (this doesn't apply to reserves declaring alternative producers, but we probably want these to be symmetric), we would have to adjust the ambiguity resolution algorithm, because currently, the algorithm has to remove all beans except alternatives and producers declared by alternatives. These producers currently cannot be reserves, but if they could be, the algorithm would have to eliminate those as well.

Moved back to draft because we need #902 merged first.

Moved back to draft because we need #902 merged first.

This can now be rebased and undrafted @Ladicek

Done.

Last call for comments :-)