https://bz.apache.org/bugzilla/show_bug.cgi?id=62453
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #35975|0 |1
is obsolete| |
--- Comment #8 from Mark Thomas <ma...@apache.org> ---
Created attachment 35990
--> https://bz.apache.org/bugzilla/attachment.cgi?id=35990&action=edit
Updated patch with test cases to check class lists
Given the general approach of Java EE (which I assume will continue in Jakarta
EE) to backwards compatibility, I don't think the behaviour required by the
specification is going to change.
The performance implications of adding imports to EL were not realised at the
time. They are now part of the spec and, for the same reason as above, I don't
think that will change.
Using a non-specification compliant work-around is an option. The work-around
proposed looks reasonable to me. However, experience tells me that it is hard
to judge what proportion of users would benefit from it vs would see failures
with it. Clearly, it would be optional. The question would be whether to enable
it by default or not.
One of the benefits of the Java 9 module system is that it is possible to
enumerate all the classes in java.lang. I have attached an updated test case
that does this and also checks the Servlet/JSP spec classes too.
The patch is undoubtedly a hack but with the test cases ongoing maintenance is
minimal and users are saved the hassle of having to go through their code and
add explicit scopes everywhere.
Unless there are objections, I plan to commit this to trunk.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
