|Summary:||ImportHandler shall ignore non-public classes|
|Product:||Tomcat 8||Reporter:||Konstantin Kolinko <knst.kolinko>|
|Component:||EL||Assignee:||Tomcat Developers Mailing List <dev>|
Description Konstantin Kolinko 2014-10-23 23:18:35 UTC
EL 3.0 specification says in 1.22.2 "Imports of Packages, Classes, and Static Fields" that "Importing a package imports all the classes in the package." I think that that is wrong and it shall actually say that it imports all *public* classes in the package. It may result in spirituous conflicts during resolveClass() -- see the example below. Consider the following example: ================================ Mr.Cameron has class com.cameron.Terminator and uses package import to make it accessible. ImportHandler handler = new ImportHandler(); handler.importPackage("com.cameron"); handler.resolveClass("Terminator"); If it really were importing all classes from a package, the above code will run successfully on some JRE, but will fail on Oracle Java 7 JRE that has "java.lang.Terminator" class, due to ambiguity between the two classes. The "java.lang.Terminator" class is not part of public API of a JRE. A JRE vendor is free to add such classes. It should not cause such spiritual failures. Javadoc for javax.el.ImportHandler in JavaEE 7  says that resolveClass(String) throws ELException - if the class is <...> not public. If resolveClass(String) method were changed to return 'null' for non-public classes instead of throwing an ELException, it would be a bit easier to implement.  http://docs.oracle.com/javaee/7/api/javax/el/ImportHandler.html
Comment 1 Mark Thomas 2014-10-24 21:36:14 UTC
I'm guessing you mean spurious rather than spirituous/spiritual. I agree the text in the spec is likely to be wrong but the text is clear. I suggest we seek clarification from the EG before continuing else we risk different behaviour in different implementations.
Comment 2 Konstantin Kolinko 2014-10-25 20:25:46 UTC
(In reply to Mark Thomas from comment #1) > I'm guessing you mean spurious rather than spirituous/spiritual. I meant unexpected and mysterious. > I agree the text in the spec is likely to be wrong but the text is clear. I > suggest we seek clarification from the EG before continuing else we risk > different behaviour in different implementations. OK. I am changing status to NEEDINFO for now. I think that if there are both public and non-public class from package imports, we would be pretty safe to prefer the public class.
Comment 4 Mark Thomas 2015-03-05 13:40:51 UTC
There has been no input from the EG so lets proceed on the basis that this bug is valid.
Comment 5 Mark Thomas 2015-03-05 13:57:31 UTC
Fixed in trunk and 8.0.x for 8.0.21 onwards,