By sal


2009-05-13 20:16:26 8 Comments

I'm attempting to compile Java 1.4 code that was created by IBM's WSDL2Java on Java5 without recreating the stubs and saw this error in Eclipse. I'm under the assumption that the stubs generated should just compile as long as the runtime jars are available (they are).

Access restriction: The type QName is not accessible due to restriction on required library C:\Program Files\Java\jdk1.5.0_16\jre\lib\rt.jar

The full class name is javax.xml.namespace.QName

What exactly is going on here? Is this a case where I am trying to refactor a pig from sausage? Am I better off recreating the stubs?

15 comments

@Nels Beckman 2010-02-01 04:09:13

There's another solution that also works.

  1. Go to the Build Path settings in the project properties.
  2. Remove the JRE System Library
  3. Add it back; Select "Add Library" and select the JRE System Library. The default worked for me.

This works because you have multiple classes in different jar files. Removing and re-adding the JRE lib will make the right classes be first. If you want a fundamental solution make sure you exclude the jar files with the same classes.

For me I have: javax.xml.soap.SOAPPart in three different jars: axis-saaj-1.4.jar, saaj-api-1.3.jar and the rt.jar

@Dan Burton 2010-11-30 21:17:25

+1 Working on a school lab computer (where I don't have permission to modify many things), this worked like a charm. Thank you.

@docwhat 2011-03-07 05:28:13

Is it an Eclipse bug or are we accidentally working-around the restriction (and violating the license terms)? If it's an Eclipse bug, then is there a bug filed?

@Nels Beckman 2011-03-07 19:50:05

@Doctor I never used this for any code that was particularly important, so I didn't investigate any further... If you find anything out please let us know.

@URL87 2012-06-04 12:29:46

where is "Add Library" in eclipse ?

@Alexei Blue 2012-06-14 09:57:12

@URL87 If you right click on the project folder go to "Build Path...", "Configure Build Path", "Libraries" (tab), you should see "Add Library" as one of the buttons on the right... This worked a charm for me as well, excellent answer

@user1676075 2013-11-12 13:08:50

The better solution under recent versions of Eclipse is not to delete the JRE System Library, but to go to "Order and Export" tab and just move JRE System Library to the bottom (which is effectively what deleting and adding it does, but you don't need to delete and add to do it).

@ggb667 2014-02-12 18:00:00

You might need to un-check the allow projects to override and also change the workspace java compliance settings.

@MattC 2015-03-17 01:29:48

And for me it was not the same JRE System Library that I added back. In my case it was originally 5, and I when I went to add back in, the default pointed to 7. Thanks!

@Dominic Cerisano 2015-09-24 23:48:34

Switched from openJDK to sunJDK for the proprietary codecs, then I got this "restrictions" error and thought I was overflowed. Thanks.

@ttulinsky 2017-08-02 17:52:24

I put the JRE lib at the bottom of the order list, then deleted and re-added it. When at the bottom of the list I got errors: The method getTextContent() is undefined for the type Element. Then I put it back at the top of the list and it finally worked. Eclipse Neon, JDK 1.8. – ttulinsky 16 hours ago

@Amudhan Bala 2018-04-04 13:34:55

This is 2018 and eclipse version is 5.0. This bug/problem still exists. Thanks a lot @NelsBeckman. Your answer has helped me after 3/4 of decade since it was posted.

@Phillip 2019-06-30 04:10:59

Right clicking on the project and choosing 'Refresh Gradle project' always seems to undo any of these changes

@Abhishek Soni 2017-08-16 06:40:31

Adding a right JRE System through build path is the solution but your eclipse still may have the error. To solve that go to Java Build path --> Order and Export and move your JRE system library on the top. This has solved my problem.

@Soumyajit Swain 2014-03-19 05:59:30

In my case there was a mismatch between the build path JRE and installed JRE on execution environment. I moved into Project > Properties > Java compiler. There was a warning message at the bottom.

I clicked on the links 'Installed JRE', 'Execution environment', 'Java build path' and changed the JDK version to 1.7 and the warning disappeared.

@usertest 2016-03-20 18:40:23

for me this how I solve it:

  • go to the build path of the current project

under Libraries

  • select the "JRE System Library [jdk1.8xxx]"
  • click edit
  • and select either "Workspace default JRE(jdk1.8xx)" OR Alternate JRE
  • Click finish
  • Click OK

enter image description here

Note: make sure that in Eclipse / Preferences (NOT the project) / Java / Installed JRE ,that the jdk points to the JDK folder not the JRE C:\Program Files\Java\jdk1.8.0_74

enter image description here

@Marvo 2018-08-06 19:56:03

Mine was already set to 1.7...79, so I was panicking. But I simply selected it again, clicked Apply, and the error went away. Whew.

@hyphan 2019-06-26 14:32:19

Wow. This helped here too - changing from an "execution environment" to an "alternate JRE". If anyone has any logical explanation for this.. (here it occurred after changing the project-faucet Java from 1.5 (5.0 in the .settings config file) to 1.8. Changing from error to warning in global prefs (see other answer) did not help: still errors. Its about old sun classes we use from package com.sun.image.codec.*)

@modulitos 2014-06-01 03:41:08

In addition to Nels Beckman's solution, I have the following tips:

Under Configure Build Path, I had to rearrange the order of my entries under Order and Export.

Additionally, as an Eclipse PDE developer, I needed to rearrange the order of my dependencies in my MANIFEST.MF, adding the problematic package as first on the list.

Playing with these dials, along with running Project > Clean in between, I was able to resolve these warnings.

@Vijay Bhatt 2015-02-16 11:51:56

Go to the Java Build Path in the project properties. Remove the existing JRE System Library Then Add it again i.e. Add Library-->JRE Lib--select jre--->Finish. Lastly select order and export tab select JRE Lib and move on top. That's it.

@scommab 2010-01-16 03:21:17

http://www.digizol.com/2008/09/eclipse-access-restriction-on-library.html worked best for me.

On Windows: Windows -> Preferences -> Java -> Compiler -> Errors/Warnings -> Deprecated and restricted API -> Forbidden reference (access rules): -> change to warning

On Mac OS X/Linux: Eclipse -> Preferences -> Java -> Compiler -> Errors/Warnings -> Deprecated and restricted API -> Forbidden reference (access rules): -> change to warning

@Adrian Mouat 2010-10-07 08:27:25

This might work, but it is not a proper solution. You need to understand why the access restriction existed in the first place. It will also hide all future cases of this, which may be more important!

@stolsvik 2011-12-14 14:44:28

@AdrianMouat that is pretty much irrelevant. If I want it to go away, I want it to go away. But surely - one shalln't code against non-public APIs, no.

@Adrian Mouat 2011-12-16 09:13:03

@stolsvik - you've lost me; are you saying the reason why the problem exists is irrelevant?

@will 2012-08-29 11:54:15

I have this problem on ONE method. I imagine the use of an alternative JDK (like OpenJDK is a better option). That said for one thing it 'might be cool' once. NOT in production code. Not for an on going design effort. I can't tell you how many man-days get lost on this kind of cr-hack.

@david blaine 2013-05-28 07:56:35

@AdrianMouat - makes sense. I'd hate to do something like this in a nuclear reactor - Too much heat in control room ? So, disable all warnings. Make big headlines next day. :P

@user1073494 2013-09-11 20:45:04

actually, I was having this "error" message when I set the JRE to one of those default "execution environments" in Eclipse. Even if I bind the execution environment to the exact match JDK, eclipse still insists to say it's an error, so disabling the warning was actually a pretty good solution for me.

@Stef 2014-12-11 03:08:28

This solved it for me. The other answer didn't. That's because I work on a project where we use lots of deprecated code (very old codebase) and unfortunately it's not gonna change too soon. So this solution is the only one that works.

@muyong 2016-09-22 15:37:55

This also work for me. My project was built with Java 7 but now I changed to 8, so the version change may be the reason. Delete the JRE System Libraries them add it back doesn't help.

@Samitha Chathuranga 2014-07-28 16:57:05

Just change the order of build path libraries of your project. Right click on project>Build Path> Configure Build Path>Select Order and Export(Tab)>Change the order of the entries. I hope moving the "JRE System library" to the bottom will work. It worked so for me. Easy and simple....!!!

@DuffJ 2013-09-06 12:31:50

I have been getting this error too, but my project is built on the command line using Maven and the tycho compiler (it's a set of OSGi plugins). After masses of sifting through people having the same problem but fixing it in Eclipse rather than on the command line, I found a message on the Tycho developer forum that answered my question, using configuration in pom.xml to ignore the compiler warning about the access restriction:

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>tycho-compiler-plugin</artifactId>
    <version>${tycho.version}</version>
    <configuration>
        <compilerArgument>-warn:+discouraged,forbidden</compilerArgument>
    </configuration>
</plugin>

More information can be found in the Tycho FAQ. This took me AGES to work out, so I figured I would assist anyone else trying to fix these access restriction errors from the command line by posting this answer.

@Arun B Chandrasekaran 2013-05-24 10:51:46

Sorry for updating an old POST. I got the reported problem and I solved it as said below.

Assuming you are using Eclipse + m2e maven plugin, if you get this access restriction error, right click on the project/module in which you have the error --> Properties --> Build Path --> Library --> Replace JDK/JRE to the one that is used in eclipse workspace.

I followed the above steps and the issue is resolved.

@Steven Wolfe 2013-06-27 03:46:35

Fair enough, but you've basically replicated the wording of the accepted answer by Nels Beckman.

@Mr. Napik 2013-04-01 15:18:17

In the case you are sure that you should be able to access given class, than this can mean you added several jars to your project containing classes with identical names (or paths) but different content and they are overshadowing each other (typically an old custom build jar contains built-in older version of a 3rd party library).

For example when you add a jar implementing:

a.b.c.d1
a.b.c.d2

but also an older version implementing only:

a.b.c.d1
(d2 is missing altogether or has restricted access)

Everything works fine in the code editor but fails during the compilation if the "old" library overshadows the new one - d2 suddenly turns out "missing or inaccessible" even when it is there.

The solution is a to check the order of compile-time libraries and make sure that the one with correct implementation goes first.

@sanwanxian 2009-11-23 05:55:30

I met the same problem. I found the answer in the website:http://www.17ext.com.
First,delete the JRE System Libraries. Then,import JRE System Libraries again.

I don't know why.However it fixed my problem,hope it can help you.

@Nels Beckman 2011-01-19 21:31:36

Huh, apparently you answered this question the same way as I did, several months before. Not sure why I didn't see your answer back then...

@Dorus 2011-07-01 09:46:10

I just had this problem too. Apparently I had set the JRE to 1.5 instead of 1.6 in my build path.

@Greg Haskins 2013-11-11 20:39:41

Same issue here. In my case, using Maven which defaults to 1.5 if unspecified.

@Philip Rego 2018-03-23 15:38:11

Remember to put this in your POM so it doesn't change back when updated. <properties> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> </properties>

@Peter Lawrey 2009-05-13 20:30:04

My guess is that you are trying to replace a standard class which ships with Java 5 with one in a library you have.

This is not allowed under the terms of the license agreement, however AFAIK it wasn't enforced until Java 5.

I have seen this with QName before and I "fixed" it by removing the class from the jar I had.

EDIT http://www.manpagez.com/man/1/java/ notes for the option "-Xbootclasspath:"

"Applications that use this option for the purpose of overriding a class in rt.jar should not be deployed as doing so would contravene the Java 2 Runtime Environment binary code license."

The http://www.idt.mdh.se/rc/sumo/aJile/Uppackat/jre/LICENSE

"Java Technology Restrictions. You may not modify the Java Platform Interface ("JPI", identified as classes contained within the "java" package or any subpackages of the "java" package), by creating additional classes within the JPI or otherwise causing the addition to or modification of the classes in the JPI. In the event that you create an additional class and associated API(s) which (i) extends the functionality of the Java platform, and (ii) is exposed to third party software developers for the purpose of developing additional software which invokes such additional API, you must promptly publish broadly an accurate specification for such API for free use by all developers. You may not create, or authorize your licensees to create, additional classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun" or similar convention as specified by Sun in any naming convention designation."

@sal 2009-05-14 03:14:03

that's it. one of the jars in the path had the QName class in it. find . -name "*.jar" -print -exec unzip -t {} \; |grep "QName" found it.

@Adrian Mouat 2010-10-07 08:25:57

Could you provide a reference about not being allowed to replace classes which ship with Java? All I found in the licence agreement was restrictions related to distributing Java itself, not Java programs, but I didn't look for very long.

@Mayur 2010-03-31 19:09:48

  • Go to the Build Path settings in the project properties. Windows -> Preferences -> Java Compiler
  • Remove the JRE System Library
  • Add another JRE with a "perfect match"
  • clean and build your project again. It worked for me.

Related Questions

Sponsored Content

17 Answered Questions

1 Answered Questions

[SOLVED] Gradle, rt.jar access restriction

10 Answered Questions

1 Answered Questions

2 Answered Questions

5 Answered Questions

[SOLVED] Access restriction on sun.security.pkcs11.SunPKCS11

2 Answered Questions

[SOLVED] What does a "restricted library" really mean in Java?

2 Answered Questions

Sponsored Content