com.sun.xml.internal.ws.client does not exist

Question

I'm trying to catch ClientTransportException and my program fails on compilation stage with the following exception

[ERROR]\workspace\rates\java\service\bundle1\src\main\java\com\connector\ws\TestClass1.java:[72,70] package com.sun.xml.internal.ws.client does not exist

As I know this package is from rt.jar and exist in jre

If I add @SuppressWarnings("restriction") it compiles from Eclipse Maven Plugin, but not from IntelliJ Idea(via maven) or command line neither.

When I remove @SuppressWarnings Eclipse show the following warning

Access restriction: The type ClientTransportException is not accessible due to restriction on required library C:\Program Files\Java\jre6\lib\rt.jar

I've found similar question but it's answer isn't clear enough for me cause I can this class in rt.jar and my IntelliJ Idea can see it either.

Can someone explain such behavior and possible solution for it?

See http://stackoverflow.com/questions/860187/access-restriction-on-class-due-to-restriction-on-required-library-rt-jar , maybe it will help. — tibtof, May 16 '12 at 08:45
Thanks, I'm reading it right now, but I see only one implementation of ClientTransportException in my project. — Alexander Zhugastrov, May 16 '12 at 08:52
[Why Developers Should Not Write Programs That Call 'sun' Packages](http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html) — Jesper, May 16 '12 at 08:55
Thanks, @Jesper, I have already read this article in [this question](http://stackoverflow.com/questions/1269319/package-com-sun-xml-internal-bind-v2-model-annotation-does-not-exist) but it tells that I **shouldn't use it** but still I can. Unfortunately I need to catch this exception it caused by legacy of our progect — Alexander Zhugastrov, May 16 '12 at 09:03

score 23 · Answer 1 · answered Aug 19 '13 at 17:28

23

According to this FAQ it's a bad practice to directly call 'sun' packages. When I ran into the same problem it was fixed by catching javax.xml.ws.WebServiceException instead (as sugested by artbristol).

answered Aug 19 '13 at 17:28

BrunoPires

383
3
9

alain.janinm · Answer 2 · 2018-08-16T10:46:14.283

You can get rid of this error using :

javac -XDignore.symbol.file=true

That's the argument to pass to javac to use rt.jar instead of ct.sym (ct.sym is used by default and required for compiling to a target older version)

ct.symdoes not contains all classes from rt.jar. Because using sun.* classes should not be used the class stub for them might not be present in in ct.sym making the compilation fails.

Removing calls to sun.* should remove this issue. (It's a bad practice to use sun packages)

References :

https://blogs.oracle.com/geertjan/ctsym-steals-the-asm-class

The truth of the matter is that there's something called "ct.sym" in the JDK. When javac is compiling code, it doesn't link against rt.jar. Instead, it uses a special symbol file lib/ct.sym with class stubs. Internal JDK classes are not put in that symbol file, since those are internal classes. You shouldn't want to use them, at all.

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6778491

This is not a compiler issue. javac is behaving correctly, according to the information provided in ct.sym. The issue belongs with those who decide what should be available with (and what should be hidden by) ct.sym I cannot as yet determine the correct category for this bug. This is intentional. Perhaps the package name "com.sun.xml.internal...." might be seen as a hint. Users should not write code that depends on internal JDK implementation classes. Such classes are internal implementation details of the JDK and subject to change without notice.

http://openjdk.java.net/jeps/247

For JDK N and --release M, M < N, signature data of the documented APIs of release M of the platform is needed. This data is stored in the $JDK_ROOT/lib/ct.sym file, which is similar, but not the same, as the file of the same name in JDK 8. The ct.sym file is a ZIP file containing stripped-down class files corresponding to class files from the target platform versions. For JDK N and --release N,the JDK's own image is used as the source of the class files to compile against. The list of observable modules is limited, however, to the documented modules and the jdk.unsupported module.

NOTE

In this case, it would be better to not use the ClientTransportException class and replaced it by javax.xml.ws.WebServiceException, as suggested by artbristol.

@Thomas Yes, unfortunately I remember the article was quite long so I didn't quote it in the answer. Currently I can't find a new website where Andrew Haley reposted it... — alain.janinm, Oct 17 '13 at 12:14
@sorin7486 I've removed this old link and tried to add some understandable explanation. — alain.janinm, Feb 23 '18 at 11:32

score 4 · Answer 3 · answered Apr 27 '16 at 11:07

4

Jre System library restricts some packages access to compiler, while they are accessible to JDK. In that case there will be no error in code but when compiling it will show errors like class not found or package not found.

In that case there are two practices. 1) Add rt.jar of jre system library to your build path for compiling and building. 2) Add jaxws-rt.jar in your build path.

Second option is a good option as it will avoid adding duplicate libraries to your build path.

answered Apr 27 '16 at 11:07

Fakhar uddin Malik

89
4

How to do that? could you explain this? I got a similar error here is : "package com.sun.xml.internal.ws.developer does not exist" only "clien" and "developer". Could you explain your solution and how to I do that? – luffy Jun 30 '16 at 13:05
Go to properties of your project, where you add system libraries. you would have an option to add jre system library. add it to your build path. error should be resolved. – Fakhar uddin Malik Jul 26 '21 at 13:02

score 4 · Answer 4 · answered May 23 '18 at 15:57

4

import this dependency in pom.xml

   <dependency>
        <groupId>com.sun.xml.ws</groupId>
        <artifactId>jaxws-rt</artifactId>
        <version>2.1.4</version>
   </dependency>

answered May 23 '18 at 15:57

Ajay Kumar

4,864
1
41
44

score 4 · Answer 5 · answered May 14 '20 at 18:00

The solution is quite simple: when you copy the ready-made code or write the code first and then load the dependencies, there is a dependency conflicts. com.sun.xml.* package is already part of JDK8, but Maven does not see it when compiling. So make sure that you use the package from mvn:repo:/...rt.jar not jdk* / .../rt.jar.

score 3 · Answer 6 · answered Aug 10 '15 at 14:12

Even in 2015, I've found many projects that use this bad practice of importing com.sun.* packages.

If you (like me) can't change the classes importing those packages, adding rt.jar to your classpath should do the trick.

Note that the said rt.jar is usually found under <jdk_home>/jre/lib folder.

score 2 · Answer 7 · answered Apr 06 '17 at 13:59

2

Even I was facing same issue in my maven project. I had imported import com.sun.xml.internal.ws.client.ResponseContext; in one of class file but this was not in use. I just commented the line in my class file and the error stopped and i could successful run my maven project.

answered Apr 06 '17 at 13:59

Chethan Shetty

21
1

Ahah, quite the same for me... In my case I mistakenly added `import com.sun.xml.internal.ws.policy.AssertionValidationProcessor` with the auto completion but I wanted `org.junit.Assert`... – potame Jul 06 '20 at 14:25

score 2 · Answer 8 · answered May 25 '21 at 03:19

For maven build adding the following plugin will resolve the issue.

Basically adding the compiler arguments to refer correct path of tools.jar

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
        <configuration>
            <source>1.8</source>
            <target>1.8</target>
            <compilerArguments>
                <bootclasspath>${java.home}/lib/rt.jar${path.separator}${java.home}/lib/jce.jar${path.separator}${java.home}/../lib/tools.jar</bootclasspath>
            </compilerArguments>
        </configuration>
    </plugin>

score -1 · Answer 9 · answered Dec 06 '17 at 14:27

-1

You should not use com.sun.* packages. We could solve the problem by using our own class instead:

/**
 * Copy of com.sun.xml.internal.ws.client.BindingProviderProperties since we're
 * not allowed to use com.sun.* packages..     
 */
public final class BindingProviderProperties {
    public static final java.lang.String CONNECT_TIMEOUT = "com.sun.xml.internal.ws.connect.timeout";
    public static final java.lang.String REQUEST_TIMEOUT = "com.sun.xml.internal.ws.request.timeout";
}

answered Dec 06 '17 at 14:27

Paul Rambags

639
7
5

How will this help if those properties are not even used internally? What's the point of setting them? – lovrodoe May 13 '21 at 07:12
You says that we should not use `com.sun.xml`. But you use it as package name, so you use it. – Mikhail Ionkin Dec 02 '21 at 08:32

com.sun.xml.internal.ws.client does not exist

9 Answers9

References :

Linked