[slf4j-user] Question about LoggerFactory

[Jacob Kjome]

This is what happens when you build a library with a newer JDK than you claim 
to support.  It takes more than just providing compiler source/target 
arguments to make code compatible with older JDK's.  You need to build against 
the lowest common denominator API that you support.

Looking at the MANIFEST.MF for slf4j-api-1.6.1.jar, I see....

Build-Jdk: 1.6.0_16
Bundle-RequiredExecutionEnvironment: J2SE-1.3

If SLF4J wants to claim support for J2SE-1.3, then the project should be built 
(or, at the very least, developed) under it.  The bad method in question 
(java.util.Arrays.toString([Ljava/lang/Object;)Ljava/lang/String) was 
introduced in JDK1.5.  Because SLF4J was built using JDK1.6, this problem was 
not discovered.  Clearly the latest version of SLF4J depends on JDK1.5 so it 
will not be possible to run under any older JDK than that.


Jake

On Thu, 9 Dec 2010 12:54:23 -0500
  "David Sills" <DSills at datasourceinc.com> wrote:
> All:
> 
> 
> 
>For a project I'm currently working on, there is a need to use Java 1.4.
> It's like going back to the Dark Ages, but I'm doing so far OK. I'm
> using Ivy and the version of SLF4J I've specified is 1.6.1. However, I'm
> running into a problem when I run my tests. Everything runs, but the
> LoggerFactory throws and prints out an exception:
> 
> 
> 
> Unexpected problem occured during version sanity check
> 
> Reported exception:
> 
> java.lang.NoSuchMethodError:
> java.util.Arrays.toString([Ljava/lang/Object;)Ljava/lang/String;
> 
>      at
> org.slf4j.LoggerFactory.versionSanityCheck(LoggerFactory.java:161)
> 
>      at
> org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:106)
> 
>      at
> org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:235)
> 
>      at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:208)
> 
>      at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:221)
> 
>      at
> com.datasourceinc.alerts.util.AlertsFileParser.<init>(AlertsFileParser.j
> ava:15)
> 
>      at
> com.datasourceinc.alerts.util.FileParsingTest.testParse(FileParsingTest.
> java:19)
> 
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 
>      at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> a:39)
> 
>      at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:25)
> 
>      at java.lang.reflect.Method.invoke(Method.java:324)
> 
>      at junit.framework.TestCase.runTest(TestCase.java:164)
> 
>      at junit.framework.TestCase.runBare(TestCase.java:130)
> 
>      at junit.framework.TestResult$1.protect(TestResult.java:106)
> 
>      at junit.framework.TestResult.runProtected(TestResult.java:124)
> 
>      at junit.framework.TestResult.run(TestResult.java:109)
> 
>      at junit.framework.TestCase.run(TestCase.java:120)
> 
>      at junit.framework.TestSuite.runTest(TestSuite.java:230)
> 
>      at junit.framework.TestSuite.run(TestSuite.java:225)
> 
>      at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUn
> it3TestReference.java:130)
> 
>      at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.ja
> va:38)
> 
>      at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTe
> stRunner.java:467)
> 
>      at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTe
> stRunner.java:683)
> 
>      at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRun
> ner.java:390)
> 
>      at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRu
> nner.java:197) 
> 
> 
> 
> I have looked at the appropriate line in the LoggerFactory source and I
> don't quite understand what is happening. I have checked that the
> versions of the API and implementation JARs match, so this has to have
> something to do with using JDK 1.4, I'm assuming. Any ideas what is
> happening or what I can do about it, short of getting source and
> compiling it under 1.4?
> 
> 
> 
> Thanks!
> 
> 
> 
> David Sills
> 
> 
>