El lenguaje Java cuenta con su compilador llamado javac (Java Compiler), el cual nos permite a partir de un archivo de programa fuente (.java) generar un segundo archivo con código intermedio denominado bytecode (.class)
Este compilador reside o queda instalado normalmente en alguna ruta como por ejemplo:c:\archivos de programa\java\jdk1.6.0_14\bin
(El nombre de la carpeta dependerá de la versión del SDK (Software Development Kit)que se instale, en este ejemplo es la versión 1.6)
Así mismo Java cuenta con su intérprete : java , el cual permite interpretarlos archivos .class o bytecode a código puro entendible por la computadorajusto en el instante (JIT) que se intente realizar la ejecución del programa.
Estos archivos .class normalmente son almacenados en una carpeta diferentea la carpeta de instalación del SDK (mencionada unas líneas arriba) como por ejemplo en la ubicación D:\MISPROGRAMASJAVA
Supongamos que tenemos un programa llamado Ejemplo.java que reside en dicha ubicación y queremos generar un bytecode para luego ser ejecutado
Estando en el indicador del sistama de windows (Inicio - Ejecutar -CMD [ENTER])La forma de compilar el programa Ejemplo.java sería así:
c:\archivos de programa\java\jdk1.6.0_14\bin> JAVAC D:\MISPROGRAMASJAVA\Ejemplo.java [ENTER]
Ahora se ha generado un segundo archivo llamado Ejemplo.class el cual quedo almacenado en D:\MISPROGRAMASJAVA (pues es el lugar de donde se tomo el programa fuente Ejemplo.java)
AHORA VIENE EL USO DE UNA VARIABLE DE ENTORNO : CLASSPATH
Esta es una variable de entorno que se necesita declarar a nivel de sistema operativo (windows, linux, etc) para que java pueda localizar a los archivos .class de forma automática.
Siguiendo nuestro ejemplo tenemos un archivo llamado Ejemplo.class localizado en D:\MISPROGRAMASJAVA
Si a continuación digitamos el siguiente comando desde el indicador del sistema windowsc:\archivos de programa\java\jdk1.6.0_14\bin> JAVA D:\MISPROGRAMASJAVA\Ejemplo [ENTER]
Java podría generar un error como el siguiente:
Exception in thread "main" java.lang.NoClassDefFoundError : D:\MISPROGRAMASJAVA\Ejemplo
Caused by: Java........etc etc etc.
A pesar de que hemos indicado la ruta donde debe ser localizado el archivo .classjava hace caso omiso a dicha indicación.
Solución (con Windows):
Tenemos 2 soluciones posibles
1) Asignar manualmente un valor a la variable de entorno CLASSPATH para que java
busque los archivos .class en una carpeta específica.
(solución que solamente será util mientras no reiniciemos la computadora)
2) Dejar un registro en la computadora en panel de control-Sistema para la variable
CLASSPATH
(solución que es permanente aunque reiniciemos la computadora y es configurable)
En esta ocasión vamos a definir la solución número 1.
Podemos digitar el siguiente comando desde el indicador del sistema:c:\archivos de programa\java\jdk1.6.0_14\bin> SET CLASSPATH=D:\MISPROGRAMASJAVA [ENTER]
(para ver el valor actual de la variable bastaría con digitar set classpath [ENTER])
De ahora en adelante donde quiera que estemos ubicados en el indicador del sistema podremos digitar el siguiente comando para ejecutar nuestros programas (sin definir laruta de forma explícita) :
JAVA Ejemplo [ENTER]
Otra variante para ignorar el contenido de la variable CLASSPATH es digitar el siguiente comando:
c:\archivos de programa\java\jdk1.6.0_14\bin> JAVA -cp D:\MISPROGRAMASJAVA [ESPACIO] Ejemplo [ENTER]
donde -cp indica ClassPath y dice a java que no utilice el valor actual de la variable del sistema, si no más bien la ruta que nosotros le estamos indicando manualmente.
Inténtelo!
Saludos Ing. Alex Jiménez.
miércoles, 19 de agosto de 2009
sábado, 15 de agosto de 2009
Compilación vrs Interpretación
Cuando escribiamos un programa en un lenguaje de programación generamos un archivo conocido como código fuente, para que éste pueda ser entendido y ejecutado por la computadora deberá ser compilado o traducido a código binario (ceros y unos). A esto se le conoce como proceso de compilación.
Mucho se ha dicho en el tema de programación sobre la desventaja que tienen los interpretes frente a los compiladores. Y es que los compiladores tradicionales generaban código binario ,el cuál la computadora puede entender y ejecutar velozmente pues se trata del lenguaje que la computadora entiende de forma nativa.
Este proceso de compilación era necesario realizarlo solamente una vez y luego generabamos un archivo .exe y la computadora no necesitaba nunca mas de un interprete para ejecutarlo pues es un archivo con lenguaje nativo.
Los interpretes tradicionales sin embargo tienen la función de traducir linea por linea de un programa para que pueda ser ejecutado y esto es siempre que el programa quiere ejecutarse, por consiguiente produce un retardo (que hoy en dia es perceptible relativamente a la velocidad del CPU de cada máquina).
El modelo de compilación/interpretación que tienen los lenguajes modernos como los lenguajes .NET (C#, VB, J#) y Java, parece haber retrocedido tomando la idea de combinar un compilador con un intérprete.
Pero cual es la razón? siemplemente hoy en dia se busca que un programa pueda ser ejecutado en cualquier plataforma de sistema operativo (Windows, Linux, Solaris, etc.)
y para ello los compiladores de hoy en día generan lo que es llamado código intermedio (en el caso de Microsoft) o ByteCodes (en el caso de Java), para luego buscar un intérprete adecuado que pueda traducir este código intermedio en código binario justo en el timpo (Just In Time, JIT) que se intenta ejecutar.
Con esto se logra el objetivo de poder distribuir nuestros programas en cualquier sistema opertativo.
Todo en la vida tiene un costo y en este caso, el retardo que se ocasiona por interpretar un código intermedio en lugar de ejecutar directamente un código binario nos provee una ventaja : La independencia del sistema operativo o programas multiplataforma.
Ing. Alex Jiménez.
Mucho se ha dicho en el tema de programación sobre la desventaja que tienen los interpretes frente a los compiladores. Y es que los compiladores tradicionales generaban código binario ,el cuál la computadora puede entender y ejecutar velozmente pues se trata del lenguaje que la computadora entiende de forma nativa.
Este proceso de compilación era necesario realizarlo solamente una vez y luego generabamos un archivo .exe y la computadora no necesitaba nunca mas de un interprete para ejecutarlo pues es un archivo con lenguaje nativo.
Los interpretes tradicionales sin embargo tienen la función de traducir linea por linea de un programa para que pueda ser ejecutado y esto es siempre que el programa quiere ejecutarse, por consiguiente produce un retardo (que hoy en dia es perceptible relativamente a la velocidad del CPU de cada máquina).
El modelo de compilación/interpretación que tienen los lenguajes modernos como los lenguajes .NET (C#, VB, J#) y Java, parece haber retrocedido tomando la idea de combinar un compilador con un intérprete.
Pero cual es la razón? siemplemente hoy en dia se busca que un programa pueda ser ejecutado en cualquier plataforma de sistema operativo (Windows, Linux, Solaris, etc.)
y para ello los compiladores de hoy en día generan lo que es llamado código intermedio (en el caso de Microsoft) o ByteCodes (en el caso de Java), para luego buscar un intérprete adecuado que pueda traducir este código intermedio en código binario justo en el timpo (Just In Time, JIT) que se intenta ejecutar.
Con esto se logra el objetivo de poder distribuir nuestros programas en cualquier sistema opertativo.
Todo en la vida tiene un costo y en este caso, el retardo que se ocasiona por interpretar un código intermedio en lugar de ejecutar directamente un código binario nos provee una ventaja : La independencia del sistema operativo o programas multiplataforma.
Ing. Alex Jiménez.
Suscribirse a:
Comentarios (Atom)