access restriction
Jpcapネットワークを使用してパケットをキャプチャする場合、前期はすべて正常に使用されます.しかし、今日jre環境を調整したところ、Access restriction:The type JpcapCaptor is not accessible due to restriction on required library C:WindowsSunJavalibextjpcap.jar
会資料を調べて、このブログを見つけました.一番よく書いてあるような気がします.詳しくは、自分で転載してきたので、書くのに時間がかかりませんでした.
http://hi.baidu.com/ccst2005/blog/item/c8f84a223172d0f4d6cae24b.html
主な問題はAccess restrictions on Jarsで、jarパッケージへのアクセスが制限されていることです.検索したところ、主に期限切れのAPIがサポートされていないことがわかりました.期限切れのものは使うときは気をつけてください.ついでに資料を集めて、後で使いましょう.
http://www.eclipsezone.com/eclipse/forums/t97259.html
When developing plug-in projects, you may occasionally get a message saying "The type X is not accessible due to restriction on required project Y". The basic reason for this message is that the dependency of one project to another's exported packages doesn't match what you're expecting. If you depend on a bundle "Wall"that exports package "wall", and you import "wall.Brick"then that'll work fine. If, on the other hand, you import "wall.test.Brick"(and assume that the only mentioned export is Export-Package: wall) then you'll get this restriction error. You may also get it when depending on a specific version of the JRE (or an OSGi execution environment). That's because whilst the standard class packages (e.g. java.util etc.) are exported, the extras that come with the JRE (e.g. sun.misc.Base64Encoder) aren't technically part of the Java core libraries, and thus shouldn't be assumed to exist (there is a Apache Commons Codec project that contains a Base64 if you need it). You can view and edit the access rules for individual Jars or JREs; you can also specify them implicitly with the Manifest.MF's Import-Package or Require-Bundle rules (for consumers of APIs) or the Export-Package (for producers of APIs). If an OSGi manifest is provided, it will automatically set up access rules for all exported packages and hide all non-imported packages. (In addition, it's also possible to mark package references as 'internal' which is done by showing what down-stream plugins can consume particular APIs, although this should rarely be needed.) One final point; if you're setting up multiple plug-ins, then use the OSGi manifest to express dependencies. Don't add Jars via the .classpath (or the GUI equivalent Java Build Path) -- and whatever you do, don't export the 'required plugin dependencies' container to downstream projects; in 3.2, this could result in an access rule visibility error even when the OSGi manifests were correct. (It's fixed in 3.3.) For those of you not using Eclipse PDE, then the net effect is that you'll end up with bundles looking like this:
It's worth noting that the x-friends and x-internal are aspects unique to Equinox; they're not part of the standard OSGi specification. The 'common-split' is not part of the spec either, but the 'mandatory' lists attribute names (including 'common' in this case) which are needed for an importer to use those packages. Since the org.eclipse.core.runtime bundle explicitly requires the org.eclipse.equinox.common bundle, and then re-exports it, it presents a unified classpath for those wishing to use the org.eclipse.core.runtime package which acts in just this way.
(次の方法は指標が根本的ではなくダチョウアルゴリズムに属する~errorをwarningやignoreに変えただけ)
[Eclipse] Access restriction: Class is not accessible due to restriction on required library
"Access restriction: Class is not accessible due to restriction on required library"; error message may be shown while developing Java projects in Eclipse IDE. Error message is self-explanatory, some classes can not be loaded into the project since restriction rules are being imposed on those classes.
How to solve
This error message can be removed by changing a setting inside Eclipse IDE. Open up the dialog box shown below, using any of the following paths.
Windows -> Preferences -> Java -> Compiler -> Errors/Warnings
(Project) Properties -> Java Compiler -> Errors/Warnings
Locate the "Forbidden reference (access rules)"option under "Deprecated and restricted API"section in the dialog box. This option decides how to handle access rules defined inside Eclipse. By default it is set to "Error"which causes Eclipse to complain about references to any restricted classes. Choosing any other option (Warning or Ignore) will remove these error messages."Warning"or "Ignore"options will only hide the potential issue in the project, by allowing the project to use any classes ignoring predefined access rules. To completely resolve this issue, analyze the project and located the use of restricted classes and take necessary actions (either remove those references or access rules).
会資料を調べて、このブログを見つけました.一番よく書いてあるような気がします.詳しくは、自分で転載してきたので、書くのに時間がかかりませんでした.
http://hi.baidu.com/ccst2005/blog/item/c8f84a223172d0f4d6cae24b.html
主な問題はAccess restrictions on Jarsで、jarパッケージへのアクセスが制限されていることです.検索したところ、主に期限切れのAPIがサポートされていないことがわかりました.期限切れのものは使うときは気をつけてください.ついでに資料を集めて、後で使いましょう.
http://www.eclipsezone.com/eclipse/forums/t97259.html
When developing plug-in projects, you may occasionally get a message saying "The type X is not accessible due to restriction on required project Y". The basic reason for this message is that the dependency of one project to another's exported packages doesn't match what you're expecting. If you depend on a bundle "Wall"that exports package "wall", and you import "wall.Brick"then that'll work fine. If, on the other hand, you import "wall.test.Brick"(and assume that the only mentioned export is Export-Package: wall) then you'll get this restriction error. You may also get it when depending on a specific version of the JRE (or an OSGi execution environment). That's because whilst the standard class packages (e.g. java.util etc.) are exported, the extras that come with the JRE (e.g. sun.misc.Base64Encoder) aren't technically part of the Java core libraries, and thus shouldn't be assumed to exist (there is a Apache Commons Codec project that contains a Base64 if you need it). You can view and edit the access rules for individual Jars or JREs; you can also specify them implicitly with the Manifest.MF's Import-Package or Require-Bundle rules (for consumers of APIs) or the Export-Package (for producers of APIs). If an OSGi manifest is provided, it will automatically set up access rules for all exported packages and hide all non-imported packages. (In addition, it's also possible to mark package references as 'internal' which is done by showing what down-stream plugins can consume particular APIs, although this should rarely be needed.) One final point; if you're setting up multiple plug-ins, then use the OSGi manifest to express dependencies. Don't add Jars via the .classpath (or the GUI equivalent Java Build Path) -- and whatever you do, don't export the 'required plugin dependencies' container to downstream projects; in 3.2, this could result in an access rule visibility error even when the OSGi manifests were correct. (It's fixed in 3.3.) For those of you not using Eclipse PDE, then the net effect is that you'll end up with bundles looking like this:
Manifest.MF
Bundle-SymbolicName: example
Export-Package:
com.example.public, // Anyone can access com.example.public if imported
com.example.test;x-internal:=true, // This is marked as internal, but can be used
com.example.impl;x-friends:=com.example.other, // Only com.example.other should access it
com.example.split;common="split";mandatory:="common" // Split is a split packageIt's worth noting that the x-friends and x-internal are aspects unique to Equinox; they're not part of the standard OSGi specification. The 'common-split' is not part of the spec either, but the 'mandatory' lists attribute names (including 'common' in this case) which are needed for an importer to use those packages. Since the org.eclipse.core.runtime bundle explicitly requires the org.eclipse.equinox.common bundle, and then re-exports it, it presents a unified classpath for those wishing to use the org.eclipse.core.runtime package which acts in just this way.
(次の方法は指標が根本的ではなくダチョウアルゴリズムに属する~errorをwarningやignoreに変えただけ)
[Eclipse] Access restriction: Class is not accessible due to restriction on required library
"Access restriction: Class is not accessible due to restriction on required library"; error message may be shown while developing Java projects in Eclipse IDE. Error message is self-explanatory, some classes can not be loaded into the project since restriction rules are being imposed on those classes.
How to solve
This error message can be removed by changing a setting inside Eclipse IDE. Open up the dialog box shown below, using any of the following paths.
Windows -> Preferences -> Java -> Compiler -> Errors/Warnings
(Project) Properties -> Java Compiler -> Errors/Warnings
Locate the "Forbidden reference (access rules)"option under "Deprecated and restricted API"section in the dialog box. This option decides how to handle access rules defined inside Eclipse. By default it is set to "Error"which causes Eclipse to complain about references to any restricted classes. Choosing any other option (Warning or Ignore) will remove these error messages."Warning"or "Ignore"options will only hide the potential issue in the project, by allowing the project to use any classes ignoring predefined access rules. To completely resolve this issue, analyze the project and located the use of restricted classes and take necessary actions (either remove those references or access rules).