[slf4j-user] [slf4j-dev] [POLL] Requiring JDK 1.5 for SLF4J

[Simon Kaegi]

> When are you planning to move to 1.5 in Equinox?
My best guess is the e4 release in June 2010 but let me try and pin this 
down at the next Equinox call (Tuesday) and report back. FWIW I'll also ping 
some of the embedded VM folk who work close by to get there thoughts on 
timeframes for what (if anything) is going to happen with CDC/Foundation.

-Simon
--
Hello Simon,

Thank you for your detailed and informative response. Much appreciated.

The Eclipse Equinox scenario you describe resembles my nightmare scenario
whereby an application container requires an older JDK-1.3-compatible 
version of
SLF4J and a hosted application requires a newer version of SLF4J requiring 
JDK
1.5, resulting in a version-deadlock. We could imagine isolating the usage 
of
SLF4J by the host so that it does not interfere with applications (as Jetty
does). However, we are talking about logging which has to be simple and 
robust.

When are you planning to move to 1.5 in Equinox?

Simon Kaegi wrote:
> I feel your pain; bumping to 1.5 class files is a big deal for low-level
> libraries like logging.
>
> My team works on the Eclipse Equinox project and we continue to struggle
> with when to update to 1.5 class files and features. Even in the upcoming
> release of OSGi we're limited to OSGi min 1.2 which still uses 1.2 class
> files. As a result of how this requirement ripples this change will 
> prevent
> us from using this new version of SLF4J for logging in the core Eclipse
> platform until we also bump our minimum requirements to 1.5 class files.
>
> For more typical users I agree that there are some benefits in terms of 
> API
> however this sort of change will affect people in the mobile and embeded
> space who for the most part are using CDC-1.1/Foundation-1.1 (similar to
> Java 1.4). Varargs are of course syntactic sugar however the real problem 
> is
> the class file version bump. Many of the mobile VMs being used can read 
> 1.5
> class files (despite having a 1.1 profile class library) but I'd be 
> hesitant
> to rely on this.
>
> Varargs doesn't really cut it as sufficient benefit to break part of the
> community so I'm -1 on this change for now as I suspect if you go ahead
> you'll be maintaining dual releases for sometime. With that said (like us)
> you probably cannot dodge this upgrade forever.
> -Simon
>
-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for 
Java.
http://logback.qos.ch
_______________________________________________
user mailing list
user at slf4j.org
http://www.slf4j.org/mailman/listinfo/user