Quiero aprender Java. Al instalar jdk, configuro las variables de entorno del sistema, pero parece que no funciona. Me gustaría pedir a los expertos que respondan esta pregunta.
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
Al mismo tiempo, el instalador JDK copiará tres archivos ejecutables: java.exe, javaw.exe y javareg.exe al servidor WEB. . Al mismo tiempo, el instalador de JDK copia los archivos ejecutables java.exe, javaw.exe y javareg.exe en el directorio winnt\system32. Dado que el sistema operativo establece winnt\system32 como la ruta de búsqueda PATH con la mayor prioridad de forma predeterminada, se garantiza que los usuarios puedan ejecutar java.exe desde cualquier directorio bajo la línea de comando para iniciar la JVM.
El método de inicio de java.exe es el siguiente:
Si hay un archivo.../jre/bin/java.dll, busque.../jre/lib/ jvm.cfg, donde el primer tipo jvm.dll enumerado se usa como tipo predeterminado (si se especifica un tipo jvm.dll en la línea de comando java.exe, se usa el tipo especificado). Si no hay ningún archivo.../jre/lib/jvm.cfg, imprima el mensaje de error que mencionó:
Si no hay.../jre/bin/java.dll (ejecute winnt\ system32\ java.exe), el registro entrará en juego en este momento. La clave HKEY_LOCAL_MACHINE\SOFTWARE\JAVASoft\JAVA Runtime Environment\ CurrentVersion en realidad registra la versión de winnt\system32\java.exe. y número de versión menor, como 1.2, 1.3, etc. La clave CurrentVersion también registra la versión de java.exe en uso en el sistema y la versión de java.exe en uso en el sistema.
Al mismo tiempo, el propio programa java.exe también tiene un valor de versión que se identifica internamente, como 1.2, 1.3, etc. java.exe compara el valor de la versión con el valor CurrentVersion en función de su propio valor de versión interna y, si se encuentra que los dos valores son iguales, se establece en el valor en HKEY_LOCAL_MACHINE\SOFTWARE\\JavaSoft\Java Runtime Environment\ Versión principal. El elemento MicroVersion se utiliza para obtener el directorio donde se encuentran el JRE y las bibliotecas de enlaces dinámicos. Los nombres de estas dos claves son JavaHome y RuntimeLib respectivamente, que representan el número de versión principal y MicroVersion, que representa el número de versión menor. MainVersion representa el número de versión principal y MicroVersion representa el número de versión secundaria.
Si la versión interna de java.exe no coincide con el valor CurrentVersion, se informará el siguiente error:
Valor de la clave de registro "Software\JavaSoft\Java Runtime Environment\CurrentVersion'
p>
el valor es "1,2", pero se espera "1,3".
Esto significa que la versión de winnt\system32\java.exe registrada actualmente en el registro es 1.2, pero la versión de java.exe que se ejecuta en este momento es 1.3. java.exe se queja de que no puede localizar correctamente java.exe por sí solo a menos que la versión 1.3 esté registrada en el registro.
Aquí, no podemos simplemente modificar el valor CurrentVersion del registro para lograr este objetivo. En términos generales, cuando se instalan dos versiones del SDK de Java2 en el sistema (por ejemplo, primero se instala la 1.2 y luego la 1.3), el SDK de Java2 instalado posteriormente copiará su propio java.exe y javaw.exe en winnt \system32. directorio, sobrescribiendo así las versiones anteriores de java.exe y javaw.exe y sobrescribiendo el valor CurrentVersion en el registro. Se recomienda desinstalar las versiones anteriores del SDK de Java2 antes de realizar la instalación, ya que sobrescribirá las versiones anteriores de java.exe y javaw.exe y reescribirá la versión actual en el registro a 1.3. Si cambia artificialmente CurrentVersion, hará que una versión diferente de java.exe cargue java.dll y jvm.dll que no coinciden con la suya, lo que provocará consecuencias impredecibles.
Caso especial:
JBuilder viene con un conjunto de JDK Una vez completada la instalación de JBuilder, el programa de instalación de JBuilder cambiará CurrentVersion a su propia versión de JDK, pero lo hará. No sobrescriba winnt\system32 java.exe y javaw.exe en .
WebLogic viene con un conjunto de JDK. Una vez completada la instalación de WebLogic, el programa de instalación de WebLogic no modificará el registro ni sobrescribirá java.exe y javaw.exe en winnt\system32.
Oracle viene con un conjunto de JDK (generalmente una versión relativamente baja, por ejemplo, 8.1.7 solo viene con JDK 1.1.7. Una vez completada la instalación de Oracle, el programa de instalación de Oracle no se modificará). el registro ni cubrirá java.exe y javaw.exe en winnt\system32. Sin embargo, el instalador de Oralce modifica la variable PATH del sistema para agregar la ruta bin del JRE a la variable PATH del sistema y la coloca en la parte superior de la lista. Con diferentes versiones de instalación de Oracle, el iniciador JRE JVM que viene con él también es diferente. En Oracle 8.1.7 instalado en la máquina del autor, el JRE se instala en C:\Program Files\Oracle, y el programa de inicio de JVM colocado al frente de la variable PATH es jre.exe, no java.exe. exe.
Lo anterior es el programa de inicio de JVM, es el programa de inicio de JVM. p>
Lo anterior es la operación cuando Java2 SDK está instalado en Windows, lo que puede causar problemas de compatibilidad:
Antecedentes del problema: después de instalar Java2 SDK, no cambie ninguna variable PATH Instalar JBuilder6
Pregunta 1
Después de instalar JDK 1.2 en el sistema operativo, instale JBuilder6 (JBuilder6 incluido con JDK 1.3.1).
1), CurrentVersion es 1.3. Al ejecutar java -version en la línea de comando, aparecerá:
Valor de clave de registro "Software\JavaSoft\Java Runtime Environment\ CurrentVersion"
El El valor es "1.3", pero se requiere "1.2": agregue la ruta a java.exe en JDK 1.2 en la parte superior de la RUTA del sistema operativo para garantizar que la ruta a java.exe siempre se ejecute cuando se llama a Java en el comando. línea.
Solución alternativa: agregue la ruta a java.exe en JDK 1.2 en la parte superior de la RUTA del sistema operativo para garantizar que la ruta a java.exe siempre se ejecute al llamar a java en la línea de comando, de modo que java .exe Capacidad para localizar correctamente JRE y jvm.dll. Cuando se instala 3.0 en el sistema operativo y JBuilder6 (viene con JDK 1.3.1), la versión actual es 1.3, pero 1.3 es la ruta al JDK 1.3.1 que viene con JBuilder6, y JDK 1.3.1 es el JDK 1.3. que viene con JBuilder6 1 ruta. JBuilder6 viene con JDK 1.3.1 JRE, en lugar de apuntar al JDK 1.3.0 JRE anterior. Cuando se ejecuta la versión java en la línea de comando, el JDK 1.3.0 ejecutado en este momento se copia a la copia de java.exe. en winnt\system32, pero la información de la versión impresa es:
versión java "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (compilación 1.3.1-b24 )
Java HotSpot(TM) Client VM (compilación 1.3.1-b24, modo mixto)
El problema se debe a que java.exe solo retiene un número de versión decimal en lugar de dos dígitos.
Solución: Igual que el problema 1
Problema 3:
Si primero se instala JDK 1.3.0 en el sistema operativo y luego se instala la versión principal de JDK y La versión menor es la misma para JBuilder6 (en el caso de JDK 1.3.1, los dos primeros dígitos son JDK 1.3.2-b24, y en el caso de JBuilder6, los dos primeros dígitos son JDK 1.3.2-b24. 1, los dos primeros bits son iguales), el problema 1 en realidad está oculto y es imposible que suceda y el problema 2 también está muy oculto y no es fácil de encontrar;
Como se mencionó en la pregunta 2, al ejecutar Java en la línea de comando, se usa una copia de java.exe de JDK 1.3.0 (ubicado en el directorio winnt\system32), pero en realidad se usa JDK 1.3. 1 JRE y su estructura de directorios. Por lo tanto, cuando usamos el mecanismo de extensión de Java2 para colocar el archivo jar en el directorio jre\lib\ext de JDK 1.3.0, encontraremos que se crea una nueva versión de JDK 1.3.1 en JDK 1.3.0. jre\lib\ext, descubrimos que no se podía lograr el efecto esperado: cuando iniciamos el programa con java en la línea de comando, no buscaba automáticamente archivos jar en el directorio jre\lib\ext de JDK 1.3. 0.
Solo irá automáticamente al directorio jre\lib\ext de JDK 1.3.1 en JBuilder6 para buscar archivos jar. Sin embargo, no existe un directorio como jre\lib\ext en JDK 1.3.1 en JBuilder6.
El problema 3 es muy sutil y, a menos que comprenda completamente el mecanismo de instalación y localización de clases del SDK de Java2, será difícil para los desarrolladores comunes descubrir el problema. Para obtener más información sobre el mecanismo de localización de clases en Java2, consulte el artículo "Mecanismo de localización de clases en Java2".
De hecho, incluso si solo hay una copia de JDK 1.3.0 en el sistema, si ejecutamos java desde la línea de comandos, el directorio JRE utilizado es C:\Program Files\JavaSoft\JRE\ 1.3, lo que significa que incluso si colocamos el frasco de extensión, no se obtendrá el resultado esperado. La forma correcta es colocarlo en el directorio C:\Program Files\JavaSoft\JRE\1.3\lib\ext.
Solución: Igual que la pregunta 1
En resumen, se recomienda encarecidamente colocar el directorio %JDK_HOME%\bin en la parte superior de la variable PATH del sistema operativo Windows para evitar posibles problemas. .
En UNIX, no habrá problemas similares al sistema operativo Windows.
El java que ejecutamos bajo el comando es /bin/java
$cuál java
$/bin/java
y / bin es un enlace a /usr/bin, lo que significa que /bin/java es en realidad /usr/bin/java
y /usr/bin/java en realidad apunta a /usr/java/bin /java , y /usr/java es un enlace a /usr/java1. 2 (JDK 1.2 está integrado en Solaris 7 o posterior), por lo que el java que realmente ejecutamos es /usr/java1.2/bin/java.
Dependiendo de UNIX, Java siempre puede usar ./jre/lib/sparc/libjava.so y .../jre/lib/sparc/libjvm.so para encontrar estos dos archivos en tiempo de ejecución, el primero es similar a java.dll en Windows, y este último es similar a jvm.dll en Windows, por lo que Java siempre puede determinar el directorio de su propio JRE.
Las bibliotecas de enlaces dinámicos utilizadas en Windows y UNIX en realidad se denominan binarios de código nativo de paquetes opcionales en la documentación de Sun. Los paquetes opcionales son en realidad clases de mecanismo de extensión. Consulte la sección "Localizador de clases de Java 2" en. . Mecanismo de posicionamiento de clases en Java2.
Una forma de cambiar la versión de Java en UNIX es cambiar el enlace /usr/java, como se describe en Instalación del JDK en UNIX.
Agregado: (2002-12-23)
Cómo Windows localiza los complementos
Localice según el número de versión de java.exe que se encuentra en PATH. exe, vaya a HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in para encontrar la versión correspondiente del complemento Java en HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in. Puede haber varias versiones del complemento en HKEY_LOCAL_MACHINE\. SOFTWARE\JavaSoft\Complemento Java.
No confíe en el valor CurrentVersion de HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit ni en el valor CurrentVersion de HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment para localizar qué versión del complemento Java debe ser usado.