Project

Profile

Help

Bug #4247

java.lang.ExceptionInInitializerError on Saxon 9.9.1.4 .Net where Java version works

Added by Jan Pertermann 2 months ago. Updated 13 days ago.

Status:
Closed
Priority:
Normal
Category:
.NET API
Sprint/Milestone:
-
Start date:
2019-07-08
Due date:
% Done:

100%

Legacy ID:
Applies to branch:
9.9, trunk
Fix Committed on Branch:
9.9, trunk
Fixed in Maintenance Release:

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 ...

StackTrace.txt (17.6 KB) Report from Net JIT debugger Jan Pertermann, 2019-07-11 09:14 StackTrace.txt

History

#1 Updated by O'Neil Delpratt 2 months 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?

#2 Updated by O'Neil Delpratt 2 months 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.

#3 Updated by O'Neil Delpratt 2 months 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");

#4 Updated by Michael Kay 2 months 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.

#5 Updated by Jan Pertermann 2 months ago

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.

#6 Updated by Michael Kay 2 months 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.

#7 Updated by Jan Pertermann 2 months 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 ...

#8 Updated by Vladimir Nesterovsky 2 months ago

According to Microsoft there will be built-in java interop in .net 5.

See https://devblogs.microsoft.com/dotnet/introducing-net-5/

#9 Updated by O'Neil Delpratt 2 months 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.

#10 Updated by Jan Pertermann 2 months ago

Thanks for the link -- though that sounds very ambitious!

#11 Updated by O'Neil Delpratt 2 months 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.

#12 Updated by Michael Kay 2 months ago

Which might (or might not) mean that they plan to fork or rewrite IKVM to support .NET Core. We'll wait and see.

#13 Updated by O'Neil Delpratt 13 days 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

Also available in: Atom PDF