[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] EE4J Project for annotation scanning?

On 04/12/17 21:52, Guillermo GonzÃlez de AgÃero wrote:
> Thanks a lot Greg. Would be interesting to see how other people expect
> to tackle this for the time being.
> 
> Do any other vendors here expect to support native Java 9 modules in the
> short term?

Tomcat is approaching this in much the same way as Jetty. We've extended
our annotation scanning code to include modules and multi-version JARs
but we expect users to find issues as they start to make greater use of
modules.

Mark


> 
> El lun., 4 dic. 2017 22:48, Greg Wilkins <gregw@xxxxxxxxxxx
> <mailto:gregw@xxxxxxxxxxx>> escribiÃ:
> 
> 
>     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 <mailto: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
>         <mailto:gregw@xxxxxxxxxxx>> escribiÃ:
> 
>             FYI I've created a draft JEP
>             <https://github.com/jetty-project/annotation-discovery/blob/master/JEP-Proposal.md>
>             and begun a discussion on it in openjdk-discuss
>             <http://mail.openjdk.java.net/pipermail/discuss/2017-December/004644.html>.
> 
>             cheers
> 
>             On 1 December 2017 at 22:54, reza_rahman
>             <reza_rahman@xxxxxxxxx <mailto: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
>                 <mailto:gregw@xxxxxxxxxxx>>
>                 Date: 11/30/17 7:23 AM (GMT-05:00)
>                 To: EE4J community discussions
>                 <ee4j-community@xxxxxxxxxxx
>                 <mailto: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
>                 <http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-November/013362.html>Â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
> 
>                       * 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?
> 
> 
>                 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-detection
> 
> 
>                 Greg 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?
> 
>                 -- 
>                 Greg Wilkins <gregw@xxxxxxxxxxx
>                 <mailto:gregw@xxxxxxxxxxx>> CTO http://webtide.com
> 
>                 _______________________________________________
>                 ee4j-community mailing list
>                 ee4j-community@xxxxxxxxxxx
>                 <mailto: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
> 
> 
> 
> 
>             -- 
>             Greg Wilkins <gregw@xxxxxxxxxxx <mailto:gregw@xxxxxxxxxxx>>
>             CTO http://webtide.com
>             _______________________________________________
>             ee4j-community mailing list
>             ee4j-community@xxxxxxxxxxx <mailto: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 <mailto: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
> 
> 
> 
> 
>     -- 
>     Greg Wilkins <gregw@xxxxxxxxxxx <mailto:gregw@xxxxxxxxxxx>> CTO
>     http://webtide.com
>     _______________________________________________
>     ee4j-community mailing list
>     ee4j-community@xxxxxxxxxxx <mailto: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
>