settitle - ¿Qué es la portabilidad? ¿Cómo es Java más portátil que otros idiomas?

set title java (11)

Como ya han dicho otros, la portabilidad es un concepto un tanto confuso. Desde cierta perspectiva, C es en realidad más portátil que Java. C hace muy pocas suposiciones sobre el hardware subyacente. Ni siquiera asume que hay 8 bits en un byte, o que los números negativos deben representarse utilizando el complemento de dos. Teóricamente, siempre que tenga una máquina basada en Von Neumann y un compilador, es bueno ir con C.

De hecho, un programa "Hello world" escrito en C funcionará en muchas más plataformas que un programa "Hello world" escrito en Java. Probablemente podría obtener el mismo programa "hello world" para trabajar en un PDP-11 y un iPhone.

Sin embargo, la realidad es que la mayoría de los programas del mundo real hacen mucho más que la salida "Hola mundo". Java tiene la reputación de ser más portátil que C porque, en la práctica , requiere mucho más esfuerzo para adaptar los programas C del mundo real a diferentes plataformas que los programas Java del mundo real.

Esto se debe a que el lenguaje C es realmente ANSI-C, que es un lenguaje muy simple de propósito general. No tiene soporte para programación de red, subprocesos o desarrollo de GUI. Por lo tanto, tan pronto como escriba un programa que incluya cualquiera de esas cosas, tendrá que recurrir a una extensión menos portátil de C, como Win32 o POSIX o lo que sea.

Pero con Java, la programación de red, los subprocesos y las herramientas de GUI están definidas por el lenguaje y se integran en cada implementación de VM.

Dicho esto, creo que muchos programadores también subestiman el progreso que C / C ++ ha hecho en lo que respecta a la portabilidad en estos días. POSIX hace mucho para proporcionar subprocesos multiplataforma, y cuando se trata de C ++, Boost proporciona bibliotecas de subprocesos y redes que son básicamente tan portátiles como cualquier cosa en Java. Estas bibliotecas tienen algunas peculiaridades específicas de la plataforma, pero también lo tiene Java.

Esencialmente, Java se basa en que cada plataforma tenga una implementación de VM que interpretará el código de bytes de una manera predecible, y C / C ++ se basa en bibliotecas que incorporan código específico de la plataforma utilizando el preprocesador ( #ifdef s). Ambas estrategias permiten la creación de hilos multiplataforma, redes y desarrollo de GUI. Simplemente, Java ha progresado más rápido que C / C ++ cuando se trata de portabilidad. La especificación del lenguaje Java tuvo subprocesos, redes y desarrollo de GUI casi desde el primer día, mientras que la biblioteca de redes Boost solo se publicó alrededor de 2005, y no fue hasta 2011 con C ++ 11 que los subprocesos portátiles estándar se incluyeron en C ++.

Me pregunto cómo Java es más portátil que C, C ++ y .NET y cualquier otro lenguaje. He leído muchas veces que java es portátil debido al intérprete y JVM, pero JVM simplemente oculta las diferencias arquitectónicas en el hardware, ¿verdad? Todavía necesitaríamos diferentes JVM para diferentes arquitecturas de máquinas. ¿Que me estoy perdiendo aqui? Entonces, si alguien escribe una capa de abstracción para C para las arquitecturas más comunes, digamos CVM, entonces cualquier programa en C se ejecutará en esas arquitecturas una vez que CVM esté instalado, ¿no es así?

¿Qué es exactamente esta portabilidad? ¿Se puede llamar a .NET portátil?

Cuando escribe un programa Java, se ejecuta en todas las plataformas que tienen JVM escrito para ellos: Windows, Linux, MacOS, etc.

Si escribes un programa en C ++, deberás compilarlo específicamente para cada plataforma.

Ahora, se dice que el lema de Java "escribir una vez, correr en todas partes" es un mito. No es del todo cierto para las aplicaciones de escritorio, que necesitan interacción con muchos recursos nativos, pero cada aplicación JavaEE puede ejecutarse en cualquier plataforma. Actualmente estoy trabajando en Windows, y otros colegas están trabajando en Linux, sin ningún problema.

(Otra cosa relacionada con la portabilidad es JavaEE (edición empresarial). Se dice que las aplicaciones escritas con tecnologías JavaEE se ejecutan en cualquier servidor de aplicaciones con certificación JavaEE. Sin embargo, esto no se cumple al menos hasta JavaEE6 ( ver aquí ))

Java es portátil desde la perspectiva del desarrollador: el código escrito en Java se puede ejecutar en cualquier entorno sin la necesidad de compilarlo. C no es portátil porque no solo está vinculado a un sistema operativo específico en muchos casos, sino que también está siempre vinculado a una arquitectura de hardware específica una vez que se ha compilado. Lo mismo es cierto para C ++. .Net es más portátil que C / C ++, ya que también se basa en una máquina virtual y, por lo tanto, no está vinculado a una arquitectura de hardware específica en tiempo de compilación, sino que se limita a las máquinas con Windows (oficialmente).

Tienes razón, la JVM es específica de la plataforma (¡tiene que serlo!), Pero cuando dices que Java es portátil, estás hablando de ello desde el punto de vista de un desarrollador y los desarrolladores de Java estándar no escriben la JVM, la usan: ).

Editar @ Raze2Dust Para responder a su pregunta. Si, podrías. De hecho, podría hacer que la plataforma Java sea específica escribiendo un compilador que genere código de máquina en lugar de código de bytes. Pero como algunos de los otros comentarios sugieren, ¿por qué harías eso? Tendría que crear un intérprete que asigne el código compilado a las operaciones de la misma manera que funciona la JVM. Entonces, en definitiva, definitivamente, podrías, pero ¿por qué lo harías?

Java proporciona tres tipos distintos de portabilidad:

Portabilidad del código fuente: un programa Java determinado debe producir resultados idénticos independientemente de la CPU subyacente, el sistema operativo o el compilador Java.

Portabilidad de la arquitectura de la CPU: los compiladores actuales de Java producen un código de objeto (llamado código byte) para una CPU que aún no existe. Para cada CPU real en la que se ejecutan los programas de Java, un intérprete de Java o una máquina virtual, "ejecuta" el código J. Esta CPU no existente permite que el mismo código objeto se ejecute en cualquier CPU para la que exista un intérprete de Java.

Portabilidad OS / GUI: Java resuelve este problema al proporcionar un conjunto de funciones de biblioteca (contenidas en las bibliotecas proporcionadas por Java, como awt, util y lang) que hablan de un sistema operativo imaginario y una GUI imaginaria. Al igual que JVM presenta una CPU virtual, las bibliotecas de Java presentan un sistema operativo virtual / GUI. Cada implementación de Java proporciona bibliotecas que implementan este sistema operativo virtual / GUI. Los programas Java que utilizan estas bibliotecas para proporcionar el puerto necesario y la funcionalidad GUI se portan con bastante facilidad.

Ver este link

La idea es que el lenguaje Java sea portátil (o más exactamente, el código de bytes compilado es portátil). Es correcto que cada máquina virtual requiera una implementación específica para un perfil de hardware determinado. Sin embargo, una vez que se haya realizado ese esfuerzo, todo el código de bytes de Java se ejecutará en esa plataforma. Usted escribe el código java / bytecode una vez, y se ejecuta en cualquier JVM.

.NET es bastante similar, pero con un énfasis mucho menor en el principio. El CLR es análogo a la JVM y tiene su propio bytecode. Mono existe en * nix, pero tienes razón en que no es "oficial".

La portabilidad es una medida de la cantidad de esfuerzo para hacer que un programa se ejecute en un entorno diferente al que se originó.

Ahora puede debatir si una JVM en Linux es un entorno diferente al de Windows (yo diría que sí), pero el hecho es que, en muchos casos, implica un esfuerzo cero si se cuida de evitar algunos errores.

La CVM de la que habla es mucho lo que las bibliotecas POSIX y las bibliotecas de tiempo de ejecución intentan proporcionar, sin embargo, existen grandes diferencias de implementación que hacen que los obstáculos se crucen. Ciertamente, en el caso de Microsoft y Apple, estos son probablemente intencionadamente para evitar que los desarrolladores presenten productos en plataformas de la competencia.

En el frente de .net, si puede apegarse a lo que proporciona mono, una implementación de .NET de código abierto, disfrutará de casi el mismo tipo de portabilidad que Java, pero dado que mono está significativamente por detrás de las versiones de Windows, esta no es una opción popular . No sé qué tan popular es esto para el desarrollo basado en servidor, donde puedo imaginar que es un problema menor.

La portabilidad no es una cosa en blanco y negro, sí o no. La portabilidad es la facilidad con la que puedo tomar un programa y ejecutarlo en todas las plataformas que nos interesan.

Hay algunas cosas que afectan esto. Uno es el lenguaje mismo. La especificación del lenguaje Java generalmente deja mucho menos hasta "la implementación". Por ejemplo, "i = i ++" no está definido en C y C ++, pero tiene un significado definido en Java. En términos prácticos, los tipos como "int" tienen un tamaño específico en Java (por ejemplo: int es siempre de 32 bits), mientras que en C y C ++ el tamaño varía según la plataforma y el compilador. Estas diferencias por sí solas no le impiden escribir código portátil en C y C ++, pero debe ser mucho más diligente.

Otra es la de las bibliotecas. Java tiene un montón de bibliotecas estándar que C y C ++ no tienen. Por ejemplo, subprocesos, redes y bibliotecas GUI. Existen bibliotecas de este tipo para C y C ++, pero no son parte del estándar y las bibliotecas correspondientes disponibles pueden variar ampliamente de una plataforma a otra.

Finalmente, está la cuestión de si puede tomar un ejecutable y soltarlo en la otra plataforma y hacer que funcione allí. Esto generalmente funciona con Java, asumiendo que hay una JVM para la plataforma de destino. (y hay JVM para muchas / la mayoría de las personas a las que les importa) Esto generalmente no es cierto con C y C ++. Normalmente, al menos vas a necesitar una recompilación, y eso es asumiendo que ya te has ocupado de los dos puntos anteriores.

Sí, si existiera un "CVM" para múltiples plataformas, eso haría que C y C ++ sean más portátiles, más o menos. Aún necesitaría escribir su código C de manera portátil (por ejemplo: no asumiendo nada sobre el tamaño de un int que no sea lo que dice el estándar) o escribiría a la CVM (suponiendo que haya tomado una decisión uniforme para todo este tipo de cosas en todas las plataformas de destino). También deberá renunciar al uso de bibliotecas no estándar (sin conexión a redes, subprocesos o GUI) o escribir en las bibliotecas específicas de CVM para esos fines. Entonces, realmente no estamos hablando de hacer que C y C ++ sean más portátiles, sino un CVM-C / C ++ especial que es portátil.

Una vez más, la portabilidad no es una cosa en blanco y negro. Incluso con Java todavía puede haber incompatibilidades. Las bibliotecas GUI (especialmente AWT) eran bastante notorias por tener un comportamiento inconsistente, y cualquier cosa que involucre hilos puede comportarse de manera diferente si te descuidas. En general, sin embargo, es mucho más fácil tomar un programa Java no trivial escrito en una plataforma y ejecutarlo en otra que hacer lo mismo con un programa escrito en C o C ++.

La portabilidad o como está escrito en Wikipedia, la portabilidad del software es la capacidad de reutilizar el mismo software (código) en múltiples entornos (OS). El java JVM es un JVM que puede ejecutarse en cualquier sistema operativo para el que fue diseñado: Windows, Linux, Mac OS, etc.

En .NET, es posible portar su software a diferentes plataformas. De Wikipedia :

El diseño de .NET Framework le permite, en teoría, ser independiente de la plataforma y, por lo tanto, compatible con todas las plataformas. Es decir, un programa escrito para usar el marco debe ejecutarse sin cambios en cualquier tipo de sistema para el cual se implementa el marco.

Y dado que Microsoft nunca implementó el marco .NET fuera de Windows y al ver que .NET es independiente de la plataforma, Mono ha hecho posible ejecutar aplicaciones .NET y compilar código para ejecutar en Linux.

Para lenguajes como C ++, Pascal, etc., tendrá que ir a cada sistema operativo y construirlo en esa plataforma para ejecutarlo en esa plataforma. El archivo EXE en Windows no es el mismo que el .so en linux (el código de la máquina) ya que ambos usan bibliotecas diferentes para comunicarse con el kernel y cada sistema operativo tiene su propio kernel.

Necesita la JVM para diferentes arquitecturas, pero, por supuesto, sus programas Java se ejecutan en esa JVM . Entonces, una vez que tenga una JVM para una arquitectura, sus programas Java estarán disponibles para esa arquitectura.

Así que puedo escribir un programa Java, compilarlo a código de bytes Java (que es independiente de la arquitectura), y eso significa que puedo ejecutarlo en cualquier JVM en cualquier arquitectura. La JVM abstrae la arquitectura subyacente y mi programa se ejecuta en una máquina virtual.

Usted pregunta si uno podría escribir una "C VM". No exactamente. "Java" es un gran término usado por Sun para significar muchas cosas, incluyendo tanto el lenguaje de programación como la máquina virtual. "C" es solo un lenguaje de programación: depende del compilador, el sistema operativo y la CPU decidir qué formato debe tener el binario resultante.

A veces se dice que C es portátil porque no especifica el tiempo de ejecución. Las personas que escribieron tu compilador pudieron elegir cosas que tienen sentido para esa plataforma. La desventaja es que C es lo suficientemente bajo y que las plataformas son lo suficientemente diferentes, por lo que es común que los programas C funcionen bien en un sistema y no en otro.

Si combina el lenguaje C con una ABI específica, podría definir una VM para ello, de manera análoga a la JVM. Ya hay algunas cosas como esta, por ejemplo:

La "Especificación de compatibilidad binaria de Intel" es un ejemplo de tal ABI (que casi nadie usa hoy en día)
"Microsoft Windows" también podría ser un ABI de este tipo (aunque uno enorme y subespecificado), para el que Wine es una máquina virtual que ejecuta programas escritos para él.
"MS-DOS", para el que dosemu es una VM
"Linux" es uno de los más populares hoy en día, cuyos programas pueden ser ejecutados por Linux, NetBSD o FreeBSD
"PA-RISC", para el cual el Dynamo de HP era una máquina virtual tipo JIT

Todas estas VM de C son, de hecho, una máquina real: nadie, AFAIK, ha creado una VM de C que fuera puramente virtual. Esto no es sorprendente, ya que C fue diseñado para ejecutarse de manera eficiente en hardware, por lo que también podría hacerlo funcionar normalmente en un sistema. Como mostró HP, aún puede hacer un JIT para ejecutar el código de manera más eficiente, incluso en la misma plataforma.

WORE - Escribe una vez corre por todas partes

En realidad, esto se limita a las plataformas que tienen una JVM, pero esto cubre la mayoría de las plataformas que desearía implementar. Está casi a medio camino entre un lenguaje interpretado y un lenguaje compilado, obteniendo los beneficios de ambos.