Project

Profile

Help

Transformation NoSuchMethodError on Java 1.4

Added by Anonymous over 17 years ago

Legacy ID: #4278016 Legacy Poster: Jonas Nyfeldt (jnyfeldt)

Hi there, I've just started trying out saxonb8-9j and stumbled across a problem that I can't seem to figure out myself. While transforming an XML-document to an XSL-FO-document (using a stylesheet generateted by Altova StyleVision) I get the following exception (abbreviated): java.lang.NoSuchMethodError: java.math.BigDecimal: method <init>(J)V not found at net.sf.saxon.value.Int64Value.getDecimalValue(Int64Value.java:311) at net.sf.saxon.expr.Calculator$DecimalDivDecimal.compute(Calculator.java:651) ... at net.sf.saxon.style.XSLStylesheet.compileStylesheet(XSLStylesheet.java:1050) at net.sf.saxon.PreparedStylesheet.setStylesheetDocument(PreparedStylesheet.java:328) at net.sf.saxon.PreparedStylesheet.prepare(PreparedStylesheet.java:140) at net.sf.saxon.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:137) at net.sf.saxon.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:88) ... Looking at line 311 of Int64Value.java I see: return new BigDecimal(value); ...where value is a member variable of type long. After browsing the BigDecimal javadoc for java 1.4 (http://java.sun.com/j2se/1.4.2/docs/api/) and java 1.5 (http://java.sun.com/j2se/1.5.0/docs/api/), it seems to me like the constructor taking a long argument was introduced in Java 1.5 (which would explain the exception). Does this mean that saxonb8-9j does not support java 1.4 anymore, or have I missing some prerequisite to run on 1.4? Thanks in advance, /Jonas


Replies (4)

Please register to reply

RE: Transformation NoSuchMethodError on Java - Added by Anonymous over 17 years ago

Legacy ID: #4278174 Legacy Poster: Michael Kay (mhkay)

Unfortunately you've snipped a bit too much of the stack trace, so I can't see what path you're on which would help me to replicate the problem. You're quite right that this constructor isn't documented as part of JDK 1.4. First puzzle is that normally this gets caught at compile time, because I compile against JDK 1.4. This could have something to do with switching to an Ant build, because I think I'm now using the JDK 1.5 compiler with source language level 1.4, rather than actually using the 1.4 compiler. The second question is, why hasn't anyone hit this until now. It's true that a lot of people have moved to 1.5 but I don't think you're the only 1.4 user left! I think it's simply that it's actually quite difficult to get onto this code path. So, could you please (a) show me more of the stack trace, and (b) tell me what you were doing at the time?

RE: Transformation NoSuchMethodError on Java - Added by Anonymous over 17 years ago

Legacy ID: #4278193 Legacy Poster: Michael Kay (mhkay)

I think the answer to the first point is that when I compiled under JDK 1.4, the call was bound to the BigDecimal(double) constructor, but compiling with JDK 1.4 with language level 1.4 has fixed up the call to BigDecimal(long) which isn't there in 1.4, and fails only if the method is actually called. So we need to find out why it's being called.

RE: Transformation NoSuchMethodError on Java 1.4 - Added by Anonymous over 17 years ago

Legacy ID: #4279601 Legacy Poster: Jonas Nyfeldt (jnyfeldt)

Thanks for the quick response. Here's an complete stack trace: java.lang.NoSuchMethodError: java.math.BigDecimal: method <init>(J)V not found at net.sf.saxon.value.Int64Value.getDecimalValue(Int64Value.java:311) at net.sf.saxon.expr.Calculator$DecimalDivDecimal.compute(Calculator.java:651) at net.sf.saxon.expr.ArithmeticExpression.evaluateItem(ArithmeticExpression.java:237) at net.sf.saxon.expr.ArithmeticExpression.typeCheck(ArithmeticExpression.java:151) at net.sf.saxon.instruct.SimpleContentConstructor.typeCheck(SimpleContentConstructor.java:65) at net.sf.saxon.instruct.SimpleNodeConstructor.typeCheck(SimpleNodeConstructor.java:102) at net.sf.saxon.instruct.Choose.typeCheck(Choose.java:98) at net.sf.saxon.instruct.ParentNodeConstructor.typeCheck(ParentNodeConstructor.java:137) at net.sf.saxon.instruct.DocumentInstr.typeCheck(DocumentInstr.java:101) at net.sf.saxon.expr.LetExpression.typeCheck(LetExpression.java:74) at net.sf.saxon.expr.LetExpression.typeCheck(LetExpression.java:87) at net.sf.saxon.expr.LetExpression.typeCheck(LetExpression.java:87) at net.sf.saxon.expr.LetExpression.typeCheck(LetExpression.java:87) at net.sf.saxon.expr.LetExpression.typeCheck(LetExpression.java:87) at net.sf.saxon.instruct.Block.typeCheck(Block.java:243) at net.sf.saxon.instruct.Choose.typeCheck(Choose.java:98) at net.sf.saxon.instruct.ForEach.typeCheck(ForEach.java:90) at net.sf.saxon.instruct.Block.typeCheck(Block.java:243) at net.sf.saxon.instruct.ForEach.typeCheck(ForEach.java:90) at net.sf.saxon.instruct.ForEach.typeCheck(ForEach.java:90) at net.sf.saxon.instruct.Block.typeCheck(Block.java:243) at net.sf.saxon.instruct.ParentNodeConstructor.typeCheck(ParentNodeConstructor.java:137) at net.sf.saxon.instruct.Block.typeCheck(Block.java:243) at net.sf.saxon.instruct.ParentNodeConstructor.typeCheck(ParentNodeConstructor.java:137) at net.sf.saxon.instruct.Block.typeCheck(Block.java:243) at net.sf.saxon.instruct.ParentNodeConstructor.typeCheck(ParentNodeConstructor.java:137) at net.sf.saxon.instruct.Block.typeCheck(Block.java:243) at net.sf.saxon.instruct.ParentNodeConstructor.typeCheck(ParentNodeConstructor.java:137) at net.sf.saxon.expr.LetExpression.typeCheck(LetExpression.java:87) at net.sf.saxon.style.XSLTemplate.compile(XSLTemplate.java:332) at net.sf.saxon.style.XSLStylesheet.compileStylesheet(XSLStylesheet.java:1050) at net.sf.saxon.PreparedStylesheet.setStylesheetDocument(PreparedStylesheet.java:328) at net.sf.saxon.PreparedStylesheet.prepare(PreparedStylesheet.java:140) at net.sf.saxon.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:137) at net.sf.saxon.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:88) at se.sdc.tm.poc.xslttest.TestProgXsltTest.testSaxonXslt20LossspecToFO(TestProgXsltTest.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:41) at java.lang.reflect.Method.invoke(Method.java:386) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) 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:118) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:392) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:276) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:167) Unfortunately I can't seem to find any way to attach files to this post, and the stylesheet and XML-document that caused the error are a little too big to paste as text... However, if you like to have the files I'm happy to give them too you. In that case, I'll need some information about where to put the files. If you can't provide that information in this thread you're welcome to contact me on: saxontemp at nyfeldt dot net.

RE: Transformation NoSuchMethodError on Java - Added by Anonymous over 17 years ago

Legacy ID: #4279677 Legacy Poster: Michael Kay (mhkay)

Thanks. The general answer to the question of where to post attachments is to use the "support requests" tracker on SourceForge which does allow attachments; however if you don't want the material to be permanently archived in the public domain you're welcome to send it direct to mike (at) saxonica.com However I have now found a test case that exercises the code in question, namely: let $x := 2 return $x div 1.5 (Division of an xs:integer by an xs:decimal at compile time) In principle this could be fixed simply by recompiling with JDK 1.4, which would fix up the BigDecimal(long) call to BigDecimal(double), but that's not ideal so I'll try and do something that works using the existing build scripts. As a workaround, cast the numerator in the division to xs:decimal. Michael Kay

    (1-4/4)

    Please register to reply