Skip to main content
Breadcrumbs
Date: 2024-01-30
Present:
- Jan Westerkamp (iJUG)
- Arjan Tijms (OmniFish)
- James Perkins (Red Hat)
- Jim Krueger (IBM)
- Ed Burns (MSFT)
- Emily Jiang (IBM)
- Dmitry Kornilov (Oracle)
- Petr Aubrecht (Payara)
- Brian Stansberry (Red Hat)
- Tanja Obradovic (Eclipse Foundation)
- Scott Marlow (Red Hat)
- Riva T Philip (IBM)
- Majid Mostafavi (IranianJUG)
- Scott Stark (Red Hat)
- Ed Bratt (Oracle)
- Cesar Hernández (Tomitribe)
- John Clingan (Red Hat)
Agenda and Minutes
- JEA-289-request-progress-review-ballott
- See d537ee.
- Jan Westerkamp
- From an implementation perspective, we need to verify that 21 is also tested.
- There is a risk that component specs, because they have a choice to do 17 or 21, instead of 17 and 21, may have late-discovered problem when we do the platform testing toward the end of the release cycle.
- Ed proposed this remedy
- Stay on top of them to see if they can do the 17 and 21 testing.
- If a component spec is not able to do the non-mandatory 17 and 21 testing, offer help to do this testing.
- Emily yes, this is documented and agreed already.
- Tom Watson
- Again, this is identical to the 11/17 for EE 10 (now 17/21 for EE 11)
- Emily mentioned one possible interpretation of https://www.eclipse.org/projects/efsp/?version=1.3 compels us to produce a new milestone release.
- Ed observes that the process experts, Paul and Wayne, did not mention this. Therefore, Ed will proceed to comply with the existing request as shown in JEA-289 and cross this bring if we come to it.
- Brian Stansberry had a different reading about us being compelled.
- [Brian] This came from the more ‘flexible’ language in https://jakarta.ee/committees/specification/guide/#progress
- That language references the efsp language Emily linked, but otoh somewhat contradicts it (e.g. the projects “are not ready for a release yet”). Although ‘milestone build’ and ‘release’ are different terms, so I think Emily’s interpretation is the better one.
- JEA-279-GlassFish-as-ratifying-compatible-implementation Jakarta Data help
- Confirm that Data can be reasonably implemented entirely based on existing primitives from Persistence and/or JDBC.
- See discussion comment in the issue. Most important point: the need to get a “project” started to host collaboration for a Data impl that GlassFish can use. This is where the “chip in” work happens.
- Date review
- Risk factors
- REST 3.2
- Progress being made is towards 3.2 that deprecates @Context injection, however Dmitry passed along a comment from Jan Supol that Jersey may not be able to find a clear way forward to allow Jersey to be a 3.2 impl. The stakeholders are engaged.
- Concurrency
- Issue open in the spec to change the API to
- Remove javadoc references, hard coding instead
- Some of that is held up about what is the 17 behavior when the user says virtual: true.
ACTION: Nathan, put a link to this issue. \
Here is the issue where we could use more feedback in deciding the Java 17 behavior: \
https://github.com/jakartaee/concurrency/pull/415
- CDI
- Action to comply with the formerly known as CDI EE idea will also be taken in time for the 2024-02-29 release review.
- Jakarta Validation and Records status
- The M2 release is ready that has some aspects of this. The “new of a record” thing is obviously not possible to perform validation.
- They have what they plan to do for EE. For the most part, “records just work”.
- Jakarta Concurrency and Virtual Threads
- Overview of change to strategy vis a vis Java 17
- Arjan: GlassFish will be doing a multi-release JAR to make this happen. Unclear how this will work in the server, it compiles, it runs the test, have not yet integrated in the server.
Beyond Jakarta EE 11 (if time allows)
Back to the top
