¿Qué es Java?
miércoles, junio 7, 2006 at 2:00AM El
artículo original ha sido publicado en: ONJava.com
(http://www.onjava.com/)
http://www.onjava.com/pub/a/onjava/2006/03/08/what-is-java.html
¿Qué es Java?
por Chris Adamson
03/08/2006
- Java
"Java" normalmente se refiere a la combinación de
tres cosas: el lenguaje de programación Java (un lenguaje de
programación orientado a objetos y de alto nivel); la máquina
virtual de Java (una máquina virtual de alto rendimiento que
ejecuta el bytecode en una plataforma de ordenador específica;
normalmente abreviada JVM); y la plataforma Java, una JVM
que ejecuta el bytecode compilado de Java, normalmente llamando a un
conjunto de librerías estándar como las proporcionadas
por Java Standard Edition (SE) o Enterprise Edition (EE). Aunque
están unidos a propósito, el lenguaje no implica la
JVM, ni viceversa.
En este artículo
Recientemente recibimos un email preguntando por la entrada "Qué
es Java" en la red de sitios what
is de O'Reilly. ¿Quién podría no saber qué
es Java en el año 2006? Después de diez años de
libros, páginas web y conferencias, ¿no todo el mundo
conoce qué es Java? Parece que no.
Después de todo, las cosas han cambiado.
Para cada una de las definiciones anticuadas que hablaban de los
applets y de los compiladores Just-In-Time (en tiempo de ejecución),
se han impuesto nuevas direcciones y verdades, aceptadas por muchos,
que aún no están completamente documentadas. Java solía
significar:
Applets
Interpretación del Bytecode
Bajo rendimiento
Una cultura de esperar por novedades de Sun
Hoy en día significa:
Aplicaciones web, servicios web,
SOAs, etc.Compilación dinámica
de los trozos de código en los que se emplea más
tiempo de ejecuciónAlto rendimiento
Una comunidad de código abierto cada vez más
independiente de Sun
El viejo eslogan "Escribe una vez, ejecuta en cualquier
sitio" aún es verdad--pero lo que se escribe y el sitio y
la manera en que se ejecuta están cambiando.
El lenguaje de programación Java
Java (el lenguaje) es un lenguaje de programación de alto
nivel orientado a objetos, que está influenciado de varias
maneras por C, C++ y Smalltalk, y también por ideas que ha
tomado prestadas de otros lenguajes (mira La
historia de los lenguajes de programación de O'Reilly). Su
sintaxis fue diseñada para ser familiar a aquellos que estaban
familiarizados con los lenguajes que descienden más
directamente de C, pero tiene los principios de la orientación
a objetos más asumidos que C++, objetos fuertemente tipados y
un sistema más justo e inflexible de excepciones que requiere
que cada método que se llama trate cualquier tipo de excepción
o especifique que puede lanzarlas. La recogida de basura es
automática, de esta manera se evita al programador tener que
liberar la memoria usada por los objetos que ya no se van a emplear.
Uno de los aspectos más polémicos de Java
--generalmente aceptado cuando se liberó pero que cada vez es
más criticado-- es que no es completamente orientado a
objetos. Específicamente, los tipos primitivos de Java comoint, char, boolean, etc. no
son objetos, y requieren un trato totalmente diferente por parte del
programador: como int no es una clase, no puedes hacer
una subclase y declarar nuevos métodos en ella, no puedes
pasarla a un método que espera un tipo Object
genérico, etc. Los tipos primitivos incrementan el rendimiento
de Java, pero con la discutible reducción de la claridad del
código, como todos los que han tenido que trabajar con las
llamadas “clases envoltorio” (Integer,Character, y Boolean) habrán
comprobado. Java 5.0 introduce una conversión automática
para utilizar menos las clases envoltorio, pero eso oculta de alguna
manera lo que realmente está pasando.
Filosóficamente, Java es un lenguaje "fácil de
aprender". Porque por sus restricciones sintácticas,
muchos fallos de programación son simplemente imposibles en
Java. Como no tiene acceso directo a los punteros, los errores de
aritmética en punteros no existen. Usar un objeto de otro tipo
que el que se exige requiere una conversión explicita, que le
da al compilador la oportunidad de rechazar las cosas que no sean
lógicas, como llamar a un método String en
una Image.
Muchos de los framework empresariales requieren que se use
archivos de configuración o descriptores de despliegue,
normalmente escritos en XML, para especificar la funcionalidad: que
clase trata cierto tipo de respuesta HTTP, el orden de los pasos para
ejecutar un motor de reglas, etc. En efecto, van más allá
del lenguaje para utilizar sus capacidades. Los críticos
señalan que esto tiene un efecto muy negativo, no sólo
se escapa a las comprobaciones del compilador de Java , sino que
además el programador no puede saber cómo actuará
un programa mirando sólo el código fuente. En Java 5.0
se añade anotaciones
al lenguaje, lo que permite etiquetar los métodos, campos y
clases con valores que pueden ser inspeccionados y utilizados en
tiempo de ejecución, normalmente usando reflection. A muchos
programadores les gusta anotaciones porque simplifica la tarea que de
otra manera estaría controlada por descriptores de despliegue
o por otros medios. Pero otra vez, pueden hacer que el código
sea difícil de entender, porque la presencia o ausencia de una
anotación puede afectar a como se ejecuta el código, de
maneras que no son obvias para la anotación.
A pesar de estas críticas, Java generalmente se ve como el
lenguaje de programación de propósito general más
popular que se usa hoy en día. Es un estándar
extensamente usado en la programación empresarial, y en 2005,
reemplazó a C++ como el lenguaje más usado en los
proyectos de SourceForge.
Las ventajas que esto ha aportado a Java son inmensas: herramientas
libres (en varias plataformas: Linux, Windows, Solaris, y Mac se
pueden ejecutar programas hechos en Java), una inmensa base de
conocimiento, y una gran cantidad de programadores disponibles de
buena gana.
El lenguaje Java ofrece una visión específica de la
pugna entre la productividad del programador y el rendimiento del
código: los ciclos de CPU cada vez son más baratos,
pero no para los desarrolladores, por eso quizás es inevitable
aceptar otro nivel de abstracción entre el programador y la
ejecución de opcodes de la CPU, que permitiría al
programador crear programas mejores y más rápido. De
hecho, los que critican la productividad de Java, como Bruce Tate en
Beyond
Java, sólo tendrían que observar esta
tendencia que continua y que lleva a Java a un punto nuevo y dulce
donde se sacrifica el rendimiento en favor de la productividad del
desarrollador.
La plataforma Java
Java se suele ver en lo que respecta a las tres plataformas como:
Standard Edition (SE), Enterprise Edition (EE), y Micro Edition (ME).
Cada una describe la combinación de una versión del
lenguaje, un conjunto de librerías estándar, y la
máquina virtual(mira más bajo) para ejecutar el código.
EE es una ampliación de SE—cualquier programa EE puede
asumir que existen las librerías de SE--y el uso del lenguaje
en EE es idéntico que en SE.
A causa de las limitaciones de los aparatos pequeños como
teléfonos o cajas set-top, Java Micro Edition difiere
significativamente de sus “hermanos”. No es un
subconjunto de SE(como SE lo es de EE), porque algunas de sus
librerías existen sólo en Micro Edition. Además,
ME elimina algunas características del lenguaje, como
el tipo primitivo float
y la clase Float,
reflejando las limitaciones de las plataformas en las que se ejecuta.
Necesita herramientas diferentes a SE y EE, y como las grandes
diferencias en los aparatos hacen que la verdadera portabilidad del
código este un poco más lejana en el espacio micro,
muchos programadores de Java ven ME como un completo desconocido.
La máquina virtual de Java
En algún punto, el código Java ha de convertirse en
código nativo ejecutable en la plataforma. Esto requiere
normalmente dos pasos: el programador compila su código a Java
bytecode, y después la máquina virtual de Java (JVM) lo
convierte a código nativo para la plataforma host. Este ultimo
paso está optimizado para ser interpretado—cogiendo cada
instrucción de la JVM y convirtiéndola al momento en
una o más instrucciones nativas. Después, los
compiladores just-in-time (JIT) convertían el bytecode en
código nativo cuando el programa empezaba su ejecución.
Actualmente, hay diferentes enfoques. El compilador
HotSpot de Sun empieza interpretando y perfilando el código
en tiempo de ejecución, compilando y ejecutando las partes más
críticas para el funcionamiento del programa. El "interprete
de modo mixto" de IBM's
JVMs funciona de forma similar. Estos enfoques evitan la
optimización inicial supuestamente hecha de golpe por los
compiladores JIT para todo el programa, lo que significa que la
mejora en el rendimiento llega después de un tiempo, cuando
las secciones de código críticas son localizadas y
optimizadas. Los procesos que se ejecutan durante bastante tiempo en
los servidores se benefician de este enfoque, aunque las programas de
los clientes no tanto.
Como es el caso de los tipos primitivos, el ciclo de compilación
de dos pasos de Java empieza a parecerse a una optimización
prematura de algunos tipos críticos. Si estas dispuesto a
esperar para compilar el Java Bytecode a código nativo, se
preguntaron, ¿porque no librar al programador de un paso
interpretando el código Java en vez del Java Bytecode? Como
Tate señala en Beyond Java, "Java no es el
lenguaje más simple. Ni le gusta hacer iteraciones cortas ...
Otros lenguajes te permiten moverte de un cambio al otro sin el
engorroso ciclo de compilar/utilizar."
La JVM sin Java
De hecho, uno de los criterios clave de Tate a la hora de
encontrar sucesores en potencia al éxito de Java es la idea
que "el próximo lenguaje comercial de éxito
debería tener una versión que se pudiese ejecutar en la
JVM. Eso debería ayudar al lenguaje a superar muchos
obstáculos, tanto políticos como técnicos."
Él señala que el enfoque de la VM te proporciona
seguridad ("sí puedes hacer que la VM sea segura, es mas
fácil hacer que el lenguaje sea seguro"), portabilidad,
interoperabilidad, y extensibilidad. Como la JVM resuelve de manera
efectiva esos problemas, un lenguaje nuevo no necesitaría su
propia VM ja que se podría ejecutar en la JVM que ja está
en millones de ordenadores.
De muchas maneras, esto ya está pasando. Escribiendo
interpretes en Java para esos lenguajes se consigue que esos
lenguajes se ejecuten en la JVM, como Rhino
para JavaScript, Jython para
Python, o JRuby para
Ruby.
Pero también es posible evitar completamente el lenguaje
Java e ir directamente al nivel de la JVM. Ya hay compiladores de
bytecode C-to-JVM, como el Axiomatic
Multi-Platform C, que proporciona un subconjunto ANSI C. Además,
el incremento en la manipulación del bytecode de Java con
herramientas como ASM y
Apache BCEL permite a
los programas Java crear clases ejecutables en tiempo de ejecución.
Esto ya no es Java, pero es una forma de lenguaje de programación
de ensamblaje para la JVM.
Posiblemente teniendo en cuenta el deseo de ejecutar código
que no sea de Java en la JVM, un nuevo JSR, "Soporte dinámico
de lenguajes tipados en la plataforma JavaTM" (JSR
292), ha sido recientemente introducido, especificando un nuevo
bytecode que podría hacer que la JVM fuese más
apropiada para ejecutar lenguajes sin tipos de información
estáticos.
Java sin la JVM
También puedes mirarlo al revés, y ejecutar Java sin
la JVM. Después de todo, en algún punto, el código
Java se convierte en bytecode, que se transforma a código
nativo—y nadie dice que no puedas hacerlo en un solo paso. El
GNU Compiler for Java (GCJ)
permite compilar de una sola vez el código Java en un
ejecutable para una única plataforma. Aunque incompleto—no
tiene soporte para Abstract Windowing Toolkit (AWT), haciendo que no
sea apto para la programación de GUI's con AWT o Swing—es
suficiente para compilar programas del lado del servidor y programas
que funcionan en la consola.
Este proceso tiene una desventaja obvia: transformar el código
en un paso lo vincula para una única plataforma. Además,
la compilación estática no es un triunfo automático
sobre la compilación dinámica HotSpot—el autor
alguna vez ha trabajado en un proyecto en el que el rendimiento que
se gana con GCJ fue inferior al cinco por ciento por encima de la
versión HotSpot. Aún así, GCJ puede resolver
problemas importantes, como ejecutar una aplicación de Java
sin preocuparte si una JVM está disponible o se está
ejecutando una versión específica de la JVM.
El Java Community Process
Aparte del lenguaje, librerías, y VM, está la
comunidad Java. A pesar de la masiva cantidad de programas de código
abierto escritos en Java, sigue habiendo una fricción abierta
y obvia entre la comunidad Java y la comunidad open source. En gran
parte, esto puede ser provocado por la negación de Sun a
liberar su implementación de Java bajo una licencia de código
abierto apropiada, aunque su código está disponible
bajo una variedad de licencias especificadas por Sun.
Algunos dicen que este conflicto está totalmente
desencaminado. El programador Bruno Souza, hablando en un episodio
reciente del podcast de O'Reilly Distributing
the Future, dijo que ese argumento en contra de Sun malinterpreta
la naturaleza de Java, ya que el lenguaje, las librerías, y la
VM son estándares establecidos en gran parte por un proceso
abierto y transparente del Java
Community Process:
Todos los estándares de Java que hay ahí se
pueden utilizar como código abierto. Esta distinción
entre si el estándar de Java lo dirige o no una organización
fuera de Sun, no creo que sea para tanto. Lo más importante es
que las reglas del JCP son muy claras ... El JCP es una organización
de estándares muy abierta. Naturalmente, no es perfecta. Pero
creo que una cosa muy importante es que puedes utilizar los
estándares que genera el JCP como estándares de Java de
código abierto. Y eso es extremadamente importante, porque esa
es la combinación que queremos ....
Puedes decir que Java no es de código abierto ...
pero es un argumento sin sentido. Porque no significa nada decir que
Java es o no es de código abierto. Es como decir que HTTP es o
no es de código abierto; esto no significa nada.
Es más, el proyecto Apache
Harmony está desarrollando algo que intenta ser una
"implementación certificada capaz de competir con las
mejores," disponible bajo la licencia Apache V2, permitida y
fomentada por el JCP.
Más allá del JCP
Moviéndose desde el metafórica catedral para el
bazar, un gran número de proyectos de Java existen fuera de
los estándares principales del JCP. Como se ha comentado
antes, Java es el lenguaje más utilizado en los proyectos en
SourceForge, y aún se pueden encontrar más proyectos de
código abierto que utilizan Java en java.net,
el Apache Jakarta Project,
Javalobby's Javaforge,
OpenSymphony, y en
incontables sitios independientes. Muchos de esos proyectos han
crecido hasta rivalizar los estándares oficiales del JCP en
“mindshare”(enlace
aportado por el traductor para aclarar este concepto), el más
obvio son los lightweight enterprise frameworks como el
framework Spring, que
ha atraído a muchos programadores frustrados con las
especificaciones “oficiales” como EJB
2.1. Los proyectos independientes también se han adaptado
rápidamente a los cambios fuera de Java y proporcionan sus
mejores características, como Rails
inspiró Trails, o el
proyecto AJAX simplificando Direct
Web Remoting (DWR).
Conclusiones
Con una diferencia de 10 años y unos pocos millones de
programadores es el momento para dejar las viejas suposiciones sobre
Java: la unión de lenguaje con la VM, tópicos del mundo
del código abierto sobre su prestigio vis-a-vis, y predecibles
críticas sin valor sobre su rendimiento o falta del mismo. Los
próximos diez años de Java se espera que sean
totalmente diferentes, posiblemente bifurcando no el lenguaje, pero
sí el foco, con muchos programadores que continuaran
trabajando en un lenguaje Java en evolución que se ejecuta en
varios entornos, mientras otros ejecutan muchos lenguajes diferentes
en la VM. Dentro de poco, preguntando "¿Qué es
Java?" podríamos preguntar "¿Qué Java,
el lenguaje o la VM?"
Chris Adamson es el editor de
ONJava y java.net, y es un consultor de Atlanta-based,
especializado en Java, Mac OS X, y desarrollador de medios.
Ir a ONJava.com.
Copyright ©
2006 O'Reilly Media, Inc.
Reader Comments