Hi,
I agree with Matej, this is a very good document and starts an important
discussion that we totally need to have: what is CDI Lite in its entirety.
It seems rather obvious to me that the extension model needs to be
different, and we've already started that discussion, but indeed there's
a lot more to debate.
Here are some of my thoughts.
On 20. 10. 20 11:42, Matej Novotny wrote:
> * Bean Metadata
> You describe the need to come up with new, reflection free view of metadata that we could use.
> This is something that we already included in the draft of extension SPI because we came to a similar conclusion; see this[1] link for the model.
> I think we should note it there and point to the PR/issue so that we improve that instead of creating duplicities. We are of course open to suggestions if you see the model unfit.
I think there's an intrinsic conflict: on one hand, the desire to "do
things right", including providing a new metamodel that is free from
reflection; on the other hand, the desire to break compatibility as
little as possible.
The Build Compatbile Extension proposal includes a new metamodel out of
sheer necessity, but whether that needs to be used at runtime, I don't
know. I do think that a big part of the existing runtime model can be
implemented in a build-time architecture, and those places that require
reflection perhaps don't have to be supported in Lite.
In general I think the population of extension writers is a lot smaller
than the population of CDI users, so I'd be willing to break more on the
extension front and less on the user-facing front.
Personally I think there are still times where you may need to evaluate the metamodel at runtime and the important thing is that the metamodel is consistent between what is seen at build time vs what is seen at runtime. An example is an interceptor whereby you would want to evaluate the annotation model of the intercepted method using the same meta model. Having said that I don't think it necessarily needs to be the same API, it just needs to be consistent.
> * Extensibility
> The shape of the extension interface that you came up with is a lot like phases[2] we drafted in the extension SPI PR.
> We are now working to incorporate Graeme's suggestions[3] into it so that it's annotation processor compatible so it will change one way or another.
> However, I suggest you link it in the document and we should make it a joint effort - it looks like there are now three various parties willing to make a dedicates Lite extension SPI.
> So let's try and draft one SPI that works for us all.
Tangent: I'm sorry I went silent on this front, I had some other duties,
but I got back to it this week and I should be able to continue the
conversation in https://github.com/Ladicek/quarkus-fork/pull/7 soon
enough (today or tomorrow).
> Other notes:
>
> * beans.xml handling
> You made beans.xml optional - how do you intend to discover beans and how do you know in which of the dependencies (JARs), do they reside?
> I'd say it's way more practical to instead have beans.xml as a marker file (== ignoring its contents) denoting that a given archive is to be searched for beans.
> That way you can further optimize which archives are to be left alone and which are to be taken into account.
> Though maybe I am just misunderstanding how you intend to perform discovery, could you please elaborate?
Bean discovery is a very interesting topic. If anything, I think we
agree that we only want the "annotated" mode, and that we don't want
anything like multiple bean archives :-)
The rest is ... hard. It seems to me that CDI always assumed that the
container would see the entire world at once (I might be wrong about
that, but at least all existing implementations do that?). But if I
understand correctly, with annotation processors, you'd want to do bean
discovery (and run extensions, and perhaps more) "per partes",
incrementally. That's an interesting constraint and I'm pretty sure that
I myself can't see all the consequences.
But requiring people to modify their JARs, otherwise beans in those JARs
won't be discovered, seems a bit harsh to me. Surely there _is_ a point
in time where you get to see the whole world? (Maven plugin or Gradle
plugin, for example.) This would of course require operating on bytecode
instead of AST, and I can see how you don't want to do that, or at least
minimize that work...
To be clear it is possible to materialize a view of the whole world inside an annotation processor since annotation processors can operate against compiled code, however in general that approach has performance consequences with regards to compilation speeds and incremental compilation since javac has to fuse an AST node from compiled method signatures.
I am not sure it is needed frankly and this is an area where Micronaut and Quarkus differ a great deal in the implementation since Micronaut places additional synthetic byte code and metadata within JAR files of extensions. These are already enhanced and hence don't need to be reprocessed at all by a compiler that has a view of the whole world.
In other words when a user consumes an extension it has already been compiled with the Micronaut compiler extensions and is ready to go and doesn't need to be reprocessed at all by a downstream compilation / bytecode enhancement process.
> * Reduction of scope
> Do you also see some other parts of CDI going away? I can imagine some not-so-used things such as specialization being a good candidate to drop.
> And there is probably more...
I think there are features that are either seldom used and error-prone,
or bad fit for build-time approach, or in retrospect shouldn't be in CDI
in the first place. Things like:
- decorators
- specialization
- session scope
- conversation scope
- passivation
- non-contextual injection
I put together a document with all of CDI APIs and whether they should
or should not, in my opinion, be part of CDI Lite:
https://docs.google.com/document/d/1jS7EbHnyBBvZZxa56LmthKeoixm2FEHmqHwITGRLljQ/edit
It should mostly match the list above.
FWIW I am in general agreement and in favour of a reduction in scope, however if there were a way to continue to allow build time produced extensions to operate at runtime I think that is worth pursuing.
Cheers
> * Extensibility
> You stated that Lite implements only the new variant of extensions (whichever that will be) and that there is an optional module for runtime extensions to add.
> So, how would this optionality work in practice? E.g. would there have to be an impl doing it all? Because I don't think either side would want to consume that implementation.
> AOT approaches would want Lite OFC, but EE servers will require the runtime impl anyway.
> And if there is such impl, it would have to have dual bean metadata - existing model + new one that we both talked about.
> That can lead to a whole lot of undefined behaviour based on which extension changes what metadata and when.
> Not to mention that performing build time extension first means you alter metadata, create synth beans and perform validation. And being at build time, you could even create proxies at this point.
> Running standard ("full") extensions after all that doesn't make much sense as you would have to re-do the whole thing... unless I am missing something.
> I don't have an answer to this situation myself, but when I was pondering this over, I didn't see much use in supporting both simultaneously.
> Can you please elaborate on how do you see the co-existence of both working?
I think the only possible way that might be realistic is to run Build
Compatible Extensions at runtime, together with Portable Extensions.
That is, runtime implementations would still have to be fully runtime. I
think the proposed extension execution phases in Build Compatible
Extensions kinda sorta match the existing lifecycle, but the devil is in
the detail obviously.
LT
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
