What happened to JAXB's NamespacePrefixMapper in JDK6u18

views:

878

answers:

+4 Q:

What happened to JAXB's NamespacePrefixMapper in JDK6u18

Hey

I've been using com.sun.xml.bind.marshaller.NamespacePrefixMapper in my project, and i had no problem with it in JDK 6u17. Now I just updated to 6u18, and I saw that it has been replaced to com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper. However if I import this class and try to compile my classes, I get the error:

package com.sun.xml.internal.bind.marshaller does not exist
import com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper;

I can access this package through the NetBeans code completion feature, and NetBeans does not highlight the code for errors.

Any help would be appreciated!

+2 A:

You are not supposed to use com.sun.** classes directly. They are deemed to be internal and subject to change without notice. (And look what just happened!!) The fact that the new class has internal in the package name is an even bigger hint!

I strongly suggest that you look for a better way of doing what you are doing ... that doesn't use the com.sun.** classes.

EDIT - hmmm, looks like whoever is responsible for the JAXB RI has broken the Sun rules about package names for that extension! And it is also unfortunate that Sun has not implemented this particular RI extension in JDK 6.0.

Stephen C 2010-02-24 13:08:38

in this case this is an API problem actually, because this feature is "advertised" as a way of determining namespace prefixes, and it is also a custom provider property. see http://java.sun.com/webservices/docs/1.5/jaxb/vendorProperties.html and http://fisheye5.atlassian.com/browse/~raw,r=1.600/jaxb-architecture-document/www/doc/com/sun/xml/bind/marshaller/NamespacePrefixMapper.html

Bozho 2010-02-24 13:17:14

(my point being - there is no better way to do this, and this is an essential feature)

Bozho 2010-02-24 13:22:54

+2 A:

Sun had made something not quite appropriate in this case. The namespace mapper isn't included in the spec, but it is "advertised" as a way to customize prefixes. So the general advice "don't use com.sun.*" doesn't apply here, and the javadoc of this class says:

Implemented by the user application to determine URI -> prefix mapping.

Check this article and see if it would work for you.

Bozho 2010-02-24 13:20:48

I do not agree with the suggested solution. Here, the OP explicitly needs to bundle the JAXB RI jars with his application (as I explain in my answer), `internal` stuff is meant to scare you away.

Pascal Thivent 2010-02-24 14:03:05

+2 A:

I don't think that the class com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper is a replacement of com.sun.xml.bind.marshaller.NamespacePrefixMapper, the former is there for a long time and it NOT MEANT TO BE USED BY YOU AT ALL (hence the internal packaging).

The problem here is that JavaSE 6 doesn't have the JAXB RI (it has a JAXB implemenation but not JAXB RI) so if you want to rely on RI specific feature, you should bundle JAXB RI in your application (and that would protect you from JAXB changes in Java SE).

Pascal Thivent 2010-02-24 14:01:17

that sounds logical, but then - why are these packages there?

Bozho 2010-02-24 14:09:56

(the blogpost I found says "Firstly, Java 6.0 now includes JAXB (which is great!) and so there is no longer any need to include the JAXB libraries in the classpath" - so that's incorrect?)

Bozho 2010-02-24 14:13:53

@Bozho As I wrote, Java 6 includes a JAXB implementation which is **not** JAXB RI so if you want to rely on a JAXB RI specific feature you should bundle it. So yes, the blog post is incorrect as the author was explicitly using a RI specific feature (which is why he faced problems with JavaSE changes, like the OP).

Pascal Thivent 2010-02-24 14:22:16

clear. But that's indeed confusing.

Bozho 2010-02-24 14:23:38

@Bozho It is indeed. But that `internal` packaging should make you run and look for another solution. Using `internal` is at best a temporary solution, you just don't know when it will break.

Pascal Thivent 2010-02-24 14:23:48

yes, but on the other hand you are already using something internal - it's in `com.sun`, and I doubt many people will instinctively look for the subtle difference

Bozho 2010-02-24 14:29:08

@Bozho `com.sun` stuff is already "tricky" (you're supposed to know what you're doing) so `com.sun.*.internal` is logically worse :) Anyway, in this particular case, discussing about this `internal` stuff is just a consequence of a wrong initial assumption (the mentioned class is not a replacement). Just ignore internal stuff and there is no issue.

Pascal Thivent 2010-02-24 14:37:02

Thanks for all the answers! I used `NamespacePrefixMapper` to "disable" prefixes, but since it is not very essential right now for me. So I will let the default prefix mapper work (or a more costful way; use string operations to replace prefixes).

wheelie 2010-02-24 14:45:23

@wheelie That's perfectly fine and you can continue to use it (but you need to bundle the jars of JAXB RI with your app).

Pascal Thivent 2010-02-24 14:52:49

@Pascal I bundled JAXB RI, and everything works fine! THANKS!

wheelie 2010-02-24 16:45:38

@Downvoter How could this possibly get downvoted??? The above answer is just the **correct** answer (and solved the problem). Downvoting it is totally ridiculous and just shows a total misunderstanding of the issue and of the solution.

Pascal Thivent 2010-07-28 20:51:02

ansaurus

tags:

views:

answers:

What happened to JAXB's NamespacePrefixMapper in JDK6u18

related questions