| Re: [ee4j-community] EE4J Project for annotation scanning? |
Guillermo,We've already implemented much of it in eclipse jetty, but:+ we keep discovering edge cases we didn't think of and can't work out from the scant documentation+ It's almost certainly wrong in many ways, as we've had to make a lot of guesses.+ it's tightly integrated with our resource abstraction and not really separable.Consider it a proof of principle... where the principles are that we don't really know what to do, don't really want to do it in the first place, certainly don't want to maintain it all on our own and fully expect to discover that other containers have interpreted things differently.I expect we'll continue to implement our own solution short/mid term as we have a current need. But want to work on a collaborative effort to eventually replace it with something that collaborative, correct and maintained into the future in parallel with the JVM.cheers_______________________________________________On 4 December 2017 at 22:32, Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:Great, thanks Greg! Btw, do you already have a working independent library for doing this annotation scanning on module path? Or is it still WIP?El sáb., 2 dic. 2017 10:05, Greg Wilkins <gregw@xxxxxxxxxxx> escribió:_______________________________________________On 1 December 2017 at 22:54, reza_rahman <reza_rahman@xxxxxxxxx> wrote:As you noted, this is primarily needed in EE ecosystem solutions. I think you should consider starting this within EE4J only as a last resort. The best place is within OpenJDK if they will have it. That said, there is a rich history already of technologies moving from Java EE to Java SE (though that history has gotten much more sparse in more recent years for good and not so good reasons).Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone-------- Original message --------From: Greg Wilkins <gregw@xxxxxxxxxxx>Date: 11/30/17 7:23 AM (GMT-05:00)To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>Subject: [ee4j-community] EE4J Project for annotation scanning?All,The eclipse jetty project has been progressively implementing java 9 support for features such as multi release jars and modules. It is a surprisingly complex area and has resulting in many discussions on the various JDK dev lists. One such recent conversation in jigsaw-dev has resulted in the suggestion that we start a project for annotation scanning that may eventually be proposed as new API for a future JVM. My question is, should/could that project be started under EE4J?The key parts of the conversation are:Greg Wilkins wrote: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
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.
- jlink
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?Alan Bateman wrote:This was listed in the JSR 376 requirements document [1] but it didn't happen in Java SE 9. There were suggestions at the time to generate an index at packaging time. There were also suggestions (and some initial prototyping with a jlink plugin) to index at link time. I don't think the efforts got as far as thinking about an API.
So yes, it is an area where there is interest but I'm not aware of anyone working on it just now. If you or others have cycles to create a library and explore the area then it could be useful.
-Alan
[1] http://openjdk.java.net/projects/jigsaw/spec/reqs/#efficient-annotation-detectionGreg Wilkins wrote:Not so sure we have a lot of cycles, but the eclipse jetty project is already burning cycles now to implement, so in the long run it may be better to put in a few more cycles to make this logic generally accepted.I'm wondering if perhaps I should suggest as a new project within the eclipse EE4J effort, as that will capture interest, expertise and cycles from several frameworks that could benefit. If successful, it might then live there long term, but I think contribution to a future java platform would be a better home for it as it would benefit from being part of future considerations.The unimplemented jigsaw requirement says:Efficient annotation detection — It must be possible to identify all of the class files in a module artifact in which a particular annotation is present without actually reading all of the class files. At run time it must be possible to identify all of the classes in a loaded module in which a particular annotation is present without enumerating all of the classes in the module, so long as the annotation was retained for run time. For efficiency it may be necessary to specify that only certain annotations need to be detectable in this manner.So that given a lot of projects (Servlet, JPA, CDI, Spring etc.) are all currently struggling to implement annotation scanning under java9, is there scope for common effort? Could it be done under EE4J? Or maybe just another toplevel Eclipse project?thoughts?--
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
--
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
--
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community