¿Cuál es mejor, Android o Java?
Creo que las personas que estudian Android habrán pensado o querrán saber esta pregunta, así que lea este artículo con paciencia. Tendrá una comprensión más profunda de la relación entre Android y Java.
¿Android es equivalente a Java? Tenga en cuenta que no dije igual, dije equivalente, como en P = NP.
Formatos de clase/código de bytes comparables En muchos niveles, Android y Java son claramente comparables. Las aplicaciones de Android están escritas en el lenguaje Java(TM) y compiladas utilizando javac del JDK (o una herramienta equivalente, como ECJ). Este proceso produce código de bytes Java estándar (archivos .class). Estos archivos luego se convierten en archivos .dex de Android. Desde una perspectiva de uso, es un archivo de clase Java en un formato diferente. Sí, es un formato superior; una gran mejora con respecto al diseño de Sun de 1994. Pero al igual que puedes convertir una imagen en formato GIF a un formato PNG más avanzado y perfectamente equivalente, aunque sus flujos de bytes son completamente diferentes.
Los formatos de archivo equivalentes son muy diferentes en los detalles de implementación, principalmente con fines de optimización. Por ejemplo, si simplemente estamos satisfechos con flujos de datos de vídeo de baja eficiencia y no utilizamos tecnología de compresión de alta gama en diferentes marcos, entonces podemos evitar el problema de luchar con las patentes de decodificación de vídeo MPEGLA.
Existen varias motivaciones para el diseño de archivos de clase específicos de Android; y evitar conflictos con la protección de la propiedad intelectual de Sun es obviamente un factor importante. En cualquier caso, Google no se ha alejado lo suficiente de Java. Los dos formatos de archivo son muy similares. Se diferencian en las estructuras de datos subyacentes específicas, pero estas estructuras son sintácticamente consistentes y almacenan exactamente la misma información. Creo que en JavaSE o JavaME VM es fácil agregar un analizador .dex al cargador de clases de su sistema para cargar "clases de Android".
El hecho de que el SDK de Android se base en la conversión .java -> .class -> .dex no es trivial ni carece de pérdidas. El hecho de que "no hay pérdida" es importante: cuando GIF = PNG, no es diferente a un archivo JPG dañado: no decodifica exactamente la misma información. Si JVM y Dalvik fueran independientes, sería difícil escribir una herramienta relativamente simple para convertir código compilado de uno a otro sin hacer concesiones: sin perder información, sin usar redundancia para compensar algunas características. class en una VM pero no en otra, no hay necesidad de una capa de tiempo de ejecución adicional para implementar la API principal de una VM en otra VM.
(Sé lo complejo que es el conversor dx. He visto su código fuente. Ese conversor de código de bytes es un descompilador/recompilador enorme y con todas las funciones, construido a través de SSA Done. Pero el conversor todavía es conceptualmente trivial; el mapeo del código de bytes de Java al código de bytes de Dalvik es fluido por diseño. La pila está optimizada en función de los detalles en la arquitectura de registro; lo importante es, por ejemplo, que el sistema de tipos de la capa VM sea completamente consistente). >
La compatibilidad entre Dalvik y JVM también es fácil de ver con claridad. No es sólo un problema con el código fuente o el formato del código de bytes: ocurre lo mismo con sus homólogos en tiempo de ejecución. Una vez que se carga una "clase de Android" en la máquina virtual Dalvik, se ejecutará como una clase de Java y funcionará como una clase de Java. Si conoce la programación Java (hasta los detalles de alto nivel y bajo nivel), también conoce la programación de Android. Solo necesita aprender algunos conceptos nuevos de API y marco. Son sistemas peer-to-peer.
¿Recuerdas .NET de Microsoft? Cuando .NET se lanzó por primera vez, el campo de Java rápidamente contraatacó, acusando a .NET de plagiar Java.
Yo también soy uno de ellos, pero hoy veo el problema con mayor claridad. Sí, solía ser una estafa seria; C# 1.0 era una... La forma más fácil de distinguir un idioma de otro es observar sus estilos idiomáticos: toString() versus ToString(), por ejemplo. Pero en la especificación de VM más importante, Microsoft ha hecho muchos deberes. Su CLR, CLI y su marco central son muy diferentes de Java, por lo que no podemos decir la ecuación JVM = CLR. No puede utilizar una herramienta de conversión de formato de archivo simple para convertir sus clases Java compiladas en código que pueda ejecutarse en el tiempo de ejecución .NET.
¿Quieres pruebas? Sólo tienes que mirar IKVM para descubrirlo. Este es un proyecto muy interesante que hace que Java y .NET sean compatibles entre plataformas, de modo que su código Java pueda ejecutarse en CLR (o el tiempo de ejecución de .NET equivalente, como Mono) sin modificaciones... Pero IKVM no es un dx simple. -Como convertidor de formato de archivo. La conversión de clases Java y la adaptación de la API central de Java son muy complicadas, incluso para un programa HelloWorld simple. Los mecanismos internos de cada plataforma, como reflexión, seguridad, paralelismo, manejo de excepciones, verificación de código de bytes, E/S y otras API centrales, tienen aproximadamente las mismas características, pero son completamente diferentes en detalles. IKVM no pase por obstáculos difíciles para que su código Java se ejecute en la máquina virtual .NET. Se basa en una enorme capa de tiempo de ejecución adicional para adaptarse a la API JavaSE completa desde el código fuente OpenJDK. Llevo unos años siguiendo el desarrollo de IKVM en general - leí el excelente blog de IKVM - así que soy plenamente consciente del enorme esfuerzo que ponen en adaptar programas Java y aplicaciones JavaSE a .NET. (El trabajo aún está inconcluso; y gran parte de él se realiza a expensas de algo de rendimiento).
(El antiguo Visual J++ Visual J# tampoco era un simple conversor de Java a .NET. Yo no No quiero discutirlo, pero definitivamente podemos decir que Visual J# no es mucho más compatible con Java que el primer IKVM)
Incluí P = NP en la discusión; algunas personas se refieren a la equivalencia de Turing (. Se introdujo la teoría de la equivalencia de Turing, diciendo que cualquier plataforma/lenguaje/VM completo de Turing es equivalente entre sí. Esto es cierto, pero no tiene nada que ver con este tema. El modelo de Turing es demasiado general; tomarlo al pie de la letra destruiría todo el sistema de patentes de software (¡aunque eso no es malo!). Necesitamos trazar una línea en el terreno para la equivalencia de JVM, una línea más cercana a las necesidades prácticas y más alejada de la equivalencia de Turing. En mi opinión, la trivial conversión de formato binario, el exhaustivo código fuente de alto nivel y la compatibilidad en tiempo de ejecución colocan a Android claramente dentro de la línea de equivalentes de Java.
API y equivalentes en tiempo de ejecución Android utiliza un subconjunto bastante grande de API de JavaSE. Estas API (del proyecto Harmony) son implementaciones completamente nuevas, pero siguen el modelo de Java SE. Si no fuera por el problema de la licencia TCK, Harmony podría haber obtenido la certificación JavaSE. Pero eso no cambia el hecho de que las API de Harmony y JavaSE son completamente equivalentes: esto es por diseño, no por accidente. Como escribió recientemente Charles Nutter, famosa personalidad de JRuby:
Android admite un subconjunto incompleto (pero bastante grande) de la biblioteca de clases Java 1.5. Este subconjunto es lo suficientemente grande como para que un proyecto complejo de JRuby pueda ejecutarse en Android con pocas modificaciones y muy pocas limitaciones.
Parece que Dalvik está tan cerca de JVM que tiene que ser totalmente compatible con la mayoría de las especificaciones de JVM, incluido el JMM completamente detallado (al igual que Android admite subprocesos y concurrencia de estilo Java, ya profundos). en el paquete avanzado java.util.concurrent). Pero, ¿por qué hay tantas afirmaciones de que "Dalvik es una nueva máquina virtual" o "Dalvik no puede ejecutar clases de Java" (el 90% de los foros y blogs que discuten esta demanda sostienen esta opinión)?
Pensamientos finales Este blog no trata sobre la base legal de la demanda entre Oracle y Google. Ignoraré (borraré) aquellos comentarios que estén fuera de tema (no relacionados con Android = Java). Simplemente odio la tontería de que "Android no tiene nada que ver con Java" y los defensores de Android necesitan encontrar un argumento más significativo;
(Esperaré y veré cómo avanza esta demanda, con toda mi previsión, hasta que se conozcan todos los detalles y el resultado final. A menos que tenga información privilegiada (yo no la tengo), no se preocupe demasiado. Mantén la calma. No conocemos las verdaderas motivaciones y planes de Oracle, ni de Google. No conocemos la historia detrás de escena desde que Google anunció por primera vez el nacimiento de Android en 2007 (lo que llevó al colapso de Android). el ecosistema JavaME), Sun lo odiaba, pero al final tuvo que actuar con el rabo entre las piernas. No creo que ningún holding accionario con mil millones de dólares tenga motivos altruistas: Google no, Oracle no. , incluso el antiguo me encanta. Tampoco Sun. Ya veremos)
No creo que Google sea capaz de crear una plataforma basada en el estilo Java (como .NET). alejarse demasiado de Java, haga eso). Dalvik, así como el marco de trabajo de Android, puede ser el resultado final de sopesar el deseo de ser altamente compatible con la gran cantidad de programas Java, bibliotecas de clases, genios de Java y cadenas de herramientas de Java existentes. Después de apretar los dientes y patear, Microsoft renunció a los beneficios de la migración de Java ya preparada y creó un nuevo .NET. Google no hace esto.
Esta ecuación Android = Java obviamente no incluye todo (no es una correspondencia uno a uno). Cada plataforma tiene sus propias API únicas y, por supuesto, Android es un sistema operativo completo, que incluye un kernel basado en Linux, un sistema de gráficos, una pila de telecomunicaciones, etc. Obviamente, solo estoy hablando de las partes más utilizadas: áreas de usuario centradas en Java/dependencias del código fuente de Java, clases de Java (independientemente del formato), API de Java (incluidas miles de API de JavaSE de uso común) y el excelente Java- como marco de aplicación de máquina virtual. Una forma precisa de describir la relación entre Android y otras plataformas Java es utilizar el concepto de versiones. Recuerdo que un blogger dijo una vez algo como "No hay 'J' en Android". Bueno, no es demasiado tarde para decirlo ahora: sugiero cambiar el nombre de Android Java GE (Java Google Edition). De esta manera ya no habrá confusión
Redirigido desde: Foro Tecnológico 51CTO