Am 08.03.2010 15:34, schrieb Ceki Gülcü:
Moreover, while a container may be built using JDK 1.4 I don't see how a container could force the use of JDK 1.4. The end-user can always chose to use a later version of the JDK.
Actually, not. I have seen so many shops which deployed WebSphere and then are bound to the IBM JRE shipped with WebSphere.
My comment was about a container exporting its version of SLF4J to the application, but as long as SLF4J v1 and v2 are binary compatible that would not be a problem. If v1 and v2 are NOT binary compatible, then that's a different matter altogether.
From my understanding, if it's binary compatible it's not v2.
There is some information centralized here: http://wiki.eclipse.org/API_Central This one is particular interesting: http://wiki.eclipse.org/Evolving_Java-based_APIs http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Turning_non-generic_types... Also this one: http://wiki.eclipse.org/Version_Numbering#When_to_change_the_major_segment
From the article above it appears that it's actually possible to use 1.5 syntax in source which gets "down-compiled" to 1.4.
WDYT?
What about a simple user survey to find out what SLF4J users are actually using today? The whole discussion might be obsolete if the survey unveils that 40% of the users are using 1.4 JREs and cannot upgrade. It could also be that >80% use Java5 already. It would be also interesting which is the most used SLF4J implementation. -Gunnar -- Gunnar Wagenknecht gunnar@wagenknecht.org http://wagenknecht.org/