Maybe a back-burner.. and will be a problem if updating from Java EE 8. And not just Sling, almost every javax based framework will get affected.
Seems Spring has about 2545 javax imports [image: Screen Shot 2019-05-08 at 3.22.59 PM.png] Thanks Suren On Wed, May 8, 2019 at 3:04 PM Konrad Windszus <[email protected]> wrote: > IMHO there is one other use case which is javax.activation.PostConstruct ( > https://jira.apache.org/jira/browse/SLING-7312 < > https://jira.apache.org/jira/browse/SLING-7312>) used from Sling Models. > But I agree with Carsten that we should not think about this yet, as long > as there is no definite plan what happens to that annotation in the > future... > > Konrad > > > On 8. May 2019, at 21:58, Carsten Ziegeler <[email protected]> wrote: > > > > I guess the only hard dependency Sling has is on the servlet API, we > might use some other javax specs here and there. > > > > But, there are no concrete plans yet and I don't think its worth > speculating. On the other hand, this might only get problematic for Sling > (or any other project) if a) a an update of a specification is produced > using the new namespace and b) someone wants to use it in combination with > Sling (or any other project using the old namespace). Creating new > specifications and adaption usually takes some time, and we can look at it > when/if it happens - and maybe it turns out that by that time the answer is > easy and poses no problems. > > > > > > Regards > > > > Carsten > > > > > > Suren Konathala wrote > >> Most of you may have been following the news/updates on the usage > "javax". > >> There's lot of discussions and nothing concrete yet. But wanted to know > how > >> much of Sling core will be affected and maybe start planning > proactively? > >> - Eclipse foundation announcement > >> > https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ > >> - Proposals from Eclipse Foundation > >> https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html > >> Thanks > >> Suren > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > [email protected] > >
