aspose file tools*
The moose likes Java in General and the fly likes references to com.sun.xml.internal won't compile Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "references to com.sun.xml.internal won Watch "references to com.sun.xml.internal won New topic
Author

references to com.sun.xml.internal won't compile

Maksim Volf
Greenhorn

Joined: Jan 23, 2013
Posts: 3
I have this class:
================

================

And it won't compile.
Here's the verbose from it:
-----------------------------------

--------------------------------

Why can't I compile it?
Both classes are obviously in the same rt.jar, but only one of them fails.
Any help?

...
Why do I need this one may wonder?
This is the default fallback for javax.xml.stream.XMLInputFactory and spring chokes on it. So I am trying to research what made it want the default fallback and why it won't work.
see newInstance() in XMLInputFactory:
===========
public static XMLInputFactory newInstance()
throws FactoryConfigurationError
{
return (XMLInputFactory) FactoryFinder.find(
"javax.xml.stream.XMLInputFactory",
"com.sun.xml.internal.stream.XMLInputFactoryImpl");
}
===========

But regardless, I have seen this issue in many threads:
package com.sun.xml.internal.<something> does not exist.
Feels like it's "sacred" and "forbidden".
Any light on this, please?

Thanks.
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

Maksim Volf wrote:Feels like it's "sacred" and "forbidden".
Any light on this, please?

Thanks.

I don't know about 'sacred' but it is not part of the public API and thus likely to change from version to version or implementation to implementation. SO you should not rely on its existence. My guess is that you are running on a JRE/JDK which does not have that package or class. And though it may exist in the rt.jar you are looking at it perhaps it does not in the one you compile with. My guess with the framework you are using is that it too is suffering from mis-matched JAR files (parts of the JRE pulled out and run in a different context or something? Class loaders looking at two different lib directories?)
Maksim Volf
Greenhorn

Joined: Jan 23, 2013
Posts: 3
No, I swear it's sacred.
This code

produces the output:
com.sun.xml.internal.stream.XMLInputFactoryImpl
but I still can't declare a variable of that type.
Sacred I tell ya!

But I guess you're right about my original research: some jar somewhere is not what it should be... back to square 2.
Tony Docherty
Bartender

Joined: Aug 07, 2007
Posts: 2410
    
  50
Welcome to the Ranch.

The first class you showed compiles on my system under but as Steve has already said you shouldn't use them as there is no guarantee they will be available in future releases or other JDK's - see this article
Maksim Volf
Greenhorn

Joined: Jan 23, 2013
Posts: 3
At first I was going to let it go and just accept it as sacred. But now that you said it compiles, I got puzzled.
When I just run javacstraight up without any tweaks, it spits out the search path that you can see in my original post, which includes the same rt.jar I'm using, but fails to compile.
Now, when I clear bootclasspath and extdirs as follows:
javac -extdirs . -bootclasspath . -classpath C:\Java\jdk1.6.0_33\jre\lib\rt.jar -verbose One.java
it works all of a sudden.
So, the conclusion is: the other jars in the bootclasspath break the compilation.
But I'm guessing you didn't have to do that to compile it, so my Java is broken in ways I cannot comprehend.

Reinstall...

Thanks for your help.
Tony Docherty
Bartender

Joined: Aug 07, 2007
Posts: 2410
    
  50
I compiled it via Eclipse using "Java(TM) SE Runtime Environment (build 1.6.0_35-b10)"

Sorry I can't be of more help but I have no idea why you are seeing the behaviour you have outlined.
 
 
subject: references to com.sun.xml.internal won't compile