Adopt \Doctrine\Common\Annotations\AnnotationReader and deprecate SimpleAnnotationReader forked from Doctrine

The deprecation is a side effect of adopting the new API, so tagging accordingly.

This isn't a 9.0.x-only change (i.e., we should do this in a minor with BC/deprecations/continuous upgrade path), so moving to 9.1.x.

I want to mention another alternative to Doctrine annotation reader.
https://github.com/spiral/attributes
This brings backwards support for PHP 8 attributes, but also supports annotations.
I have not really studied \Doctrine\Common\Annotations\AnnotationReader as an alternative, so can't really advocate for one or the other atm. But I think we do want to move towards towards attributes at some point.

OTOH probably symfony provides newer version as they adopted native attributes

And here some discussion #3223435: Track PHP 8.1 support in hosting and distributions

Btw, one question related to this:
Do we still want to prevent class files from being included during discovery?
That is, do we still need StaticReflectionParser + StaticReflectionClass? Or could we use native reflection instead?

I don't remember why we decided to use StaticReflectionParser in the past, I can think of the following reasons:

• Avoid fatal error when including a class where a parent type is in an optional 3rd party package, that is currently not installed.
• Memory concerns? Perhaps we save opcode memory, but we pay with regular memory for variables used in the parser, I would think.
• Performance concerns? Parsing a file probably is not faster than loading it..

For the first issue, I found the following:

• Since PHP 7.3, we can catch the Error from extends: https://3v4l.org/mch0d
• Since PHP 7.4 we can catch the Error from implements: https://3v4l.org/0VPev

@donquixote I think the memory and performance concerns are still valid. The Doctrine StaticReflectionParser (that we now adopted into core in #3180351: doctrine/reflection is abandoned) has an optional optimisation when we only want to read class docblocks, this avoids parsing most of the PHP.

Once we are on a minimum of PHP 8 we can start migrating to native attributes, but we still might want a faster/cheaper way of parsing these than loading all the code.

Memory concerns? Perhaps we save opcode memory, but we pay with regular memory for variables used in the parser, I would think.
Performance concerns? Parsing a file probably is not faster than loading it..

I bet in a light of JIT -dopcache.jit_buffer_size=20M it will be faster to load

Moreover core could benefit from preload and so on
- #3108687: Compatibility with/take advantage of code preloading in PHP 7.4
- #2218651: [meta] Make Drupal compatible with persistent app servers like ReactPHP, PHP-PM, PHPFastCGI, FrankenPHP, Swoole

Memory concerns? Perhaps we save opcode memory, but we pay with regular memory for variables used in the parser, I would think.

Seems I am wrong here.
The variables from the parser can be wiped after each file, assuming we don't cache them in memory. The memory for PHP opcode stay during the entire process/request.

(However, with preload or whatever, as mentioned by @andypost, if we assume that the opcode is already in memory all the time, that would be ok)

As for performance:

• For annotations, we already need to parse the use statements, so there is little to gain from using native reflection.
• For attributes in PHP < 8, we again need a parser for use statements, the class declaration, and attributes. So again we perhaps gain little from using native reflection.
  (As a benefit, we can add forward support for advanced attributes syntax (e.g. objects in arg values).)
• For atrributes in PHP 8+, we can fully rely on native reflection, with whichever benefit that might bring (to be determined).
  (However, we will be stuck with whatever is supported in that version of PHP, because PHP will always parse it when loading the file, and fatal out: https://3v4l.org/T5n3n.)

There's related issue which also raised few concerns #2919424: Deprecate annotations, one of the four plugin discovery approaches

But I don't want to deprecate annotations :)
Unless moving to attributes qualifies as that.

As core 10 requires PHP 8.1 it looks more promissing

For atrributes in PHP 8+, we can fully rely on native reflection, with whichever benefit that might bring (to be determined).
(However, we will be stuck with whatever is supported in that version of PHP, because PHP will always parse it when loading the file, and fatal out: https://3v4l.org/T5n3n.)

it's fixed in PHP 8.1 - so no longer a blocker

PS: Symfony also faced it but it's hard to change it in 6.0

Probably #3252386-104: Use PHP attributes instead of doctrine annotations and next comments will cause a split or meta

Given the requiring PHP 8.1 for Drupal 10 means that using attributes instead of annotations is possible I think we should close this issue as we won't do this.