Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Scanning specification
There was a JEP proposal from Greg Wilkins (Eclipse Jetty Lead) to the OpenJDK to introduce such a feature at the JVM level.
Sadly, it didn't go very far within the OpenJDK group.

Perhaps some of this discussion could be framed a bit better from that proposal?
Concepts that perhaps we are not thinking of (yet)?

https://github.com/jetty-project/annotation-discovery/blob/master/JEP-Proposal.md


On Thu, Mar 18, 2021 at 5:47 PM Thomas Bitonti <bitonti@xxxxxxxxxx> wrote:

Hi,

What we found in Open Liberty has been:

* Initial consumption of class and annotations data uses simple queries, generally:
** What are the classes which have a specified annotation, e.g., what classes have WebServlet as a class annotation.
** What is the implementation hierarchy of a particular class.

* Cache data must include inheritance and qualifier information in addition to the basic annotations data. (This additional data is contained within Jandex indexes.)

* Using JARs as the unit of index generation and of index composition works well. In particular, that enables the sharing of indexes between different consumers of the data (for example, Servlet, WebService, or CDI), each which may want to compose the indexes differently.

* For complete inheritance data, a listing of specific unresolved class references (mostly, superclass and interface references) is needed. Open liberty index composition has a final step of chasing down unresolved class references in the external references class loader.

* When working with Web Modules, composition requires the labeling of index data as being from a metadata-complete or omitted from absolute ordering regions of the web module. This is an ugly but unfortunate consequence of how different processing consumes the data.

Using a simplified API means that initial processing is able to use just a subset of the Jandex index data. (Open Liberty wrote a custom, lightweight reader, specifically to read the subset data.) This means that "Info" objects don't need to be instantiated, and, within Open Liberty, that Jandex string instances can be placed with Open Liberty managed strings.

(Use of a simplified API also enables the creation of a secondary layer of caches, which would be a cache of query results. For scenarios where there is a fixed "scan and process" phase, the queries which are performed should be fixed, with the result that subsequent starts could rely on there being complete query cache data, which would in turn could completely avoid the need to load indexes. This seems to be, in effect, what new very lightweight server implementations are doing, with the query results being embedded into a server image as code.)

Thomas F. Bitonti
WebSphere Application Server


Inactive hide details for Jason Greene ---03/18/2021 05:22:05 PM---Hey guys, In case it’s helpful I am happy to provide someJason Greene ---03/18/2021 05:22:05 PM---Hey guys, In case it’s helpful I am happy to provide some insight on Jandex. I originally created t

From: Jason Greene <jason.greene@xxxxxxxxxx>
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 03/18/2021 05:22 PM
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Scanning specification
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>




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
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

[1] https://docs.wildfly.org/jandex/org/jboss/jandex/CompositeIndex.html
[2] https://github.com/Ladicek/StillDI
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev



_______________________________________________
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