On Jan 28, 2013, at 3:46 AM, Mark Thomas wrote: > On 26/01/2013 21:51, Henri Yandell wrote: >> On Fri, Jan 18, 2013 at 8:30 AM, Jeremy Boynes <jer...@boynes.com> wrote: >>> On Jan 18, 2013, at 1:34 AM, Konstantin Kolinko wrote: >>> >>> There is also an issue with the I18N tags taking a long time to start on a >>> Java6 platform due to changes in the way Locales are located by the JRE. I >>> remember some discussion on fixing this but a requirement to stay on Java 5 >>> meant having to build two implementations and switch between them which I'd >>> planned to do once a release was out. If we pre-req 6 or 7 then the >>> implementation can just be updated and this issue closed easier. >> >> Would the TCK pass if it was on Java 7? > > We are talking about Taglibs 1.2 right? (If not adjust versions below > accordingly). > > Taglibs 1.2 requires JSP 2.1. > > JSP 2.1 requires Java 5 or later (as does Servlet 2.5 and J2EE 5). > > Based on that, I would say that the TCK has to pass when running on Java 5. > > /me goes looking for some TCK docs > > I've just checked the latest version of the TCK documentation for JSTL > 1.2 and while the TCK has been updated so it will run on Java 7, the > reference runtime remains Java 5. My interpretation of that is that the > TCK must pass when running with a Java 5 JRE.
My interpretation was that a product must pass the TCK in all its configurations. In other words, you can't claim compatibility on Java7 unless you've tested on Java7. If we test on Java7 and pass, we can claim we're a compatible implementation in that mode; if we don't test on Java5 then we can't claim compatibility on Java5 but that does not stop us being compatible on Java7. I read it as being sufficient if we document what we require as a resource. @Henri, I ran all tests on Java6 and have not tried SQL on Java7. I'll pull the newer version and retest. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
