Bug #4247
closed
java.lang.ExceptionInInitializerError on Saxon 9.9.1.4 .Net where Java version works
100%
Description
We have an XSLT script that works with 9.8.0.14 PE .Net and shall work with the recent 9.9.1.4 PE .Net version of Saxon. Instead we get an error message:
Unbehandelte Ausnahme: java.lang.ExceptionInInitializerError
bei net.sf.saxon.Transform.doTransform(String[] args, String command)
bei Saxon.Cmd.DotNetTransform.Main(String[] args)
(Unbehandelte Ausnahme = Unhandled exception; bei = at)
Quite interesting: The script is working with the Java version of 9.9.1.4 PE.
The script is also not working with the prior maintenance release 9.9.1.3 PE .Net.
Other (simpler) scripts work.
With option "-t" set I can see that URIs from various catalog files get resolved and also that the stylesheet gets compiled.
I have no idea how to locate the problem within the XSLT with the help of the message above. And I cannot drop the XSLT /Data here.
Last lines in console before stacktrace are (with -t option):
Stylesheet compilation time: 3.4210791s (3421.0791ms)
Processing (no source document) initial template = main
Do you have any hints? Any particular infos you need to know? Obviously, this is a Problem of Saxon 9.9 .Net versions ...
Files
Updated by O'Neil Delpratt almost 5 years ago
- Applies to branch 9.9 added
Hi, Is it possible for you to attach the files to this bug issue or send them by email if they are confidential?
Updated by O'Neil Delpratt almost 5 years ago
- Category set to .NET API
- Status changed from New to In Progress
- Assignee set to O'Neil Delpratt
- Priority changed from Low to Normal
Bug issue reproduced. There seems to some relation to setting the language and localization to non-english. I reproduced the error using German settings.
Investigating issue.
Updated by O'Neil Delpratt almost 5 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
- Applies to branch trunk added
- Fix Committed on Branch 9.9, trunk added
The underlying cause of this error is in the file EXPathFile on line 55:
public static final String NEWLINE = String.format("%n");
The String.format depends on the locale and is returning some wrong when we set localization to Germany.
Bug fixed as follows:
public static final String NEWLINE = System.getProperty("line.separator");
Updated by Michael Kay almost 5 years ago
Note: we have fixed this without understanding the root cause. The call to String.format("%n") should return exactly the same as System.getProperty("line.separator"). But for some reason, if the default Locale is non-English, then under .NET the first call is failing. This could be an IKVM bug, we really don't know.
Updated by Jan Pertermann almost 5 years ago
- File StackTrace.txt StackTrace.txt added
I attached a report from the JIT debugger we used yesterday to get the localization issue - maybe you can find some hints. Paste it to an excel or calc sheet to view the contents. Indeed it might be an issue of IKVM.
Updated by Michael Kay almost 5 years ago
The key error here seems to be "Das Objekt des Typs java.util.PropertyResourceBundle kann nicht in Typ sun.util.resources.OpenListResourceBundle umgewandelt werden." (That is, an object of type java.util.PropertyResourceBundle cannot be converted to sun.util.resources.OpenListResourceBundle) which suggests that somewhere deep in the localization code something is assuming a sun.util implementation of PropertyResourceBundle, which has probably been replaced by an IKVM implementation.
The diagnostics also show that the simple call on String.format("%n") is initialising a vast load of localisation machinery which really isn't needed for the purpose. so the patch is certainly a good one even if we don't fully understand why it's needed.
I'm afraid that with IKVM no longer supported, we're going to have to work around problems like this in future rather than getting them fixed. Fortunately they are very rare.
Updated by Jan Pertermann almost 5 years ago
Michael Kay wrote:
I'm afraid that with IKVM no longer supported, we're going to have to work around problems like this in future rather than getting them fixed. Fortunately they are very rare.
Then, relying on IKVM in the long term can be no oppportunity. Switching to SaxonJ is on our list, but this will still take some time ...
Updated by Vladimir Nesterovsky almost 5 years ago
According to Microsoft there will be built-in java interop in .net 5.
See https://devblogs.microsoft.com/dotnet/introducing-net-5/
Updated by O'Neil Delpratt almost 5 years ago
Vladimir Nesterovsky wrote:
According to Microsoft there will be built-in java interop in .net 5.
See https://devblogs.microsoft.com/dotnet/introducing-net-5/
Yes, this is something to look out for to see what it contains.
Updated by Jan Pertermann almost 5 years ago
Thanks for the link -- though that sounds very ambitious!
Updated by O'Neil Delpratt almost 5 years ago
It is unclear how it will be done, but reading the comments in the posts it mentions that they will take the approach of Mono, which uses IKVM to interop with Java.
Updated by Michael Kay almost 5 years ago
Which might (or might not) mean that they plan to fork or rewrite IKVM to support .NET Core. We'll wait and see.
Updated by O'Neil Delpratt over 4 years ago
- Status changed from Resolved to Closed
- Fixed in Maintenance Release 9.9.1.5 added
Bug fix applied in the Saxon 9.9.1.5 maintenance release.
Please register to edit this issue
.