Re: Apache Tomcat 10 and Jakarta EE 9 - an update
On 24/01/2020 10:29, Mark Thomas wrote: > Hi all, > > There has been a fair amount of progress made both towards a Tomcat 10 > release and Jakarta EE 9 since my State of the Cat talk at ApacheCon EU > in October. For those of you that haven't seen it is is on YouTube: > https://www.youtube.com/watch?v=hfgO6R9o5Tw > > In order to update the Tomcat community there will be a webinar next > week on Thursday 30th at 14.00 UTC. Joining details are below. > > The meeting will be recorded and uploaded to YouTube afterwards. Links > will be posted once that is done. As promised. https://www.youtube.com/watch?v=Vwj0XG-4Nos Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Apache Tomcat 10 and Jakarta EE 9 - an update
Hi all, There has been a fair amount of progress made both towards a Tomcat 10 release and Jakarta EE 9 since my State of the Cat talk at ApacheCon EU in October. For those of you that haven't seen it is is on YouTube: https://www.youtube.com/watch?v=hfgO6R9o5Tw In order to update the Tomcat community there will be a webinar next week on Thursday 30th at 14.00 UTC. Joining details are below. The meeting will be recorded and uploaded to YouTube afterwards. Links will be posted once that is done. Topics planned to be covered include: - The Tomcat 10 release plan - Scope for Jakarta EE 9 - Schedule for Jakarta EE 9 - Progress towards Tomcat 10 - Progress towards Jakarta EE 9 (APIs, spec docs, TCKs) Hope to see you there. Mark = Webinar Joining Details = Topic: Apache Tomcat 10 and Jakarta EE 9 Time: Jan 30, 2020 14:00 London Join Zoom Meeting https://pivotal.zoom.us/j/124753263 Meeting ID: 124 753 263 One tap mobile +16699006833,,124753263# US (San Jose) +16468769923,,124753263# US (New York) Dial by your location +1 669 900 6833 US (San Jose) +1 646 876 9923 US (New York) 877 853 5257 US Toll-free 855 880 1246 US Toll-free Meeting ID: 124 753 263 Find your local number: https://pivotal.zoom.us/u/ajUQ3fLCY Join by SIP 124753...@zoomcrc.com Join by H.323 162.255.37.11 (US West) 162.255.36.11 (US East) 221.122.88.195 (China) 115.114.131.7 (India Mumbai) 115.114.115.7 (India Hyderabad) 213.19.144.110 (EMEA) 103.122.166.55 (Australia) 209.9.211.110 (Hong Kong) 64.211.144.160 (Brazil) 69.174.57.160 (Canada) 207.226.132.110 (Japan) Meeting ID: 124 753 263 Join by Skype for Business https://pivotal.zoom.us/skype/124753263 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta EE 9
Am 28.10.2019 um 22:07 schrieb Michael Osipov: Am 2019-10-28 um 22:00 schrieb Stefan Mayr: Am 28.10.2019 um 14:13 schrieb Rémy Maucherat: On Mon, Oct 28, 2019 at 1:46 PM Johan Compagner wrote: Hi On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: Hi all, A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For those of you who aren't familiar with Jakarta EE the key points are: - Oracle have donated Java EE to Eclipse - Eclipse have released Jakarta EE 8 which is essentially identical to Java EE 8 - Oracle have refused to allow changes to the APIs in the javax namespace - The Jakarta EE community seem to be reaching consensus on releasing Jakarta EE 9 which will rename all the Java packages from javax.* to jakarta.* what does this rename really mean? import javax.servlet.http.HttpSession; import javax.websocket.Session; those are renamed? If that is yes that would mean pretty much everything will break? https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ I thought everyone knew about this. We were supposed to have a session on this rename at ApacheCon EU, but unfortunately it didn't happen. Rémy This article mentions that javax.* package namespace is not allowed to change. The API needs to remain compatible. When javax.* is renamed to jakarta.* it should be sufficient to have a javax.* shim library that translates everything to use jakarta.*. Or is there any public information that Oracle prohibits that too? This will only work if the API won't change. I consider such a shim to be dangerous at some point in time. Michael Time is the right cue: having both namespaces would allow a transition phase. The javax shim could (or should!) trigger a deprecation warning. And I hope the API won't change too soon. It would be good for the Jakarta EE acceptance if they keeping existing interfaces stable for some time. - Stefan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta EE 9
Am 2019-10-28 um 22:00 schrieb Stefan Mayr: Am 28.10.2019 um 14:13 schrieb Rémy Maucherat: On Mon, Oct 28, 2019 at 1:46 PM Johan Compagner wrote: Hi On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: Hi all, A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For those of you who aren't familiar with Jakarta EE the key points are: - Oracle have donated Java EE to Eclipse - Eclipse have released Jakarta EE 8 which is essentially identical to Java EE 8 - Oracle have refused to allow changes to the APIs in the javax namespace - The Jakarta EE community seem to be reaching consensus on releasing Jakarta EE 9 which will rename all the Java packages from javax.* to jakarta.* what does this rename really mean? import javax.servlet.http.HttpSession; import javax.websocket.Session; those are renamed? If that is yes that would mean pretty much everything will break? https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ I thought everyone knew about this. We were supposed to have a session on this rename at ApacheCon EU, but unfortunately it didn't happen. Rémy This article mentions that javax.* package namespace is not allowed to change. The API needs to remain compatible. When javax.* is renamed to jakarta.* it should be sufficient to have a javax.* shim library that translates everything to use jakarta.*. Or is there any public information that Oracle prohibits that too? This will only work if the API won't change. I consider such a shim to be dangerous at some point in time. Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta EE 9
Am 28.10.2019 um 14:13 schrieb Rémy Maucherat: > On Mon, Oct 28, 2019 at 1:46 PM Johan Compagner > wrote: > >> Hi >> >> >> >> On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: >> >>> Hi all, >>> >>> A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For >> those >>> of you who aren't familiar with Jakarta EE the key points are: >>> >>> - Oracle have donated Java EE to Eclipse >>> - Eclipse have released Jakarta EE 8 which is essentially identical to >>> Java EE 8 >>> - Oracle have refused to allow changes to the APIs in the javax namespace >>> - The Jakarta EE community seem to be reaching consensus on releasing >>> Jakarta EE 9 which will rename all the Java packages from javax.* to >>> jakarta.* >>> >>> >> >> what does this rename really mean? >> >> import javax.servlet.http.HttpSession; >> import javax.websocket.Session; >> >> those are renamed? >> If that is yes that would mean pretty much everything will break? >> > > https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ > I thought everyone knew about this. We were supposed to have a session on > this rename at ApacheCon EU, but unfortunately it didn't happen. > > Rémy > This article mentions that javax.* package namespace is not allowed to change. The API needs to remain compatible. When javax.* is renamed to jakarta.* it should be sufficient to have a javax.* shim library that translates everything to use jakarta.*. Or is there any public information that Oracle prohibits that too? Regards, Stefan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta EE 9
On Mon, Oct 28, 2019 at 3:53 PM i...@flyingfischer.ch wrote: > Am 28.10.19 um 15:39 schrieb Mark Thomas > >> If this is going to be disruptive and we cannot maintain compat, why > >> not > >> go the extra step and explicitly move Tomcat code to > >> org.apache.tomcat.* > >> for Tomcat 10? Git renames will work flawlessly for backports. > > It will break things for users that code against those APIs. It is a > small number but some do. > > > > Mark > Do you have any evidence based number on this matter? May be in turns > oout that this "small number" isn't as small as assumed... > > Of course, it's actually rather huge: - Anyone using Tomcat embedded - Anyone having written a custom Catalina component - Anyone using a library with a Tomcat integration - Anyone using a framework that embeds Tomcat The rationale is that the jakarta change is already breaking compatibility, and thus to go all in. But I don't share that opinion, it's simply easier to explain to users that there's a single change: rename javax.servlet (and the others) to jakarta.servlet. Plus there might be tools or deployment tricks to do that magically in most cases, while there would likely be nothing for Tomcat package changes. Rémy
Re: Jakarta EE 9
On October 28, 2019 2:53:29 PM UTC, "i...@flyingfischer.ch" wrote: >Am 28.10.19 um 15:39 schrieb Mark Thomas >>> If this is going to be disruptive and we cannot maintain compat, why >>> not >>> go the extra step and explicitly move Tomcat code to >>> org.apache.tomcat.* >>> for Tomcat 10? Git renames will work flawlessly for backports. >> It will break things for users that code against those APIs. It is a >small number but some do. >> >> Mark >Do you have any evidence based number on this matter? May be in turns >oout that this "small number" isn't as small as assumed... Only a sense based on experience of issues raised when we have previously changed the internal API - usually between major versions. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta EE 9
Am 28.10.19 um 15:39 schrieb Mark Thomas >> If this is going to be disruptive and we cannot maintain compat, why >> not >> go the extra step and explicitly move Tomcat code to >> org.apache.tomcat.* >> for Tomcat 10? Git renames will work flawlessly for backports. > It will break things for users that code against those APIs. It is a small > number but some do. > > Mark Do you have any evidence based number on this matter? May be in turns oout that this "small number" isn't as small as assumed... Markus - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta EE 9
On Mon, Oct 28, 2019 at 3:11 PM Michael Osipov wrote: > Am 2019-10-28 um 14:59 schrieb Mark Thomas: > > On October 28, 2019 12:37:14 PM UTC, Johan Compagner < > jcompag...@servoy.com> wrote: > >> Hi > >> > >> > >> > >> On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: > >> > >>> Hi all, > >>> > >>> A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For > >> those > >>> of you who aren't familiar with Jakarta EE the key points are: > >>> > >>> - Oracle have donated Java EE to Eclipse > >>> - Eclipse have released Jakarta EE 8 which is essentially identical > >> to > >>> Java EE 8 > >>> - Oracle have refused to allow changes to the APIs in the javax > >> namespace > >>> - The Jakarta EE community seem to be reaching consensus on releasing > >>> Jakarta EE 9 which will rename all the Java packages from javax.* to > >>> jakarta.* > >>> > >>> > >> > >> what does this rename really mean? > >> > >> import javax.servlet.http.HttpSession; > >> import javax.websocket.Session; > >> > >> those are renamed? > >> If that is yes that would mean pretty much everything will break? > > > > Correct. Hence the question on options for how we consider maintaining > compatibility. > > If this is going to be disruptive and we cannot maintain compat, why not > go the extra step and explicitly move Tomcat code to org.apache.tomcat.* > for Tomcat 10? Git renames will work flawlessly for backports. > > I assume that most users never knew or don't understand where "catalina" > comes from. > There's no reason to break APIs just for the sake of it (and the current package structure looks relatively reasonable to me, catalina is the actual container, coyote is the connector, jasper is Jasper). This is really like "oh, this is going to be a pain for users, so while we're at it let's destroy the rest". At this point I think the differences with the current 9 should be as limited as possible to avoid user problems. If more significant items get included such as, let's say, APR removal or some similar feature that wouldn't be backported to 9, then it should be limited to these items and it justifies the branch being called "10" rather than "9.something". Rémy
Re: Jakarta EE 9
On October 28, 2019 2:11:22 PM UTC, Michael Osipov wrote: >Am 2019-10-28 um 14:59 schrieb Mark Thomas: >> On October 28, 2019 12:37:14 PM UTC, Johan Compagner > wrote: >>> Hi >>> >>> >>> >>> On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: >>> >>>> Hi all, >>>> >>>> A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. >For >>> those >>>> of you who aren't familiar with Jakarta EE the key points are: >>>> >>>> - Oracle have donated Java EE to Eclipse >>>> - Eclipse have released Jakarta EE 8 which is essentially identical >>> to >>>> Java EE 8 >>>> - Oracle have refused to allow changes to the APIs in the javax >>> namespace >>>> - The Jakarta EE community seem to be reaching consensus on >releasing >>>> Jakarta EE 9 which will rename all the Java packages from javax.* >to >>>> jakarta.* >>>> >>>> >>> >>> what does this rename really mean? >>> >>> import javax.servlet.http.HttpSession; >>> import javax.websocket.Session; >>> >>> those are renamed? >>> If that is yes that would mean pretty much everything will break? >> >> Correct. Hence the question on options for how we consider >maintaining compatibility. > >If this is going to be disruptive and we cannot maintain compat, why >not >go the extra step and explicitly move Tomcat code to >org.apache.tomcat.* >for Tomcat 10? Git renames will work flawlessly for backports. It will break things for users that code against those APIs. It is a small number but some do. Mark > >I assume that most users never knew or don't understand where >"catalina" >comes from. > >Michael > >- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta EE 9
On Mon, Oct 28, 2019 at 1:15 PM Mark Thomas wrote: > Hi all, > > A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For those > of you who aren't familiar with Jakarta EE the key points are: > > - Oracle have donated Java EE to Eclipse > - Eclipse have released Jakarta EE 8 which is essentially identical to > Java EE 8 > - Oracle have refused to allow changes to the APIs in the javax namespace > - The Jakarta EE community seem to be reaching consensus on releasing > Jakarta EE 9 which will rename all the Java packages from javax.* to > jakarta.* > - Jakarta EE 9 will not contain any other API changes > - It will be a requirement to maintain backwards comparability (maybe not > 100% compatibility) with Jakarta EE 8 > - Jakarta EE 9 will be released in the next ~11 months > - Jakarta EE 10 will then follow which is where new features will be > introduced > > This raises various questions for the Tomcat community including: > > 1. Do we implement Jakarta EE 9? > > Assuming yes to q1. > +0.1 > > 2. As Tomcat 10 or some other version? > I'm not convinced yet by using 10 for that since EE 9 is functionally equivalent. > > 3. How do we manage development (in a branch, as master, ...)? > I would say master. > > 4. How do we implement backwards compatability? Runtime, deploy time, > compilation time? > I have no idea how this would realistically be achieved at the moment. To run on jakarta, the most problematic are libraries and frameworks and it seems difficult to me to think it is really possible to hack our way in at runtime. Deployment, I don't know, so you seem to believe BCEL is a possibility. > > 5. At what point do we EOL Tomcat 7? (since Jakarta EE 9 is just a package > renaming?) > We should mandate that, except for the jakarta package rename changes and/or functionality, all commits to that master should be backported to 9.0 (no exceptions). Keeping 7 is possible, but it means more work. > > 6. Do we commit to supporting Tomcat 9 for an extended period? (to provide > a version that supports java.* directly) > I would be in favor of that as a mirror of that new branch, since it would be hard to guarantee zero issues for "legacy" javax.* webapps, which will basically continue to exist forever. > > I'm posting this to users@ as how Tomcat users want to use and adopt > Jakarta EE 9 is likely to be the biggest driving factor in choosing answers > to these questions. > > We don't have to have all of the answers right now. I think we do need > answers for 1 & 3 so we can start. A few options and 'wait and see' is > likely good enough for the rest for now. > > I have my own views on the answers but I have tried not to express them > here so we can get as wide a discussion as possible. > > Thoughts? > Rémy
Re: Jakarta EE 9
Am 2019-10-28 um 14:59 schrieb Mark Thomas: On October 28, 2019 12:37:14 PM UTC, Johan Compagner wrote: Hi On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: Hi all, A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For those of you who aren't familiar with Jakarta EE the key points are: - Oracle have donated Java EE to Eclipse - Eclipse have released Jakarta EE 8 which is essentially identical to Java EE 8 - Oracle have refused to allow changes to the APIs in the javax namespace - The Jakarta EE community seem to be reaching consensus on releasing Jakarta EE 9 which will rename all the Java packages from javax.* to jakarta.* what does this rename really mean? import javax.servlet.http.HttpSession; import javax.websocket.Session; those are renamed? If that is yes that would mean pretty much everything will break? Correct. Hence the question on options for how we consider maintaining compatibility. If this is going to be disruptive and we cannot maintain compat, why not go the extra step and explicitly move Tomcat code to org.apache.tomcat.* for Tomcat 10? Git renames will work flawlessly for backports. I assume that most users never knew or don't understand where "catalina" comes from. Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta EE 9
On October 28, 2019 1:11:46 PM UTC, Christopher Schultz wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA256 > >Mark, > >On 10/28/19 08:15, Mark Thomas wrote: >> Hi all, >> >> A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. >> For those of you who aren't familiar with Jakarta EE the key points >> are: >> >> - Oracle have donated Java EE to Eclipse - Eclipse have released >> Jakarta EE 8 which is essentially identical to Java EE 8 - Oracle >> have refused to allow changes to the APIs in the javax namespace - >> The Jakarta EE community seem to be reaching consensus on releasing >> Jakarta EE 9 which will rename all the Java packages from javax.* >> to jakarta.* - Jakarta EE 9 will not contain any other API changes >> - It will be a requirement to maintain backwards comparability >> (maybe not 100% compatibility) with Jakarta EE 8 - Jakarta EE 9 >> will be released in the next ~11 months - Jakarta EE 10 will then >> follow which is where new features will be introduced >> >> This raises various questions for the Tomcat community including: >> >> 1. Do we implement Jakarta EE 9? >> >> Assuming yes to q1. >> >> 2. As Tomcat 10 or some other version? >> >> 3. How do we manage development (in a branch, as master, ...)? >> >> 4. How do we implement backwards compatability? Runtime, deploy >> time, compilation time? >> >> 5. At what point do we EOL Tomcat 7? (since Jakarta EE 9 is just a >> package renaming?) >> >> 6. Do we commit to supporting Tomcat 9 for an extended period? (to >> provide a version that supports java.* directly) >> >> I'm posting this to users@ as how Tomcat users want to use and >> adopt Jakarta EE 9 is likely to be the biggest driving factor in >> choosing answers to these questions. >> >> We don't have to have all of the answers right now. I think we do >> need answers for 1 & 3 so we can start. A few options and 'wait and >> see' is likely good enough for the rest for now. >> >> I have my own views on the answers but I have tried not to express >> them here so we can get as wide a discussion as possible. > >How "simple" of a replacement are we talking about, here? For example, >can it be done simply with sed? Probably not. JSPs are likely to be more complicated. The XSDs are probably not an issue. Request attributes and similar may need to support both javax.* and jakarta.* names for attributes. The detail is TBD. >$ find . -type f | xargs sed -e 's/javax.servlet/jakarta.servlet/g' > >? > >I'm asking because if it really is that easy, then we should be able >to trivially package each of the existing Tomcat 7, 8.5, 9 releases as >7.jakarta, 8.5.jakarta, and 9.jakarta alongside their legacy Java EE >versions. That only works if users can have separate Tomcat instances for javax.* based apps and jakarta.* based apps. My sense is that that will not be an acceptable option for all users. >Users wanting to move to the Jakarta EE namespace can do so with >existing, reliable versions of Tomcat instead of waiting for Tomcat 10 >or Tomcat having to implement some kind of hybrid version which >supports BOTH flavors of APIs (which seems kind of nightmarish to me). A runtime solution to compatibility would not be my first choice. I'm currently learning towards a BCEL based solution(or simikar) at deployment time. >Are there any restrictions against us supporting Jakarta EE in >existing Tomcat releases? Naming could be an issue. There might also be some very minor API changes as well as the package rename. That would make that tricky. Mark > I don't believe so. We merely advertise >support for various standards; Tomcat is no longer the "reference >implementation" of any APIs so we can do whatever we want, right? > >If we do a simply sed-style re-naming of packages to produce parallel >releases, will they actually work? My sense is that, yes, they will >indeed work. > >- -chris >-BEGIN PGP SIGNATURE- >Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > >iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl226RIACgkQHPApP6U8 >pFjnfQ//bYExvm+BEhwroa/W+v3BGx+Bw0qtzz9MxjDIZ1zcGuxlITb1QdoYZ1sz >C9eQumSo/gK1sO8ImVhMCYdFOf1n2az/olcMdF2v9gYC3YMZ11+qQhppYRxvfRvG >pHzkV4PHbE6mgvfY9pli6LBs1Na1MSN0nRLluC4OBz3wMGCLQyByfBX3x+++8klB >HHM1wcJDLzziIBmM3NKcuEFQ1gVbjlV10rFYes29KiuG4z78FRPY87pQmP+Xj71o >l5NEtERYA+SjDGPZo6wrF6k3l23cZL/yrCp4PGwO1c0VB148DervvWG33+9OEOQL >1E8F0IZc2o2eiNYUxbUQcMxGXORnfbWpMyG8RVSVlwdhmzO4Ug1pxNVcpO2Y2qC2 >vHHz+deQiQ/dZIsNU5aWtC+MBL7tx3RWxBNxb3n2d5T9tJm6zHBSdGfcPyTN14cV >HTtPj9al4usxoT3XGSEhAP7FiI1RJX
Re: Jakarta EE 9
On October 28, 2019 12:37:14 PM UTC, Johan Compagner wrote: >Hi > > > >On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: > >> Hi all, >> >> A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For >those >> of you who aren't familiar with Jakarta EE the key points are: >> >> - Oracle have donated Java EE to Eclipse >> - Eclipse have released Jakarta EE 8 which is essentially identical >to >> Java EE 8 >> - Oracle have refused to allow changes to the APIs in the javax >namespace >> - The Jakarta EE community seem to be reaching consensus on releasing >> Jakarta EE 9 which will rename all the Java packages from javax.* to >> jakarta.* >> >> > >what does this rename really mean? > >import javax.servlet.http.HttpSession; >import javax.websocket.Session; > >those are renamed? >If that is yes that would mean pretty much everything will break? Correct. Hence the question on options for how we consider maintaining compatibility. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta EE 9
On Mon, 28 Oct 2019 at 14:13, Rémy Maucherat wrote: > On Mon, Oct 28, 2019 at 1:46 PM Johan Compagner > wrote: > > > Hi > > > > > > > > On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: > > > > > Hi all, > > > > > > A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For > > those > > > of you who aren't familiar with Jakarta EE the key points are: > > > > > > - Oracle have donated Java EE to Eclipse > > > - Eclipse have released Jakarta EE 8 which is essentially identical to > > > Java EE 8 > > > - Oracle have refused to allow changes to the APIs in the javax > namespace > > > - The Jakarta EE community seem to be reaching consensus on releasing > > > Jakarta EE 9 which will rename all the Java packages from javax.* to > > > jakarta.* > > > > > > > > > > what does this rename really mean? > > > > import javax.servlet.http.HttpSession; > > import javax.websocket.Session; > > > > those are renamed? > > If that is yes that would mean pretty much everything will break? > > > > https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ > I thought everyone knew about this. We were supposed to have a session on > this rename at ApacheCon EU, but unfortunately it didn't happen. > > Rémy > phh this is really horrible, one more reason to kind of hate Oracle.. this will split up a huge thing... So for example if you make Tomcat 10 to only have "jakarta.xxx" so all the existing code will not work on that anymore. then that tomcat will be for a long time in its own small corner.. We will not be able to use that for years to come.. because we have no control over what people are really using We still target java 8 (and that will also be the case for the coming years i am afraid) johan -- Johan Compagner Servoy
Re: Jakarta EE 9
On Mon, Oct 28, 2019 at 2:22 PM Michael Osipov wrote: > Am 2019-10-28 um 13:15 schrieb Mark Thomas: > > Hi all, > > > > A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For > those of you who aren't familiar with Jakarta EE the key points are: > > > > - Oracle have donated Java EE to Eclipse > > - Eclipse have released Jakarta EE 8 which is essentially identical to > Java EE 8 > > - Oracle have refused to allow changes to the APIs in the javax namespace > > - The Jakarta EE community seem to be reaching consensus on releasing > Jakarta EE 9 which will rename all the Java packages from javax.* to > jakarta.* > > - Jakarta EE 9 will not contain any other API changes > > - It will be a requirement to maintain backwards comparability (maybe > not 100% compatibility) with Jakarta EE 8 > > - Jakarta EE 9 will be released in the next ~11 months > > - Jakarta EE 10 will then follow which is where new features will be > introduced > > W/o going into the questions. You may want to answer two simple > questions to our users who solely use a servlet container like me: > > * Will my stuff break if I have written it against javax.servlet...? > * Since there is no canonical body (? is it Eclipse Foundation now) for > the specs, is there a possiblity that someone will fork the specs and > create their own, e.g., commercial vendors or Undertow, Netty, Jetty, > etc.?! (Mainly portability within the API) > Yes, the spec body for EE (starting with EE 9, which is functionally equivalent to EE 8 except for the package rename to jakarta.*) is now the Jakarta project at Eclipse. As with any standard, what matters is if people implement it. Rémy > > Michael > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Jakarta EE 9
Am 2019-10-28 um 13:15 schrieb Mark Thomas: Hi all, A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For those of you who aren't familiar with Jakarta EE the key points are: - Oracle have donated Java EE to Eclipse - Eclipse have released Jakarta EE 8 which is essentially identical to Java EE 8 - Oracle have refused to allow changes to the APIs in the javax namespace - The Jakarta EE community seem to be reaching consensus on releasing Jakarta EE 9 which will rename all the Java packages from javax.* to jakarta.* - Jakarta EE 9 will not contain any other API changes - It will be a requirement to maintain backwards comparability (maybe not 100% compatibility) with Jakarta EE 8 - Jakarta EE 9 will be released in the next ~11 months - Jakarta EE 10 will then follow which is where new features will be introduced W/o going into the questions. You may want to answer two simple questions to our users who solely use a servlet container like me: * Will my stuff break if I have written it against javax.servlet...? * Since there is no canonical body (? is it Eclipse Foundation now) for the specs, is there a possiblity that someone will fork the specs and create their own, e.g., commercial vendors or Undertow, Netty, Jetty, etc.?! (Mainly portability within the API) Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta EE 9
On Mon, Oct 28, 2019 at 1:46 PM Johan Compagner wrote: > Hi > > > > On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: > > > Hi all, > > > > A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For > those > > of you who aren't familiar with Jakarta EE the key points are: > > > > - Oracle have donated Java EE to Eclipse > > - Eclipse have released Jakarta EE 8 which is essentially identical to > > Java EE 8 > > - Oracle have refused to allow changes to the APIs in the javax namespace > > - The Jakarta EE community seem to be reaching consensus on releasing > > Jakarta EE 9 which will rename all the Java packages from javax.* to > > jakarta.* > > > > > > what does this rename really mean? > > import javax.servlet.http.HttpSession; > import javax.websocket.Session; > > those are renamed? > If that is yes that would mean pretty much everything will break? > https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ I thought everyone knew about this. We were supposed to have a session on this rename at ApacheCon EU, but unfortunately it didn't happen. Rémy
Re: Jakarta EE 9
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 10/28/19 08:15, Mark Thomas wrote: > Hi all, > > A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. > For those of you who aren't familiar with Jakarta EE the key points > are: > > - Oracle have donated Java EE to Eclipse - Eclipse have released > Jakarta EE 8 which is essentially identical to Java EE 8 - Oracle > have refused to allow changes to the APIs in the javax namespace - > The Jakarta EE community seem to be reaching consensus on releasing > Jakarta EE 9 which will rename all the Java packages from javax.* > to jakarta.* - Jakarta EE 9 will not contain any other API changes > - It will be a requirement to maintain backwards comparability > (maybe not 100% compatibility) with Jakarta EE 8 - Jakarta EE 9 > will be released in the next ~11 months - Jakarta EE 10 will then > follow which is where new features will be introduced > > This raises various questions for the Tomcat community including: > > 1. Do we implement Jakarta EE 9? > > Assuming yes to q1. > > 2. As Tomcat 10 or some other version? > > 3. How do we manage development (in a branch, as master, ...)? > > 4. How do we implement backwards compatability? Runtime, deploy > time, compilation time? > > 5. At what point do we EOL Tomcat 7? (since Jakarta EE 9 is just a > package renaming?) > > 6. Do we commit to supporting Tomcat 9 for an extended period? (to > provide a version that supports java.* directly) > > I'm posting this to users@ as how Tomcat users want to use and > adopt Jakarta EE 9 is likely to be the biggest driving factor in > choosing answers to these questions. > > We don't have to have all of the answers right now. I think we do > need answers for 1 & 3 so we can start. A few options and 'wait and > see' is likely good enough for the rest for now. > > I have my own views on the answers but I have tried not to express > them here so we can get as wide a discussion as possible. How "simple" of a replacement are we talking about, here? For example, can it be done simply with sed? $ find . -type f | xargs sed -e 's/javax.servlet/jakarta.servlet/g' ? I'm asking because if it really is that easy, then we should be able to trivially package each of the existing Tomcat 7, 8.5, 9 releases as 7.jakarta, 8.5.jakarta, and 9.jakarta alongside their legacy Java EE versions. Users wanting to move to the Jakarta EE namespace can do so with existing, reliable versions of Tomcat instead of waiting for Tomcat 10 or Tomcat having to implement some kind of hybrid version which supports BOTH flavors of APIs (which seems kind of nightmarish to me). Are there any restrictions against us supporting Jakarta EE in existing Tomcat releases? I don't believe so. We merely advertise support for various standards; Tomcat is no longer the "reference implementation" of any APIs so we can do whatever we want, right? If we do a simply sed-style re-naming of packages to produce parallel releases, will they actually work? My sense is that, yes, they will indeed work. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl226RIACgkQHPApP6U8 pFjnfQ//bYExvm+BEhwroa/W+v3BGx+Bw0qtzz9MxjDIZ1zcGuxlITb1QdoYZ1sz C9eQumSo/gK1sO8ImVhMCYdFOf1n2az/olcMdF2v9gYC3YMZ11+qQhppYRxvfRvG pHzkV4PHbE6mgvfY9pli6LBs1Na1MSN0nRLluC4OBz3wMGCLQyByfBX3x+++8klB HHM1wcJDLzziIBmM3NKcuEFQ1gVbjlV10rFYes29KiuG4z78FRPY87pQmP+Xj71o l5NEtERYA+SjDGPZo6wrF6k3l23cZL/yrCp4PGwO1c0VB148DervvWG33+9OEOQL 1E8F0IZc2o2eiNYUxbUQcMxGXORnfbWpMyG8RVSVlwdhmzO4Ug1pxNVcpO2Y2qC2 vHHz+deQiQ/dZIsNU5aWtC+MBL7tx3RWxBNxb3n2d5T9tJm6zHBSdGfcPyTN14cV HTtPj9al4usxoT3XGSEhAP7FiI1RJXywq+o0sppaF6BrAh0UpRIYhLtU0vh80b+J r5XClSUuQAzlWY6N6TOEHBWWDIxZ0Y2Jjx//Yz4x1XO6BVLs4Z0OhWsa0sZ+3cfg e8jaTZHcTkX6rSZCXxExELJlsOke0KcA+IaPf/zQFJUiTEEteIck60GONKaPLtoC mNaBAh7qJp7zzrl82OswiaJdksj+g76Xh4JdVFLlv1BDRbWiXVM= =kSej -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta EE 9
Hi On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: > Hi all, > > A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For those > of you who aren't familiar with Jakarta EE the key points are: > > - Oracle have donated Java EE to Eclipse > - Eclipse have released Jakarta EE 8 which is essentially identical to > Java EE 8 > - Oracle have refused to allow changes to the APIs in the javax namespace > - The Jakarta EE community seem to be reaching consensus on releasing > Jakarta EE 9 which will rename all the Java packages from javax.* to > jakarta.* > > what does this rename really mean? import javax.servlet.http.HttpSession; import javax.websocket.Session; those are renamed? If that is yes that would mean pretty much everything will break?
Jakarta EE 9
Hi all, A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For those of you who aren't familiar with Jakarta EE the key points are: - Oracle have donated Java EE to Eclipse - Eclipse have released Jakarta EE 8 which is essentially identical to Java EE 8 - Oracle have refused to allow changes to the APIs in the javax namespace - The Jakarta EE community seem to be reaching consensus on releasing Jakarta EE 9 which will rename all the Java packages from javax.* to jakarta.* - Jakarta EE 9 will not contain any other API changes - It will be a requirement to maintain backwards comparability (maybe not 100% compatibility) with Jakarta EE 8 - Jakarta EE 9 will be released in the next ~11 months - Jakarta EE 10 will then follow which is where new features will be introduced This raises various questions for the Tomcat community including: 1. Do we implement Jakarta EE 9? Assuming yes to q1. 2. As Tomcat 10 or some other version? 3. How do we manage development (in a branch, as master, ...)? 4. How do we implement backwards compatability? Runtime, deploy time, compilation time? 5. At what point do we EOL Tomcat 7? (since Jakarta EE 9 is just a package renaming?) 6. Do we commit to supporting Tomcat 9 for an extended period? (to provide a version that supports java.* directly) I'm posting this to users@ as how Tomcat users want to use and adopt Jakarta EE 9 is likely to be the biggest driving factor in choosing answers to these questions. We don't have to have all of the answers right now. I think we do need answers for 1 & 3 so we can start. A few options and 'wait and see' is likely good enough for the rest for now. I have my own views on the answers but I have tried not to express them here so we can get as wide a discussion as possible. Thoughts? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org