Re: [ee4j-community] Oracle Java EE8 Issue Tracker Abandonment

[Ed Bratt <ed.bratt@xxxxxxxxxx>]

Hi Werner,

The migrated issue for JPA at GitHub is

https://github.com/javaee/jpa-spec/issues/146

... which is closed and includes a link to the JPA community list thread that lead to this conclusion. You can continue this thread either via the issue at GitHub, or https://javaee.groups.io/g/jpa-spec/message/7

-- Ed

PS We did our best to preserve issue IDs as we migrated from Java.Net to GitHub. We also provided cross-reference links at the top Java EE web-page: http://javaee.github.io and http://jpa-spec.java.net does refer on to the current git-hub project page. As with any service discontinuation, when java.net was closed down, the information chain became harder to negotiate. We are sorry for that inconvenience.

On 12/4/2017 4:06 PM, Werner Keil wrote:

Bill,

Thanks for the clarification. It often is indeed hard to find on the JCP pages, although https://jcp.org/aboutJava/communityprocess/mrel/jsr338/index.html clearly states 2.2.

Similar for other JSRs like CDI where only https://jcp.org/aboutJava/communityprocess/mrel/jsr346/index.html

showed the MR was CDI 1.2.

A case of "abandonment" would be this Java.net JIRA ticket for JPA 2.2: https://java.net/jira/browse/JPA_SPEC-146

Is there a follow-up on GitHub by any chance?

Thanks,

Werner

On Tue, Dec 5, 2017 at 12:56 AM, <ee4j-community-request@xxxxxxxxxxx> wrote:

Send ee4j-community mailing list submissions to
        ee4j-community@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        https://dev.eclipse.org/mailman/listinfo/ee4j-community
or, via email, send a message with subject or body 'help' to
        ee4j-community-request@eclipse.org

You can reach the person managing the list at
        ee4j-community-owner@eclipse.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ee4j-community digest..."


Today's Topics:

   1. Re: EE4J Project for annotation scanning?
      (Guillermo Gonz?lez de Ag?ero)
   2. Re: Oracle Java EE8 Issue Tracker Abandonment (Bill Shannon)


----------------------------------------------------------------------

Message: 1
Date: Mon, 04 Dec 2017 21:52:19 +0000
From: Guillermo Gonz?lez de Ag?ero      <z06.guillermo@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] EE4J Project for annotation scanning?
Message-ID:
        <CAG1ZpUYT=nuYg-5_Kd5JFU9M_NB2DZFM3A+u7CgybnNOGKDn8g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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?

El lun., 4 dic. 2017 22:48, Greg Wilkins <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> 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?:
>>
>>> 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> 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
>>>> <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> CTO http://webtide.com
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171204/01b54788/attachment.html>

------------------------------

Message: 2
Date: Mon, 4 Dec 2017 15:52:53 -0800
From: Bill Shannon <bill.shannon@xxxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>,    Alexander
        Salvanos <salvanos@xxxxxx>
Subject: Re: [ee4j-community] Oracle Java EE8 Issue Tracker
        Abandonment
Message-ID: <9c0a98a1-d201-6712-fb97-4c42f1a16b9e@xxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

Alexander Salvanos wrote on 12/ 3/17 01:46 PM:
> Buy the way, I found a mistake on Oracle's site, that states that the JPA
> Specification is on version JPA 2.2, although it is actually JPA 2.1.
> whome have I to call for the issue of the "JPA 2.2" mistake at Oracle's site?
>
It's confusing on the JCP web site, but it *is* JPA 2.2.? Here
<https://jcp.org/aboutJava/communityprocess/maintenance/jsr338/ChangeLog-JPA-2.2-MR.txt>
are the changes to JPA 2.1 that resulted in JPA 2.2.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171204/649157a7/attachment.html>

------------------------------

_______________________________________________
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


End of ee4j-community Digest, Vol 4, Issue 52
*********************************************

_______________________________________________
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