求解答 为什么装置不了JAVAsetup8u241 每次都报这个失误 (求问为什么)

本文目录导航：

• 为什么装置不了JAVAsetup8u241，每次都报这个失误，求解答。
• java无法加载插件，揭示无法加载java(TM)platform SE 8 U25是怎样回事？如图。求处置，高报答。有追加。
• java中classpath的值是多少？

为什么装置不了JAVAsetup8u241，每次都报这个失误，求解答。

1、请确认你没有删除Windows Installer。

删掉的话人造要从新装置2、请确认Windows Installer服务没有被禁用。

到控制面板->治理工具->服务中检查Windows Installer，确认设置不为禁用（智能手动都可以，自动设置应该为手动）。

3、请确认你没有删除C:\WINDOWS\Installer文件夹，假设此文件夹被删除，会造成一系列不确定的失误，其中就有或许如你所形容的失误。

由于这个文件夹关涉很多软件的装置消息，详细处置方法不详。

假设你有数据复原软件并且删除期间不久可以尝试复原，否则卸载掉Windows Installer后再从新装置有或许处置。

java无法加载插件，揭示无法加载java(TM)platform SE 8 U25是怎样回事？如图。求处置，高报答。有追加。

楼主，这个是java 的 applet 小程序，应该是不被阅读器允许了。

可以尝试在控制页面的java设置外面，从新开启允许。

java中classpath的值是多少？

检查文章 JAVA中classPath片面解析 2009年08月22日 14:15 # 摘要 Class Path是Java口头期间环境用来搜索类别与其它资源所用之门路。

Class Search Path（理论经常使用Class Path这个缩写称号比拟为人所知）可以在呼叫SDK工具程式时经常使用-classpath或许是设定CLASSPATH环境变数。

倡导是经常使用-classpath选项，由于您可以独立的为每一个运行程式设定，而不会影响其它的运行程式，且不会有其它的运行程式来扭转这个值。

1 C:> sdkTool -classpath classpath1;classpath2...-或- 1 C:> set CLASSPATH=classpath1;classpath2...在这边： sdkTool：是一个命令列工具程式，像是java、javac 或 javadoc. classpath1;classpath2：指向、或 档案的Class Path，每一个classpath都应以档名或目录称号（这与您所要设定的classpath无关）作完结。

* 对於一个包含的或档案而言，class path要以或档案的称号作完结。

* 对於一个未命名的package而言，class path要以包含一切档案的目录作完结。

* 对於一个已命名的package而言，class path要以包含根package（完整package称号的第一个package）的目录称号作完结。

多个门路名目要以 分号 作区隔，经常使用set指令，关键的是等号两头无法有空白。

预设的class path是目前的目录，设定CLASSPATH变数或经常使用-classpath命令列选项时会笼罩这个预设，所以假设您要在目前的搜索门路中包含目前的目录，您必定在新设定中包含. 。

即不是目录也不是文件档案（或）的classpath会被疏忽。

# 说明 class path通知SDK工具程式与运行程式要到哪边寻觅第三元件（third-party）与经常使用者定义的classes，也就是它们非Java加长套件或非Java平台的一部份。

在您经常使用javac编译器编译类别时，须要经常使用class path来找出任何所需的套件 -- 预设是目前的目录，以繁难找到这些类别。

Java2 SDK、JVM与其它的SDK工具藉由搜索Java平台、classes、其它加长classes与class path来找到所需的classes，以这个顺序（要瞭解搜索战略的细节，请看如何寻觅Classes, How Classes Are Found），大部份运行程式所用的类别库就可以应用加长套件机制（extensions mechanism），在您载入一个不在目前目录的类别或它的其它子目录且它们不在伸加长套件机制中时，您所要作的就是设定class path。

假设您从旧版本的SDK更新过去，在您的进行设定中或许包含曾经不再经常使用的CLASSPATH设定，您必定将这些非特定运行程式的设定移除，像是，一些经常使用到Java虚构机器的第三元件运行程式或许会更改您的CLASSPATH环境变数，以将它们所经常使用的程式库包含出来，这些设定则可以保管。

在您要求JVM或其它SDK工具程式时，您可以在经常使用Java工具程式时藉由-classpath选项来扭转class path，或是经常使用CLASSPATH环境变数来指定。

倡导是经常使用-classpath选项会比设定CLASSPATH环境变数来得好，由于您可以为每一个运行程式区分设定，而不会影响其它的应 用程式，而其它运行程式也不会扭转这个值。

Classes可以被贮存在目录（资料夹）或是在文件档案（archive files），Java平台的classes是被贮存在，要瞭解文件档案的细节或是class path如何运作的新闻，请看看稍後小节的 瞭解class path与package称号。

关键、留意：一些旧版本的JDK软体在预设的class path中包含了<jdk-dir>/classes名目，这些目录的存在是为了被JDK软体经常使用，而不应被运行程式classes经常使用。

运行程式类别应该被放在JDK目录结构之外的其它目录，用这种模式，新的JDK就不会强制您从新装置运行程式classes，为了要与旧版本相容，必定经常使用<jdk-dir>/classes目录作为类别库的的运行程式，在目前的版本也可以运作，但不保障在未来的版本中仍可以运作。

# 经常使用SDK工具程式的-classpath选项 SDK工具程式 java、jdb、javac与javah领有一个-classpath名目，当口头工具程式时，它用於取代由CLASSPATH环境变数所设定的门路，在扭转class path设定时，这是个倡导经常使用的选项，由于每一个运行程式可以领有自已所需的class path，而不会与其它运行程式相互搅扰。

口头期间工具程式java也有一个 -cp 选项，这个选项是-classpath的缩写称号。

对於一些相当不凡的例子来说，java与javac都领有一些名目可以让您扭转它们用来找到专属类别库的门路，但是绝大少数的经常使用者从未须要经常使用这些名目。

# 经常使用CLASSPATH环境变数 普通而言，倡导您经常使用-classpath命令列选项，就似乎上方所提过的，这个小节将告让您如何设定CLASSPATH环境变数，假设您想这麼作的话，或许是想肃清之前装置所留下的设定。

设定 CLASSPATH： CLASSPATH环境变数可以藉由set指令来修正，格局是： 1 set CLASSPATH=path1;path2 ....门路应该以磁碟机代号开局，例如C:\，用这种模式，即使您切换至另一个磁碟机也可以找获取classes。

（举个例子来说，假设门路名目以斜线开局而您在磁碟机D:，那麼classes将会预期是在D:，而不是C:） 肃清 CLASSPATH： 假设您的CLASSPATH环境变数曾经被设定为某个值，但是并不正确，或许是您的进行档案或是命令稿被设定了失误的门路，您可以藉由以上去敞开CLASSPATH的设定： 1 C:> set CLASSPATH=这个指令只敞开目前的命令列揭示视窗CLASSPATH设定，您应当删除或修正您的进行设定，以保障您在下一次性操作也会有正确的CLASSPATH设定。

扭转进行设定： 假设CLASSPATH被设定於系统进行时，设定的中央则视您所经常使用的作业系统而定： 作业系统方法： *Windows 95与98 审核中的set指令 *其它（Windows NT、Windows 2000、....）经常使用控制台中的系统工具来设定CLASSPATH变数 # 瞭解class path与package称号 Java的classes被组织为packages，它们对应於档案系统的目录结构，但是不像档案系统，每当您指定一个package称号时，您指定整个package称号而不是部份称号，例如，的package称号是经常使用来指定。

例如，假定您要Java口头环境找到一个在 package称号 中名叫的class，假设该目录的门路是C:\java\MyClasses\utility\myapp，您要设定class path以包含 C:\java\MyClasses。

要口头这个运行程式，您可以经常使用上方的JVM指令： 1 c:> java -classpath C:\java\MyClasses 当运行程式口头时，JVM会经常使用class path设定来找就任一其它被定义於 package（它被Cool类别经常使用）中的类别。

留意在指令中被指定的整个package称号，这是无法能的，例如，设定class path包含C:\java\MyClasses\utility并经常使用指令java ，这麼作并不会找到class。

（您或许会想是什麼定义了一个class的package称号，答案是package称号是class的一部份，而且无法被修正，除非从新编译） 留意：一个package指定机制的幽默的结果是，同一个package中的部份档案可以存在於不同的目录，对於每一个class而言，package称号将会相反，但是每一个档案的门路将会以class path中不同的目录开局。

目录与文件档案（archive files）： 当classes被贮存在目录（资料夹），像是c:\java\MyClasses\utility\myapp，那麼class path名目指向包含package称号第一个元素的目录（在这个例子中是c:\java\MyClasses，由于package称号是） 但是当classes被贮存在文件档案时（或档案），class path名目就是指向且包含或的档案，例如，经常使用在档案中的类别库，指令会像是： 1 C:> java -classpath C:\java\MyClasses\ 多个指定： 要寻觅C:\java\MyClasses中与C:\java\OtherClasses中的classes，您可以这麼设定class path： 1 C:> java -classpath C:\java\MyClasses;C:\java\OtherClasses ...留意两个门路是以分号作区隔。

指定顺序： 指定多个class path名目标顺序很关键，Java解码器（interpreter）会以class path变数 中的顺序来於目录中寻觅classes，在上方的例子中，Java解码器首先会在目录C:\java\MyClasses中寻觅所需的类别，只要在它於该目录中找不到适当称号的类别时，解码器才会於C:\java\OtherClasses目录中寻觅。

///////////话说回来, 咱们有没有方法, 将一些罕用的 jar file 放到一个目录中 ex: commons-lib\ 透过一个程式来智能 import commons-lib 之下的一切 jar 相似 tomcat 咱们只需放到 lib 中, 程式会智能 import . 就可以 import and compile 了 ^^~ 我想这是可行的. 但是理想中, 咱们还要去判别重复的 class 该如何去设定. 看来, 要去 trace tomcat sourcecode 并且修正 ^^~ //////////////有一个参数-extdirs可以下, 我看它的说明 很像是下了这个就可以做到智能import指定目录下的jar档吧 不过没有 ///////////LoadClass LoadLibrary so many so on. JDK allows compile at runtime. /////////////dear biology 我要的不是 LoadLibrary , 你这样还是须要指定你要哪个 library 应该是说, 我想要的是只需将相关的 jar file 放到一个指定的目录. 可以少去 complie 及 run 时刻不须要设定 CLASSPATH. ////////////////////刚刚测试了一下 ClassLoader 他可以把咱们想要的 档所有载入 jvm 但是有个小疑问. 那就是 (String) 这一个不必定会找到咱们要的 class.... 须要应用 (className, initialize, classloader). 但是须要先指定 classloader... 这个是个疑问.... 要素是 (string) 会取代成 (string, true, )... 假设那个 classloader 自身(还有 parent classloader)没有 这特定 library 存在, 那就无法抓到指定的 class.... 所以总归 还是一次性参与 CLASSPATH 比拟好... 或则只好托付人深化钻研了... [理想你可以应用 ClassLoader 半智能到达你要的物品....] /////////局部我测试用的 code: 宿愿多少有协助... u[]=new [1]; u[0]=new ( cl=(u,()); ()(); //. //purpose? //this will be failed: () Object obj=(,true,cl)(); //Object obj=()(); m=()(aaa,null); (obj, null); //////////////////你们不会不知道吧？！ JRE/lib/ext 就是这个用途啊，让你放 third-party 的 library，JRE 进行时会把智能载入外头的 jar(应该说 classloader 须要 resolve class 时会到这个目录上去找)。

关键的疑问是，装置 JDK 时普通人或许会装两个 JRE，一在 JDK 装置目录下的 JRE 目录，一在(预设) Program files 目录下的 Java 目录。

经常使用的是JDK 所附的 private JRE(JDK/JRE)，而口头 Java 程式则要看你的 path 定。

JDK\bin\, JDK\jre\bin\ 经常使用的是 private JRE，program files\java\jre1.x.x\bin\, WinNT(Windows)\system32\ 经常使用的是public JRE。

同上。

比拟保险的做法是把 third-party library jar file 在 private JRE/public JRE 各放一份，这样可确保编译时可以 resolve third-party classes，或是设定 path 使得优先经常使用 private JRE(或乾脆就移除掉 public JRE)。

Eclipse 比拟特意，你可以只把 third-party 放在 public JRE 就好，不须要放在private JRE 也可以在编译时让编译器去参考到所须要的 class。

///////////////////没错, 这就是我宿愿的配置, 摆在那边 install 没疑问, 但是 uninstall 就会有疑问了, 由于或许会有重复经常使用到的 jar files. 所以我宿愿能够指定一个目录 当我是个 application setup 实现之後, 目前的做法是在 中设定相关的 CLASSPATH 此外, 对於一个 java 新手, 我也宿愿提供一个繁难的方法治理及部署 jar files. 防止 CLASSPATH 设定的疑问. 繁难来说, 就是口头某个程式可以自在地参与目录相当 %JAVA_HOME%/lib/ext 接著我开发我的程式或口头我的程式, 而且透过那个程式可以做一些 jar files 的治理 例如说, 优先顺序, 重复剔除 等等的配置 ^^~ ///////////////我想jini兄跟Biologic兄应该都知道的... 但是我臆测或许他们以为放在JRE/lib/ext不是很失当的方法 第一个疑问就是未来经常使用者要自己把经常使用的classpath放在/jre/lib/ext 会形成经常使用者的困扰 二来 或许会有一些版本的抵触... 以前就有出现这个例子 就是抓了很多xml parser.. 而每个外面又包了JAXP 结果有的包旧的有的包新的.. 失误就这样发生了... 普通来讲还是在口头的时刻给classpath才是好方法 至於太多lib的话 我团体还是不青睐程式外面用ClassLoader去抓... 我宁愿提供批次档给他口头 或是提供.. ant题供**/*的写法 ////////////////赞同 popcorny 的认识, 放在 JRE/lib/ext 下可行, 但层级太高, 尤其假设是在 web app(tomcat) 或 J2EE 的环境底下, 必定思考 class loading 先後顺序的疑问 (似乎在spec中有定义.) 所以应该不会有任何一个java applicaion installation guide 要你把哪个 jar 放在 JRE/lib/ext 中 (但这似乎不属於新手区的探讨 ...) ///////////////////////假设说是同一套 library 不同版本的抵触疑问，最基本(或许也是最好的)解法是，替每一个 application 提供一个批次档，指定公用的 classpath。

或是写个 classloader 会依照 application 的属性(xml file)，到特定的目录去找 jar，但是这没有方法套用在其余厂商提供的运行程式上。

一个比拟可行的方法是，写一个 application launcher，领有治理 jar library 及每个运行程式所倚赖的 library 的对应相关，然後要求经常使用者在口头任何 Javaapplication 时，都得透过 app launcher(app launcher 会进行特定的 classloader 来载入 app 所须要的 jar)来进行(这很容易)。

//////////////////////////很多 ext package 都是要求自己设定 classpath，批示把 ext-package jar 放进Jre/lib/ext 也是有：Java Communications API。

/////////////////////很多 ext package 都是要求自己设定 classpath ...这样比拟好. 批示把 ext-package jar 放进 Jre/lib/ext 也是有 是 java extention, 团体以为比拟不像 application, 既然是 Java 的一部份, 倡导间接放 jre/lib/ext 下也无可非议, 但版本的疑问或许会是 nightmare. 团体以为还是用 application specific classpath 好. Application 把 jar 间接往 jre/lib/ext 放, 不是无法以, 而是*不应该*. 假设在 jre/lib/ext 下有一个 , 在classpath中有一个 , 在 WEB-INF/lib 下也有一个 ,哪一个会先被用呢? jini 兄提到的 uninstall 亦是个疑问. 对新手来说, 倡导把一切的 jar 往 jre/lib/ext 放或许繁难些, but may not be a good practice.