Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [el-dev] Jakarta EE 9 EL 4.0 Status

On 25/01/2020 01:14, Paul Nicolucci wrote:
> Hi,
> 
> I created the Release Record for Jakarta Expression Language 4.0.0:
> https://projects.eclipse.org/projects/ee4j.el/releases/4.0.0

Great. Thanks for doing that.

> I used the end of March as a date, we can change this if necessary.
> 
> As long as we stick to the overall Jakarta EE9 plan then we won't need
> an additional ballot / review etc. For now I've just referenced the
> Jakarta EE9 plan.
> 
> If we have an issue we think should be addressed for the 4.0.0 release
> lets discuss it on the mailing list and decide which to include in 4.0.0
> and which need to wait for the next release.
> 
> Open Issues: https://github.com/eclipse-ee4j/el-ri/issues
> 
> I reviewed the issues and I didn't spot any issues that jumped out as
> "fix typo in spec" or "clarification". Do we have an issue for the
> generics work you were talking about?

There isn't an issue for the generics. I'll get that added. The fix is
trivial but I was waiting until I had made progress on the TCK.

(Aside: I am very close to having a PR for the TCK project to update the
EL TCK. I have found an issue we'll need to fix first. More on that below.)

There was one trivial clarification issue that I have already fixed:
https://github.com/eclipse-ee4j/el-ri/issues/41

I've been going through the open issues in more detail over the last day
or so. The only issue that I think comes under the heading of
clarification is:
https://github.com/eclipse-ee4j/el-ri/issues/42

I have some ideas for wording here but I think this is going to be
something that needs several iterations to get right. I'll start a new
thread for that.


We need to figure out what to do about:
https://github.com/eclipse-ee4j/el-ri/issues/37

There is an undocumented behaviour change between Java EE 8 and Jakarta
EE 8. I've yet to form a view on whether this change is 'correct'.
Should we revert the change anyway, irrespective of correctness?


While testing my PR for the TCK I discovered:
https://github.com/eclipse-ee4j/el-ri/issues/118

This needs fixing for 4.0.0. The same issue affects Apache Tomcat
(unsurprising, given the shared history of the code bases) and I'm
working on a fix for Tomcat. Once I have a working Tomcat fix, I intend
to apply essentially the same fix to EL.


There are a handful of issues (#78, #45, #44) that I'd like to
investigate more to see if the root cause lies in the API or the
implementation. I'd like to get any API issues fixed for this release.


Finally, it would be good to get more eyes on the new EL spec PDF - in
particular checking it against the 3.0 spec. I've been through it
several times but it is getting to the point where I am too familiar
with it to spot any issues.

Mark


> 
> Regards,
> 
> Paul Nicolucci
> 
> On Thu, Jan 23, 2020 at 4:26 AM Mark Thomas <markt@xxxxxxxxxx
> <mailto:markt@xxxxxxxxxx>> wrote:
> 
>     On 23/01/2020 01:15, Paul Nicolucci wrote:
>     > Hi,
>     >
>     > I was planning to create the Release Record for EL 4.0 to complete the
>     > first item on this list:
>     https://github.com/eclipse-ee4j/el-ri/issues/116
> 
>     Great. Thanks for looking at this.
> 
>     > Are there any plans other than the Jakarta naming update planned
>     for EL 4.0?
> 
>     I'd like to review the open issue list and fix any issues that come
>     under the category of "typos" in Javadoc, spec doc etc. It is a while
>     since I looked through the issues and I know there were a few like that
>     across the projects I'm involved in but I can't remember if there were
>     any in EL.
> 
>     If there are "clarification" issues then we might be able to address
>     some of them providing it doesn't change the API or expected behaviour.
>     Again, I haven't looked through them recently enough to have anything
>     specific in mind.
> 
>     There are a handful of API clean-ups (adding generics where they were
>     missed) that are binary compatible changes that I plan to make. We
>     didn't make them in Jakarta EE 8 because it would have meant changing
>     the signatures in the TCK but since we are going to have to update the
>     signatures for the package rename now is a good time to get this done.
> 
>     There is a single deprecated method:
>     MethodExpression#isParmetersProvided()
>     that I'd *really* like to remove. The method name has a typo and a new,
>     fixed method has been added. Part of me thinks the Jakarta EE 8 to 9
>     transition is the perfect time to do this. However, it is a backwards
>     incompatible change and would add complexity to any tool doing automatic
>     Jakarta EE 8 to 9 conversion. As much as I'd like to see this method
>     removed, I think it is going to have to remain for Jakarta EE 9.
> 
>     > Additionally I only saw a 4.0.0-M1 out on Maven Central, we will
>     need an
>     > RC according to the following information from the platform-dev
>     mailing
>     > list: 
>     https://www.eclipse.org/lists/jakartaee-platform-dev/msg01414.html
>     >
>     > Any thoughts on a date for the EL 4.0 Release Record?
> 
>     Is that a guess at the final date? If so the TCK is the big unknown. I
>     haven't looked at any of that yet. Best guess (and it really is a guess)
>     would be end of March.
> 
>     Mark
>     _______________________________________________
>     el-dev mailing list
>     el-dev@xxxxxxxxxxx <mailto:el-dev@xxxxxxxxxxx>
>     To change your delivery options, retrieve your password, or
>     unsubscribe from this list, visit
>     https://www.eclipse.org/mailman/listinfo/el-dev
> 
> 
> _______________________________________________
> el-dev mailing list
> el-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/el-dev
> 


Back to the top