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