Jakarta EE Backlog -> Guide to Jakarta EE 10

[Reza Rahman]

Folks,

As you are aware, Ondro and I have began to draft a guide to Jakarta EE 10 contribution now that Jakarta EE 9 is winding down. A large part of this is outlining what people 
could help contribute to as part of a backlog. Ryan and I started just such a backlog a little bit ago: https://docs.google.com/document/d/1uZFBoIujXCc-gQhCzh_ZdlKEsrsV0yVVIHzBTI3usF8/edit?usp=sharing.

We would like to start some discussion on this backlog now. I don't think every possible change, detail or idea needs to be hashed out right now. It is likely best to focus
on headline features more likely to attract people.

Ideally we should try to close this discussion by next weekend. Please do chime in. Once we stabilize this conversation we can focus on drafting the contribution guide.
 

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

[Reza Rahman]

Just a reminder that I would like to wrap this up by next weekend and begin authoring the actual guide. There has been some discussion, but it would be good to have more.

Here is the draft link again: https://docs.google.com/document/d/1uZFBoIujXCc-gQhCzh_ZdlKEsrsV0yVVIHzBTI3usF8/edit?usp=sharing.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

[Vano Beridze]

Hello,

I would add this issues to the list:

1. JAX-RS add uniform API for multipart/form-data

2. @RolesAllowed for JAX-RS resources

3. JPA - enrich JPQL, for instance allow sub-select in select to avoid writing native queries.

4. JPA native queries pick up schema from orm.xml

5. JPA native queries use named parameters

6. Introduce standard for distributed caching. Today we have JCache, Hazelcast, Infinispan, Redis. We need to have standard for memory storage which is cluster aware and synchronized.

7. Multitenancy. On the JPA level at first.

Kind regards,

Vano Beridze 

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee...@eclipse.org
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

[arjan tijms]

Hi,

On Wed, Jun 17, 2020 at 6:50 PM Vano Beridze <vanu...@gmail.com> wrote:

2. @RolesAllowed for JAX-RS resources

Maybe not so much needed as JAX-RS resources will be deprecated in favour of it all being CDI beans, and then the Jakarta Security API will define a CDI/Interceptor based @RolesAllowed.

Kind regards,

Arjan

 

[Tom Jenkinson]

Are there any common themes for Jakarta EE 10 defined yet?

_______________________________________________

[Steve Millidge (Payara)]

It’s not been defined yet.

 

For me some starter general themes I would have at the platform level would be;

 

1. Alignment with the CDI component model across all specifications
2. Updates for JDK 11 capabilities
3. Further build out annotation support for resource definition

 

After that it’s individual spec themes over and above those 3 and addition of new specs if they are ready.

 

Steve

[Kevin Sutter]

Another item that needs addressing in Jakarta EE 10 is the "support" of JPMS, whatever that means...  Whatever type of JPMS integration that we end up supporting needs to be cognizant of the other existing module systems, namely OSGi and RH's module system.


---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail:  sut...@us.ibm.com     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter

To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community_______________________________________________

jakarta.ee-community mailing list
jakarta.ee...@eclipse.org
To unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

[Ryan Cuprak]

 In terms of support for JPMS, one thing I would like to see, is the ability to use Jakarta EE APIs/implementations in an applications that is using JPMS. 

A while back I tried to create a demo Java SE app using CDI (Weld) and jlink. It was a nightmare. Most of the dependencies didn’t have module-infos and some of the jar names of dependencies weren’t compatible with automatic module names (transitive dependency).

I would like to see the ability to at least use EE components (JPA/CDI/etc) in a Java SE JPMS application. 

Not being too familiar with OSGi, could we include module definitions for both? 

-Ryan

--
You received this message because you are subscribed to the Google Groups "Jakarta EE Ambassadors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jakartaee-ambass...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/OF812018F0.8A32A06C-ON8625858B.0051A6FC-8625858B.0051FE1F%40notes.na.collabserv.com.

[arjan tijms]

Hi,

On Fri, Jun 19, 2020 at 1:12 AM Ryan Cuprak <rcu...@gmail.com> wrote:

Not being too familiar with OSGi, could we include module definitions for both?

Most every component already contains at least OSGi definitions since both GlassFish and Open Liberty depend on these. There's an extra header in the MANIFEST.MF for the JPMS automatic module name. Some components started to use that, but I think most are still waiting for an official guidance from the platform for that. I haven't tried JPMS much, so I don't know how much module-info will conflict or not.

Kind regards,

Arjan

 

[Ryan Cuprak]

 The entry in MANIFEST.MF is so that the automatic module name isn’t generated from the JAR file name. This enables you to start modularizing before all of the dependencies are modularized etc.

 The module-info.java and OSGi configurations should be able to co-exist. Unless you load a dependency on the module-path, the module-info is ignored. 

 I would like to see Jakarta EE dependencies provide a module-info so that you could use them in a modularized Java SE application. I don’t think it makes sense to say that JPMS is the module system to be used by containers (would wreak havoc). 

 Note: I don’t think I was the one that added JPMS to the list so I don’t mean to speak for whoever added it.

-Ryan 

[Ryan Cuprak]

 You mention Java 11, is Jakarta EE only going to target the LTS releases? 

 I could see the APIs locked to an LTS release. However, with Jakarta EE, could the platform say that containers must support Java 11 and have timely support for newer Java versions (unless the next LTS) within a period of time (a month for example). I’d like some sort of guarantee that I am not stuck on a release of Java for 3 years. 

 -Ryan

[Reza Rahman]

This is a good idea indeed. I think it would help attract people to engage and begin contributing in some way. Once discussion stabilizes over the weekend, I will try to put in some (unofficial) themes in our guide.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

[Reza Rahman]

Thanks for bringing forward the discussion. My thoughts embedded below. I hope others will chime in too.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

On 6/17/2020 12:50 PM, Vano Beridze wrote:

Hello,

I would add this issues to the list:

1. JAX-RS add uniform API for multipart/form-data

Is this really a salient/common enough scenario to add in the document? I may have done a poor job explaining the document, but at this point I think we just want to list out major realistic features likely to get a broader range of developers excited and interested in at least tracking Jakarta EE 10 if not contributing. This one feels to me like a feature that probably is not "headline worthy" but still important enough to consider as an enhancement. What do you think? I certainly would encourage you to pursue this in the Jakarta REST project regardless.

2. @RolesAllowed for JAX-RS resources

Is this really needed separate from the possibilities outlined in the document for the Security API? What do you think?

3. JPA - enrich JPQL, for instance allow sub-select in select to avoid writing native queries.

This makes a lot of sense and one I have heard often from folks. I'll generalize/abstract this as "Add more SQL features in JPQL/Criteria API such as sub-select, WITH clause..."

4. JPA native queries pick up schema from orm.xml

Can you kindly explain this a bit?

5. JPA native queries use named parameters

Is this also too minor to think of as a major possibility to highlight? Again, I certainly would encourage you to pursue this in the Jakarta Persistence project regardless.

6. Introduce standard for distributed caching. Today we have JCache, Hazelcast, Infinispan, Redis. We need to have standard for memory storage which is cluster aware and synchronized.

I would like to think what others think of this. While in principal I would love to see JCache move to Jakarta, in practical terms, will this actually happen in terms of IP transfer? If not, maybe it is best to leave this out?

7. Multitenancy. On the JPA level at first.

What do others think about this? The reason I ask is that this feature was abandoned fairly quickly in Java EE 7 and no provider seems to implement it since then. How likely is this to happen?

[Josh Juneau]

Certainly, I would like to see only JDK 11 and forward being supported, although I know that may be a blocker for some. 

I definitely agree with modernizing the TCKs to use JUnit5/Arquillian.  I also think it may be a good idea to have a standard testing API as part of the platform. 

Josh Juneau
june...@gmail.com
http://jj-blogger.blogspot.com
https://www.apress.com/us/search?query=Juneau

On Jun 18, 2020, at 8:25 PM, Reza Rahman <reza_...@lycos.com> wrote:



--
You received this message because you are subscribed to the Google Groups "Jakarta EE Ambassadors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jakartaee-ambass...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/8c3aa88a-ff3a-c580-9220-24036d1a5702%40lycos.com.

[Kito Mann]

Is JAX-RS going to require CDI? I'm not sure that's a good idea. Some frameworks use those annotations without any DI. 

Kind regards,

Arjan

 

--
You received this message because you are subscribed to the Google Groups "Jakarta EE Ambassadors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jakartaee-ambass...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/CAE%3D-AhAcjnx3jvZ%3DvY7EwFWzCC6pigC60-59WS-g10yrdyEGPA%40mail.gmail.com.

[reza_rahman]

I believe the idea is to use CDI when it is available and possible. So it is more "supports" than "requires". However, best to clarify this with folks like Markus.

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

[Werner Keil]

Isn't there a @RolesAllowed in Jakarta Security and the idea would be to deprecate it in Jakarta REST in favor of that?

If Security needed a little more modularity or a "light" module where Authentication or Authorization may not always be required, I guess that is also something to explore.

Werner 

On Fri, Jun 19, 2020 at 5:47 PM reza_rahman <reza_...@lycos.com> wrote:

I believe the idea is to use CDI when it is available and possible. So it is more "supports" than "requires". However, best to clarify this with folks like Markus.

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------

From: Kito Mann <kito...@virtua.com>

Date: 6/19/20 11:39 AM (GMT-05:00)

To: arjan tijms <arjan...@gmail.com>

Cc: Jakarta EE Ambassadors <jakartaee-...@googlegroups.com>, Jakarta EE community discussions <jakarta.ee...@eclipse.org>

Subject: Re: [jakarta.ee-community] [jakartaee-ambassadors] Re: Jakarta EE Backlog -> Guide to Jakarta EE 10

_______________________________________________

[arjan tijms]

Hi,

On Fri, Jun 19, 2020 at 5:53 PM Werner Keil <werne...@gmail.com> wrote:

Isn't there a @RolesAllowed in Jakarta Security and the idea would be to deprecate it in Jakarta REST in favor of that?

If Security needed a little more modularity or a "light" module where Authentication or Authorization may not always be required, I guess that is also something to explore.

Both Authentication and Authorization are very small SPIs, and they are exactly meant for vendors to implement a few things of so that Jakarta Security works on whatever environment. Something like say MP JWT takes about the same to implement from scratch as Jakarta Authentication or Authorization (I know, since I implemented all three ;)).

Kind regards, 

Arjan Tijms

 

[Andy McCright]

> Is JAX-RS going to require CDI? I'm not sure that's a good idea. Some frameworks use those annotations without any DI. 

Yes, the plan is for JAX-RS to require CDI.  See https://github.com/eclipse-ee4j/jaxrs-api/wiki/Roadmap

JAX-RS 3.1 - PLANNED - (Q2 or Q3 2020) - Java SE Bootstrap API. Deprecating @Context: Implementors MUST provide CDI; applications MAY use CDI....

and

JAX-RS 4.0 - PLANNED (2021) - Removing @Context: Applications MUST use CDI

Can you elaborate on the drawbacks to using CDI?  The footprint (in general) should not increase since JAX-RS has its own DI framework - it's this framework that causes conflicts and increased footprint in environments where both JAX-RS and CDI are used.  By removing JAX-RS's DI framework and delegating injection to CDI, this should reduce footprint and complexity - both for vendors and users.

Thanks, 

Andy  

[Kito Mann]

Hello Andy,

Thanks for the clarification. I see what you're saying. I guess the key thing is that I'd want it to be implemented in such a way that end users don't have to use CDI. 

I'm specifically thinking of frameworks like DropWizard, which, although they use JAX-RS annotations, the general programming model does not use any DI. Even though I personally prefer a CDI-based programming model, I think it's important to allow the community to build frameworks that use JAX-RS and don't have a CDI-based programming model.

___

Kito D. Mann | @kito99 | Java Champion | Google Developer Expert | LinkedIn

Expert training and consulting: PrimeFaces, PrimeNG, JSF, Java EE, Web Components, Angular

Virtua, Inc. | virtua.tech 

+1 203-998-0403

* Enterprise development, front and back. Listen to stackdpodcast.com.

[reza_rahman]

In general honestly I agree. One of the key reasons Jakarta EE still remains relevant despite all its challenges is because it has always made an effort to try to empower a broader ecosystem where it can. The bellwether for me is the likelihood of Spring users integrating the API. If that likelihood is high, we should try to avoid making CDI a hard requirement. Why not continue to support @Context as a fallback to CDI in environments where CDI is not available?

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------

From: Kito Mann <kito...@virtua.com>

Date: 6/27/20 12:22 PM (GMT-05:00)

To: Jakarta EE community discussions <jakarta.ee...@eclipse.org>

Cc: Jakarta EE Ambassadors <jakartaee-...@googlegroups.com>

Subject: Re: [jakarta.ee-community] [jakartaee-ambassadors] Re: Jakarta EE Backlog -> Guide to Jakarta EE 10

[arjan tijms]

Hi,

On Sat, Jun 27, 2020 at 6:33 PM reza_rahman <reza_...@lycos.com> wrote:

In general honestly I agree. One of the key reasons Jakarta EE still remains relevant despite all its challenges is because it has always made an effort to try to empower a broader ecosystem where it can. The bellwether for me is the likelihood of Spring users integrating the API. If that likelihood is high, we should try to avoid making CDI a hard requirement.

I'm not sure, don't Spring users have Spring MVC?

 

Why not continue to support @Context as a fallback to CDI in environments where CDI is not available?

I wonder if some of these environments actually use Jakarta REST, or whether they don't just use Jersey? I might be mistaken, but I think DropWizard falls more into the Jersey category.

Also, the problem I'm seeing is that environments that didn't have JAX-RS available, made JAX-RS available by adding (say) Jersey. Likewise, JAX-RS uses bean validation, so environments that didn't have that available added bean validation. Internally, Jersey uses HK2. Again, environments that didn't have HK2 available (which I dare assume to say is most of them) added HK2.

As far as I know, it hasn't been common to ask for Jersey not using HK2 anymore and provide a fallback for (say) Spring. 

I'm curious why then CDI (say Weld) is so much different? Is there actually a technical reason for this, or is something else?

Kind regards,

Arjan Tijms

 

--

You received this message because you are subscribed to the Google Groups "Jakarta EE Ambassadors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jakartaee-ambass...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/5ef774de.1c69fb81.4f77f.5ea6SMTPIN_ADDED_MISSING%40gmr-mx.google.com.

[m.reza.rahman]

The real truth is probably that the perception problems you are alluding to has to do with the hypercompetitive nature of our industry. That's why CDI is seen as being more "contentious" than things like REST/@Context, Persistence and Servlet. Nonetheless, it is an ecosystem reality we should probably try to respect when possible. The risk of not doing so is limiting the adoption of these technologies and thus really becoming more of a de-jure standard rather than something that is both a de-facto standard and an open standard/specification.

To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/CAE%3D-AhB4Osjha1_APgr18JkW9mX%2B0F8Z46ozXwYSbfeFDBJEzw%40mail.gmail.com.

[Kito Mann]

Well said, Reza. +1

To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/5ef77e19.1c69fb81.2acb.a78a%40mx.google.com.

[arjan tijms]

Hi,

I hear you, though in this particular case it might not be such a problem. If Jersey can use HK2 under the covers, then why not CDI?

I wonder if the average DropWizard user is even aware that Jersey uses HK2 under the hood. It's surely not something the environment has to supply very explicitly (Jersey 2.26+ made this a little more explicit, but only a little more).

It becomes more interesting even given the plans of Payara to move HK2 into a full CDI implementation. What then? Jersey will then already use CDI under the hood as well, and, probably, still without DropWizard users being much aware of that.

Kind regards,

Arjan

[Thomas Andraschko]

spring even supports @Inject, so no reason to not remove @Context

[Thomas Andraschko]

spring even supports @Inject, so no reason to not remove @Context

reza_rahman <reza_...@lycos.com> schrieb am Sa., 27. Juni 2020, 18:33:

In general honestly I agree. One of the key reasons Jakarta EE still remains relevant despite all its challenges is because it has always made an effort to try to empower a broader ecosystem where it can. The bellwether for me is the likelihood of Spring users integrating the API. If that likelihood is high, we should try to avoid making CDI a hard requirement. Why not continue to support @Context as a fallback to CDI in environments where CDI is not available?

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------

From: Kito Mann <kito...@virtua.com>

Date: 6/27/20 12:22 PM (GMT-05:00)

To: Jakarta EE community discussions <jakarta.ee...@eclipse.org>

Cc: Jakarta EE Ambassadors <jakartaee-...@googlegroups.com>

Subject: Re: [jakarta.ee-community] [jakartaee-ambassadors] Re: Jakarta EE Backlog -> Guide to Jakarta EE 10

[Kito Mann]

Good points, Arjun. And that's what I was hoping -- that it's more of an implementation detail for Jersey as opposed to a requirement for creating an endpoint. For example, in DropWizard apps, you use JAX-RS annotations, but to register your resource, you actually do it imperatively:

    final HelloWorldResource resource = new HelloWorldResource(
        configuration.getTemplate(),
        configuration.getDefaultName()
    );
    environment.jersey().register(resource);

So there's no use of @Named or anything; you create and initialize the object via its constructor.

___

Kito D. Mann | @kito99 | Java Champion | Google Developer Expert | LinkedIn

Expert training and consulting: PrimeFaces, PrimeNG, JSF, Java EE, Web Components, Angular

Virtua, Inc. | virtua.tech 

+1 203-998-0403

* Enterprise development, front and back. Listen to stackdpodcast.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/CAE%3D-AhAx6H4PD7Tzx011%3D60_aR-sbMpm6CL4XwO4j8weP-J1kA%40mail.gmail.com.

[werne...@gmail.com]

Maybe at least deprecate @Context and remove it with the next major version.

As Jakarta EE 10 aims to use JDK 11 as the minimum version (or at least 9 otherwise the JPMS won't work) this can also be annotated via @Deprecated.

Werner

[Santiago Pericas-Geertsen]

Reza,

 The reason for switching to CDI is that there are currently two competing DI’s in Jakarta REST and there are many edge cases where these do not happily co-exist. Moreover, the CDI integration itself isn’t perfect because of backward compatibility constraints. It is generally a bad idea to have multiple APIs that overlap like these, and this is one of those cases. 

 I can understand the argument that CDI may provide more than what is necessary (at least for Jakarta REST) but that can be solved by modularizing CDI rather than continuing to support multiple DI’s for different use cases. CDI goes far beyond dependency injection, and for many Jakarta REST applications the rest (no pun intended) isn’t needed. 

 I hope it is clear that we are not talking just about two annotations (@Inject vs. @Context) but the semantics around them (including scopes, bean initialization, etc). By dropping the @Context-based DI, things can be simplified and edge cases eliminated. 

— Santiago

On Jun 27, 2020, at 12:33 PM, reza_rahman <reza_...@lycos.com> wrote:

In general honestly I agree. One of the key reasons Jakarta EE still remains relevant despite all its challenges is because it has always made an effort to try to empower a broader ecosystem where it can. The bellwether for me is the likelihood of Spring users integrating the API. If that likelihood is high, we should try to avoid making CDI a hard requirement. Why not continue to support @Context as a fallback to CDI in environments where CDI is not available?