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" <[email protected]> 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
_______________________________________________
slf4j-user mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-user
