import sun.audio.AudioPlayer;
import sun.audio.AudioStream;
上面这两句都报“Access restriction: The type AudioPlayer is not accessible due to restriction on required library C:\JDK1.5\jre\lib\rt.jar”的错误
最开始我还以为是rt.jar有问题了，按照网上的办法把JRE System Library给remove掉，然后重新加进来，问题依旧。同事提示我是JDK版本有问题，他用的是JDK5，我的是JDK6，我抱着试试看的心理卸载掉了6装上了5，当时是没问题了，可是回家之后问题再次重现了。
家里的环境是JDK1.5.0_u22，单位是u6，在u22编译下，问题再次发生。于是我怀疑这个问题不是出在JDK的版本上，JDK5和6中SwingUtilities的兼容性有一些问题（），但是对sun.audio.*的兼容性有问题我还没有听说过，所以我又开始查是不是Eclipse有什么设置导致了这个问题，因为rt.jar中明明有这些东西。
后来查到可以用这个解决办法：在preference->java->complier->errors/warning->deprecated and restricted API把 Forbidden reference 的Error改成warning 即可（）
虽然到这一步，问题已经解决了，可是我还是不太明白，为什么这class在jar里面但是却访问受限，于是继续在网上查询相关的资料，后来发现了最准确的解释：
J2SE中的类大致可以划分为以下的各个包：java.*，javax.*，org.*，sun.*
除了“sun”包，其它各个包都是Java平台的标准实现，并且今后也将被继续支持。一般说来，“sun”之类的包并不包含在Java平台的标准中，它与操作系统相关，在不同的操作系统（如Solaris，Windows，Linux，Mac等等）中的实现也各不相同，并且可能随着J2SE版本不定期变化。因此，直接调用“sun”包的程序代码并不是100％的Java实现。
也就是说：“java.*”包，“javax.*”包，“org.*”包是作为J2SE的API公开接口的一部分，如果程序直接调用这些包中的API，那么程序是可以运行在所有Java平台上，而与操作系统无关；但“sun.*”包并不是API公开接口的一部分，调用“sun”包的程序并不能确保工作在所有Java平台上，事实上，这样的程序并不能工作在今后的Java平台上。
正因为如此，“sun.*”包中的类并没有提供API文档。平台无关性是Java语言最大的优势之一，此外，SUN和Java许可证确保维持了今后API的向上兼容性（以后修改的那些有严重bug的代码除外）。这种兼容性意味着你写好的程序编译成的cl ass文件仍然可以工作在将来的版本当中。 每家实现Java平台的厂商都可以使用他们自己的方式。“sun.*”包中的类是SUN 对Java平台的实现方式，它们工作在Java 2 SDK的下层，这些类未必被其它Java 平台开发商支持。比如你的Java程序如果调用了一个名为“sun.package.Foo”的类，将有可能产生“ClassNotFoundError”的错误，同时你也将失去利用Java的一个主要的优点。 从技术上讲，并不能防止你的程序调用“sun.*”包中的类。在版本的变迁当中，这些类可能会被删除或转移到其它包路径下，而且它的接口（包括名称、标签等）也很有可能发生变化，（根据SUN的观点，我们应当能够通过对“sun.*”包的修改来提高Java平台的性能。）在这种情况下，即便你希望程序仅仅运行在SUN的实现平台下，你仍将承受新的版本给你的系统带来破坏的风险。总之，编写依赖于“sun.*”包的Java程序是不安全的，他们将变得无法移植，无法被很好地支持。（）
至此，这个问题终于有了圆满的解答，虽然折腾了一晚上，但是毕竟还是有收获的，我把自己的思考过程都记录下来，也希望遇到类似问题的朋友能够少走一些弯路，尽快解决问题，多学习一些东西。