Back in September I asked a couple of questions about scanning modules (for annotated classes):
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-September/013178.html Thanks for the answers, which have been helpful, but now a supplementary question/suggestion. Given that many java technologies (not just EE) need to scan jars for annotated classes, is it possible for this to be a semantic provided by the module system? Currently multiple java frameworks are implementing code that asks for lists of modules, then lists of classes within those modules, then finding the raw bytes of those classes and passing them to something like ASM to determine how they are annotated in order to drive their configuration. This code can be rather complex and probably fragile when you consider issues like: - multi release jars (specially as sometimes one JVM might need to process meta data to be deployed on a different java platform) - classpath vs module path vs upgrade paths etc - observable vs resolved vs platform modules - layers - jlink Currently frameworks are having to reimplement much of the logic to determine exactly what classes a JVM will resolve for a given environment. The chances are low of every frameworks getting this right and doing so in a way that is future proof as these features evolve through java 9, 10, 11. So perhaps it would be a good idea for the library to provide some semantics to assist frameworks to get this right? Ideally there would be an API to allow frameworks to query the JVM about what classes (which may not be loaded and may even be for a different target platform) it can see that are annotated in a particular way. thoughts? -- Greg Wilkins <gr...@webtide.com> CTO http://webtide.com
