Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [servlet-dev] Transitioning to Jakarta EE namespace

I mostly agree with the points Mark and Greg have raised. I will write up a more detailed post later but I will just point out now that I think this is going to be way more disruptive than people think.

Servlet is a foundational library that is depended on by thousands of additional libraries. It looks like in maven central alone the official artifact has over 10k dependencies. This is not just a simple change of imports, and bytecode transformation is not a panacea, as it will not help if the code cannot be compiled in the first place. 

For example If I have code in a library that expects a javax.servlet.HttpServletRequest and my app has a jakarta.servlet.HttpServletRequest then my program will not compile so runtime bytecode transformation is not a solution. The only way to deal with this will be to either get a more up to date version of the library (which may not be possible), or do my own build time transformation, which is not necessarily simple (e.g. I will likely need my own maven repo to deploy my modified version of this artifact).

From a users point of view I think they will mostly see this as all pain with no gain, especially as many users do not use the Servlet API directly but via other frameworks, so will not see any benefits from improvements.

Stuart

On Tue, May 7, 2019 at 10:37 AM Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
Reza,

I think for any given project, changing imports is not that cumbersome.

The problem comes when you are a vendor providing a container to a user that might have hundreds of projects worked on by thousands of developers.  Now if they were all micro-services, then they could perhaps change these projects one by one - but many/most are not like that.    So how do you combine all these projects to be deployable onto the same server infrastructure?  How do they update all their documentation, support scripts, training materials when it can't be done atomically?

How much time and effort is going to be expended, only to arrive back exactly where we are today?

What is the carbon footprint going to be of almost every request passing an  if (javax) {goJavax } else { goJakarta } ?

 It is doable, but there is a cost in time, money and lost opportunity to use this disruption to actually change something.

cheers


On Tue, 7 May 2019 at 16:30, Reza Rahman <reza_rahman@xxxxxxxxx> wrote:
I'll chime in as a former user. I do not think changing imports is that
cumbersome.

On 5/7/2019 9:42 PM, Mark Thomas wrote:
> Thinking about this from a purely Servlet perspective.
>
> The current API feels mostly done. There are some bits and pieces we
> could clean up but most of the things on my TODO list for the existing
> API are around clarifying behaviour for various edge cases - i.e.
> changing the JavaDoc, not changing the code. Even for Cookies - an area
> where I think there is a lot to do - a lot can be done with the existing
> API.
>
> Potential new features (reactive, QUIC, HTTP/3, ???) would almost
> certainly be put into new packages. I think it makes little difference
> if those packages are under jakarta.servlet.* rather than javax.servlet.*
>
> Existing Java EE 8 implementations are going to be supported for as long
> as it remains viable to do so. In terms of open source implementations,
> I can see that support lasting for at least the next decade.
>
> My conclusion from these musing is that significant new features should
> go into new jakarta.servlet.* packages. The open question is what do we
> do with the existing API?
>
> Leave it where it is:
> Pros:
> - Upgrade from Java EE 8 to Jakarta EE 9 is seamless.
> Cons:
> - We have to live with the API as is.
> - Our hands are tied in terms of making any changes to javax.servlet.*
>    classes. We could probably handle this by creating new
>    jakarta.servlet.* classes that extended javax.servlet.* where
>    necessary but that could get messy.
>
> Move it to jakarta.servlet.*
> Pros:
> - We can clean up the API.
> - We have more flexibility to change the existing API.
> Cons:
> - Upgrade from Java EE 8 to Jakarta EE 9 will require code changes.
>    Much of it will be copy/paste but there may be some more subtle
>    changes required depending on how much we clean up.
>
>
> I'm currently undecided on the best way forward. The opportunity to
> clean up the API is tempting but I'm worried about the cost of migration
> to users. I would be good to hear from some users on this.
>
> Mark
>
>
>
> On 07/05/2019 10:52, Greg Wilkins wrote:
>> All,
>>
>> I draw your attention to the discussions regarding the potential need to
>> transition for javax.* namespace to the jakarta.* namespace:
>>
>>   [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
>>   - https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html
>>
>> This is an incredibly significant matter that may well shape our
>> development efforts for years to come.  It is extremely important that
>> we come up with a reasonable approach to overcome this difficult issue -
>> both from a servlet point of view and as the wider jakarta EE community.
>>
>> The EE ramification will be discussed
>> in  https://accounts.eclipse.org/mailing-list/jakartaee-platform-dev and
>> all are welcome to participate.  However, I believe that in parallel
>> (and to correctly inform the EE discussion),  we need to discuss the
>> servlet specific ramifications, opportunities, evolution, revolutions,
>> etc.    I think this is the correct forum to do this and I invite input
>> and discussion here.
>>
>> I expect that there will be many relevant discussions external to this
>> forum and the platform-dev one: blogs, articles, vendor lists, other
>> forums etc.   I plan to write my own thoughts down in a blog soon.
>>   Thus can we make an effort to link such external discussion here.
>>
>> Ultimately I expect that an email forum thread will be insufficient to
>> capture all the issues, concerns, solutions, alternatives, etc. and that
>> we may eventually need to use an issue tracker or similar, but let's
>> start with a thread to at least get the ideas circulating.
>>
>>
>>
>> --
>> Greg Wilkins <gregw@xxxxxxxxxxx <mailto:gregw@xxxxxxxxxxx>> CTO
>> http://webtide.com
>>
>> _______________________________________________
>> servlet-dev mailing list
>> servlet-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/servlet-dev
>>
> _______________________________________________
> servlet-dev mailing list
> servlet-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/servlet-dev
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/servlet-dev


--
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/servlet-dev

Back to the top