1

I want to know how some of special character automatically convert. Example Unicode: 0x3 is converted to (you can see this got converted &#three; . i have changed 3 to three) I am not sure how this convert automatically.
I am using java 1.6 and below is JAXB info.

xjc version "JAXB 2.1.10 in JDK 6" JavaTM Architecture for XML Binding(JAXB) Reference Implementation, (build JAXB 2.1.10 in JDK 6)

Above conversion happening on one of our test environment, however if i try to do same in my local machine i am getting below exception

        at javax.xml.bind.helpers.AbstractUnmarshallerImpl.createUnmarshalException(AbstractUnmarshallerImpl.java:315)
        at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.createUnmarshalException(UnmarshallerImpl.java:505)

I have spent a lot of time to figure this but not able to find any answer.Just to clear , i have checked and in code we do not have any escape custom class.

I have validated this jrocket jdk and as well as sun jdk but i have same problem. In test environment we are having jrocket jdk.

Is some face same issue ? Is this issue related to JAXB or it can be related to java ?

Prateek Shaw
  • 13
  • 5
  • 1
    Can't say for sure, but jdk 6 is pretty ancient and since jdk 9+ is no longer backwards compatible, have you tried updating your jdk to something newer. Actually thinking about it it's likely this is the issue as jdk 9+ represents String as UTF8, jdk 9- (!) I think used UTF16. – Bill Naylor Jan 09 '20 at 17:21
  • Thank Bill for reply. One place it is working with 1.6 and one place it is not. So i am not sure what to look for and compare them. – Prateek Shaw Jan 09 '20 at 18:13
  • As I mentioned in the last part of my comment, this could be an issue between UTF8 encoding (which allows multiple - up to 4 (?) bytes), this is to allow loads of character sets including many Chinese Japanese even Ogham, instead of being stuck with just two byte encoding. Can you not just install jdk 9 or a more recent one and see if that works? – Bill Naylor Jan 09 '20 at 18:59
  • BTW another advantage of UTF8 is that for Roman aphanumeric characters (ones that fit in the first 7 bits) they only take up 1 byte rather than 2 (for UTF 16). – Bill Naylor Jan 09 '20 at 19:02
  • it could be that the (three;) entity is not defined in the schema that you are referencing and this is being dealt with differently by the different jdk's? – Bill Naylor Jan 09 '20 at 19:25
  • I am look this question at different point view, let us assume there is problem with character, but i want to know where it is converting it ? Ideally it is not done by java or encoding. I googled it and we have write escape logic to do this. – Prateek Shaw Jan 09 '20 at 19:42
  • I also want to add , that we also using SOAP web service , is there any way because of SOAP library. It is using different implementation. – Prateek Shaw Jan 09 '20 at 19:51
  • These are quite a lot of details that are missing from your post! Which is the SOAP library, is it compatible with the other elements of your framework? If I where you, I would look at the differences between your local config and your 'test environment' (as that is where you get a correct response?) – Bill Naylor Jan 09 '20 at 19:58
  • Basically because of conversion , it is not throwing above exception. In my local conversion is not happening and i can see xml file is being created with this special character so marshaling is working , but when it is try to unmarshal then it is throwing exception. – Prateek Shaw Jan 09 '20 at 19:58
  • We are using SOAP library which come by default from java. – Prateek Shaw Jan 09 '20 at 20:00
  • from you penultimate comment it looks like this is a problem with de-serialisation, which could well be because of the jdk 9+ issue I mentioned above. have you tried using jdk 9? – Bill Naylor Jan 09 '20 at 20:03
  • I have not yet , i will try , but if you have any idea where i can look for escaping code that would be great , i am dividing this problem in two parts 1-need to see where escaping happening 2-then work on de-serialization issue – Prateek Shaw Jan 09 '20 at 20:06
  • Is there anyway possible to know where escaping is happening ? It is possible that some jdk support default escaping . – Prateek Shaw Jan 09 '20 at 20:15
  • From your description of the problem, I don't think this is a programmatic issue, i.e. I don't think escaping can help you. I think it is just a matter of using an up to date java. The encoding stuff all happens in the core of the JVM. – Bill Naylor Jan 09 '20 at 21:44
  • Prateek, could you confirm whether or not upgrading the jdk fixed this issue, or if there is a reason why you can't use an up to date java? – Bill Naylor Jan 11 '20 at 16:52
  • Hi Bill , I have two applications, one is in jDK 1.8 and one is JDK 1.6. And it is not working in JDK 1.8. I can not use any different version. I know we have used two different JDK , in 1.6 it is jrocket and 1.8 it sun. – Prateek Shaw Jan 13 '20 at 16:49
  • Think you might be stuffed then, sorry. But there has been (amongst a few) a breaking change with going to java 9 which is moving to UTF8 representation for Strings. This is a positive change going forward, though seems (I think) to cause issues link the one you are seeing. Can you prove this is the issue (by making another instance working on JDK 1.9), that would be positive for other users of the forum! – Bill Naylor Jan 13 '20 at 19:07
  • Hi , i have validated and i got the same error. However i have found that there is some changes in jdk 9 http://openjdk.java.net/jeps/320. Default jaxb and web service classes ar not in class path. – Prateek Shaw Jan 14 '20 at 19:04

0 Answers0