Agreed that the spec can be clearer. :-) This has been discussed by the Spec expert group, and bullet .2 was added because some vendors wanted it. I'll check with the spec lead for a clarification.
Also agreed that this breaks backward compatibility; but it not really too bad. I think a lot of users would rather have the error at compilation time than at runtime. What can you do with an instantiation error at runtime? If we are really concern about BC, then we can add another compilation option to revert to old behavior. I really don't like another switch, but if it'll make people happy... -Kin-man > Date: Mon, 02 Feb 2004 19:41:54 +0100 > From: Remy Maucherat <[EMAIL PROTECTED]> > Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java > To: Tomcat Developers List <[EMAIL PROTECTED]> > > Kin-Man Chung wrote: > > -1. > > > > Remy, please reread JSP 2.0 spec, p 1-101,1-102. Bullet .2 of the Semantics > > section was added to allow for this kind of optimization. Bullet .5 and .6 > > will be executed ONLY IF the container choose not to issue translation errors. > > I cannot really understand what the fragment really means, so I don't > know. I had the impression that it implied that the error should be at > runtime. > I recommend the change is reverted as I did, as many users will likely > make the same mistake, since the specification is impossible to > understand (if you are right and your change indeed does not break the > specification). This will also create compilation errors when upgrading > from TC 4 to TC 5. > > Rémy > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
