Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Scanning specification
Hey guys, 

In case it’s helpful I am happy to provide some insight on Jandex. I originally created the project during WildFly’s inception for optimal annotation scanning. Over time it ended up being more of an offline reflection/introspection system with an emphasis on reduced memory consumption, and optimized index storage, since the target at the time was dynamic runtime deployment. It’s now used in number of other contexts, including the build time offline introspection in Quarkus. 

It is actually designed to support multi-jar indexing (e.g. [1]). The reason base Indexes are intended to be scoped to a single JAR is to adapt to a variety of topologies and support software updates. For example if A.jar depends on B.jar, and you index both and store the index in A.jar, a subsequent update to a newer version of B.jar leads to an invalid index stored in A.  

The expectation is that an application runtime will aggregate these indexes in a way that maps to the class loader strategy utilized in their implementation, and the users packaging approach. CompositeIndex[1] is a simple flat multi-jar example of this. It’s also designed to handle incomplete classpaths (as I am sure you all know is very common in EE deployments where random artifacts get thrown an) and unlike ClassLoaders will support introspection of types with broken/incomplete linkage. 

Regarding API usability, I agree for this use case you want something simpler. For example Jandex utilizes DotNames to reduce memory using a radix tree in place of standard string access. While reasonable for an application server implementation that prioritizes resource usage, a standard EE user won’t care and just wants to lookup things by name without going through an indirection Name type. So an EEish API should probably should just use standard String like the Java reflection API (this is easily mappable to Jandex if internally used).  CDI-Lite’s extension API proposals have done exactly this[2]. Although in this example, it’s a push API based to allow for new CDI implementations that are APT based (e.g. Micronaut)

BTW this is somewhat of a tangent but I think EE10 should consider pruning the complexity of hierarchical deployment architectures (e.g. ears), and the variety of scoping (nested jars tend to share a CL, and wars tend to be isolated). If you go to a standard simple flat deployment model like all users expect, you make your life (and your users) a heck of a lot easier. 

Thanks,
-Jason


On Mar 18, 2021, at 1:46 PM, Thomas Bitonti <bitonti@xxxxxxxxxx> wrote:

+1

Jandex provides an approximate solution, but needs more lightweight ways to access index data.

Requirements become more complicated if the scope of caching becomes larger than a single JAR.

Things get more complicated also if the cache data is to be consistent with what a class loader sees, vs what can be seen working directly with resources.

Thanks!

Thomas F. Bitonti
WebSphere Application Server


<graycol.gif>arjan tijms ---03/17/2021 11:47:32 AM---Of course +1 from me. HK2 and Jandex are both inspirations to start from. In HK2, build-time

From: arjan tijms <arjan.tijms@xxxxxxxxx>
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 03/17/2021 11:47 AM
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Scanning specification
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>




Of course +1 from me. HK2 and Jandex are both inspirations to start from. In HK2, build-time scanning has an important role, and the so-called hk2-inhabitant-generator is often used. See this article from Jonathan that shows this: https://blog.payara.fish/hk2-the-hundred-kilobyte-kernel
Of course +1 from me.

HK2 and Jandex are both inspirations to start from. In HK2, build-time scanning has an important role, and the so-called hk2-inhabitant-generator is often used. See this article from Jonathan that shows this: https://blog.payara.fish/hk2-the-hundred-kilobyte-kernel




On Wed, Mar 17, 2021 at 4:01 PM Thiago Henrique Hupner <thihup@xxxxxxxxx> wrote:
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

Back to the top