¿Es Java (todavía) el lenguaje de elección multiplataforma? [cerrado]

20

Cuando comencé a usar Java en los años noventa, todo fue "¡ Escribe una vez, corre en cualquier lugar! " Desde el primer día. Eso probablemente era todo cierto entonces y yo también era parte del coro.

Ya no estoy seguro de qué pensar sobre eso, teniendo en cuenta todos los demás lenguajes que utilizan tiempos de ejecución multiplataforma (python, flash, perl, html, php ...). Pero todavía veo muchos argumentos que dicen que debes usar Java porque supuestamente es mejor para el desarrollo multiplataforma.

Entonces, ¿sigue siendo cierto hoy? ¿Sigue siendo Java el lenguaje elegido para el desarrollo multiplataforma?

  • Por favor sea específico con enfoque en los aspectos multiplataforma.
  • No estoy pidiendo comparaciones de características del lenguaje general.

Actualización: ¡Grandes respuestas hasta ahora! La mayoría de las respuestas parecen estar favoreciendo Java o la web. ¿Alguna aportación de la multitud de guiones?

Martin Wickman
fuente
3
Este comentario no aborda el meollo de la pregunta, pero es un factor a tener en cuenta: las aplicaciones web basadas en Java dirigidas a usuarios de Windows son algo de lo que hay que alejarse. Oracle JVM para Windows ha tenido muchos problemas de seguridad últimamente. Como tal, es posible que los usuarios inteligentes no usen aplicaciones web basadas en Java porque han desinstalado la JVM.
meter
Su pregunta se basa en la suposición de que incluso era el lenguaje de plataforma cruzada elegido para comenzar.
Lucas Ramage

Respuestas:

10

los lenguajes de estilo de script como python también facilitan el desarrollo multiplataforma. Ahora, si le gusta Python (u otros lenguajes similares) depende de usted, y probablemente no necesitemos comenzar ese debate aquí.

Java intenta forzarlo a escribir código que se ejecutará de forma portátil, mientras que python le permite escribir código portátil. El lenguaje actual de Python se ejecutará de manera portátil, pero las bibliotecas externas pueden o no. Además, python dará acceso libremente a servicios específicos de la plataforma.

¿Tiene Java una ventaja allí? Creo que en cualquier caso puede escribir el código portátil con similar facilidad. Es decir, puede escribir código y generalmente funcionará en diferentes plataformas. Pero no puede salirse con la suya simplemente escribiendo código y suponiendo que funcionará en todas partes. Trabajé en un proyecto de Python que produjo la versión para Windows, Linux y Mac y nos encontramos con muy pocos problemas de plataforma cruzada. (El único que recuerdo fue debido a un error en la biblioteca que estábamos usando pygame, que causó problemas de dibujo en Linux. Esto se solucionó al actualizar la versión de pygame que usamos)

Otro problema es el despliegue. Si desea distribuir programas independientes que ejecutan su código, deberá producir diferentes versiones para diferentes plataformas. Para Java, puede distribuir una versión y asumir que el usuario tiene Java instalado o puede instalarlo. En este caso, Java probablemente gane en la simplicidad del departamento de implementación.

Al final, creo que todo se reduce a qué idioma le gusta trabajar y qué tipo de implementación debe realizar.

Winston Ewert
fuente
18

Aunque Java puede no ser el o la única viable herramienta multiplataforma, tiene algunas ventajas:

  • Es extremadamente rápido
  • Es extremadamente robusto.
  • Es extremadamente portátil (por ejemplo, el código de bytes compilado hace 10 años en Windows 95 funciona bien en OS X hoy).

y algunas debilidades:

  • Las bibliotecas principales de la GUI (Swing ...) muestran su edad (las adiciones de terceros ayudan aquí)
  • El lenguaje en sí podría ser menos detallado (por ejemplo, excepciones marcadas ...).
  • El tiempo de inicio podría ser más rápido (aunque está mejorando todo el tiempo).

Cuando se habla específicamente de la plataforma Java , hay un punto más:

  • Hay bastantes lenguajes que se ejecutan en la JVM e interoperan con Java.
Joonas Pulakka
fuente
19
¿Extremadamente rápido? ¿Comparado con que?
HardCode
18
@ HardCode: en comparación con cualquier idioma interpretado o la mayoría de los idiomas compilados. C y C ++ se pueden hacer más rápido en algunos casos, pero es difícil y se vuelve cada vez más difícil cuando crece el número de núcleos. Con la concurrencia de Java (utilizando esos núcleos múltiples de manera eficiente) es mucho más fácil de lograr en la práctica.
Joonas Pulakka
55
@HardCode, aparentemente el JVM es el tiempo de ejecución más rápido disponible para casi cualquier idioma interpretado (a diferencia de los que los hackers hicieron)
14

Es tan cierto hoy como lo era en aquel entonces, es decir, no del todo. Java es escribir una vez, probar y depurar en todas partes. Claro, eso es mucho menos trabajo que un puerto completamente nuevo, pero generalmente es más trabajo de lo que la exageración inicial nos hizo creer.

Nuestro producto tiene un servidor Java que se ejecutará en Windows o Linux, pero hemos visto problemas específicos del sistema operativo y nos aseguramos de tener servidores Linux y Windows disponibles para soporte / prueba si es necesario. Las UI de Java tienden a tener más problemas que los servidores (aunque muchos son cosméticos y, por lo tanto, pueden ignorarse dependiendo de la aplicación).

Aunque no es estrictamente un lenguaje para mí, la web es la plataforma multiplataforma de elección. Un front-end HTML / JavaScript significa que su aplicación se ejecutará en casi cualquier plataforma de cliente y, en la mayoría de los casos, ese era el objetivo real: no tener que preocuparse si era una Mac o una PC, qué versión de sistema operativo, etc.

Por supuesto, generalmente seguirá dictando la plataforma del servidor, pero cuando se trata solo de que las personas se vuelven mucho más flexibles, particularmente en estos días en que la mayoría de las empresas ya admiten una combinación de servidores Windows y Linux.

Jon Hopkins
fuente
8
Buena respuesta. Por supuesto, asegurarse de que su aplicación funcione correctamente en todas las versiones del navegador también puede ser un dolor de cabeza.
Tim Goodman el
55
@Tim: buen punto. Creo que las aplicaciones de navegador son mucho más "prueba y depuración en todas partes" que las aplicaciones de escritorio Java.
Joonas Pulakka
55
@Tim: +1. Lograr que una aplicación de aplicación web funcione de la misma manera en todos los principales navegadores es tan difícil como lograr que una aplicación Java funcione de la misma manera en múltiples sistemas operativos.
Yevgeniy Brikman
3
"escribir una vez, depurar en todas partes" no es cierto en mi experiencia. Mientras sea sensato y evite las dependencias específicas de la plataforma, no he tenido problemas al ejecutar el mismo código Java en varias plataformas (incluidas las GUI). Sí, por supuesto, deberías probarlo, pero creo que en casi 15 años de codificación de Java solo tuve una vez un verdadero problema de portabilidad (que fue mi culpa por codificar los separadores de directorios de Windows en lugar de utilizar el útil File.pathSeparator multiplataforma de Java !)
mikera
2
@mikera: hemos visto problemas entre Linux y Windows que no tienen nada que ver con nuestro código. Son raros pero existen.
Jon Hopkins
9

Personalmente, diría que Java sigue siendo el lenguaje de elección multiplataforma, y ​​es probable que permanezca allí por algún tiempo (junto con las aplicaciones web). Escribí un poco más sobre el tema en esta publicación sobre Java como plataforma de elección , pero en particular en el frente multiplataforma:

  • Siempre que tenga cuidado con sus dependencias (por ejemplo, evite las bibliotecas que usan JNI para interactuar con el código nativo), entonces Java puede escribirse y ejecutarse sin modificaciones en todas las plataformas JVM principales

  • Debido a que Java generalmente se distribuye como código de bytes independiente de la máquina, puede ejecutarse sin recompilación en cualquier JVM (ya que la JVM local maneja la compilación JIT en código nativo). Por ejemplo, he logrado que una aplicación GUI compleja y razonable se ejecute por primera vez en una Mac después de desarrollarla en Windows, con el mismo archivo jar . Compare eso con la mayoría de los otros lenguajes multiplataforma, que generalmente requieren bibliotecas diferentes o una recompilación para una plataforma diferente.

  • Muchas de las bibliotecas principales que necesita (GUI, redes, IO, etc.) son parte del tiempo de ejecución estándar y están escritas en una plataforma cruzada. Por lo tanto, no necesita buscar y probar bibliotecas multiplataforma, tiene la garantía de que casi todo lo que necesita ya está allí en el entorno de tiempo de ejecución.

mikera
fuente
3

Creo que tienes esas opciones:

1) usa un

  • compilado o
  • lenguaje interpretado

2) ¿Cómo empacará y entregará su código?

  • ¿Un "front-end", un binario / script?
  • ¿Un "front-end", múltiples binarios / scripts?
  • Múltiples "front-end", múltiples binarios / scripts?

Esas elecciones afectan el rendimiento, la visibilidad y la distribución del código soure.

¿Te importa regalar tu código fuente? Los idiomas compilados pueden ser para ti. Los lenguajes compilados parecen funcionar mejor en micro-puntos de referencia que los lenguajes interpretados (incluso JIT). Además, si depende de un entorno de tiempo de ejecución como Java, Python, Ruby, etc., su código podría ser más difícil de distribuir.

Descubrí que las aplicaciones de escritorio multiplataforma más populares van para "Un front-end, múltiples binarios" usando C / C ++ y una biblioteca de widgets multiplataforma, por ejemplo, Audacity, Blender, Firefox, Google Earth, OpenOffice, Skype, Songbird, Stellarium, VLC

LennyProgrammers
fuente
Cometió un error interesante al enumerar Skype en sus ejemplos, pero esta aplicación súper popular en realidad se inició con Delphi / Pascal en Windows y se portó con C / C ++ en Linux y Objective-C en MacOS / iPhone
Maksee
Creo que la dicotomía compilada / interpretada es un poco engañosa: Java, en cierto sentido, tampoco lo es porque está compilada en un bytecode independiente de la máquina para su distribución (es decir, ya no está en forma de fuente), y luego JIT compilada más tarde en código nativo en cualquier máquina en la que estés corriendo. Es totalmente multiplataforma, pero también le brinda un rendimiento nativo, además de que no tiene que distribuir su fuente si no lo desea. ganar ganar ganar.
mikera
0

Yo diré que no. Python y Ruby se usan mucho y también JavaScript para el lado del cliente y del servidor. Personalmente uso .NET y no tengo problemas para que se ejecute en Mac y Linux (mientras desarrollo en Windows)

-editar- escuché que LLVM se está volviendo popular pero sigue siendo extremadamente pequeño. Eso te permitirá usar C ++ multiplataforma en un solo binario. Aparentemente se ejecutará en el navegador, pero no he visto un ejemplo en el que le permita modificar el dom o llamar a javascript.


fuente
LLVM no se trata de ejecutarse en un navegador ... ¿Estás hablando de emscripten?
Camilo Martin
Comprueba la fecha. Hace 4 años emscripten no existía. Se suponía que NativeClient funcionaba (y se estaba ejecutando), pero no lo hizo.
Ahora veo la fecha, pero aún así, LLVM nunca fue específicamente sobre los navegadores, ¿verdad?
Camilo Martin
1
No Aunque desearía poder escribir C ++ o algún otro lenguaje compatible con LLVM en lugar de JS ...
En ese sentido ...
Camilo Martin
-1

Si incorporas plataformas móviles a la mezcla, al menos también deberías incluir la recompilación. Por ejemplo, android, j2me.

Conor
fuente