java - que - jnlp windows 10
Java Web Start-Popularidad (8)
Creo que se debe principalmente a la falta de conciencia. Funciona muy bien. Bastante transparente. La aplicación solo descarga si es la primera vez, ha habido una actualización o si el usuario final ha borrado la caché. ¡Una excelente manera de implementar aplicaciones de escritorio completas que el usuario no tendrá que preocuparse por la actualización manual!
Recientemente utilicé una aplicación Java Web Start. Lo lancé desde mi navegador web usando un enlace jnlp incrustado en la página que estaba viendo. La aplicación se descargó, lanzó y funcionó perfectamente. Tenía acceso a mi sistema de archivos local y recordé mis preferencias entre reiniciarlo.
Lo que quiero saber es por qué las aplicaciones Java Web Start no son un formato de entrega más popular para aplicaciones complejas en la web. ¿Por qué los desarrolladores a menudo gastan mucho tiempo y energía en replicar la funcionalidad de escritorio en html / javascript cuando la potencia de una aplicación de escritorio se puede entregar más fácilmente usando Java y Java Web Start?
Sé que en algunos entornos corporativos, por ejemplo, la banca, son formas relativamente populares de entregar aplicaciones comerciales complejas a los clientes, pero ¿por qué no son generalizadas en toda la web en su conjunto?
(En aras de la discusión supongamos un mundo donde: las fuentes de descarga son "confiables" y las aplicaciones "firmadas" (es decir, sin problemas de seguridad), las velocidades de descarga son rápidas (el tiempo de carga es rápido) y los desarrolladores conocen Java (en los números que saber html / js / php)).
El problema con Webstart es que tienes que ''iniciar'' algo que no es tan rápido incluso con una conexión rápida, mientras que con una aplicación web ingresas la URL y la aplicación está ahí.
También muchas cosas pueden salir mal con webstart. Tal vez el usuario previsto no tiene los privilegios necesarios, o el proxy de webstart está configurado incorrectamente, o algo salió mal con las dependencias de jre o simplemente no hay java instalado en primer lugar. Entonces, para el promedio de John Doe en internet, no es del todo agradable.
En entornos controlados, como una empresa, es una solución buena y fácil en muchos casos.
Hay un problema muy grande: no permite "iniciar el programa de forma instantánea y, a CONTINUACIÓN, verificar y descargar las actualizaciones en segundo plano", que es a lo que el comportamiento de las aplicaciones convergen.
Considero que esto es una molestia tan grande que estamos buscando activamente otra tecnología que proporcione eso.
Un obstáculo importante para Java Webstart es probablemente que todavía necesite tener una JVM instalada antes de que pueda intentar descargar e iniciar su aplicación. Todos tienen un navegador. No todos tienen una JVM.
Editar: Desde entonces, adquirí experiencia práctica en webstart y ahora puedo agregar estos dos puntos:
- La secuencia de comandos Deployment Toolkit y la JVM modularizada lanzada en algún lugar alrededor de Java 1.6u10 hacen que el requisito de JVM sea menos problemático ya que puede descargar automáticamente una JVM y el núcleo de la API e iniciar el programa descargando el resto.
- Web Start tiene errores graves. Incluso entre las versiones de Java 1.6 había una que descargaba la aplicación completa cada vez, y otra que la descargaba y luego fallaba con un mensaje de error oscuro. En general, realmente no puedo recomendar confiar en un sistema tan frágil.
He trabajado en una aplicación implementada por JWS durante unos años sobre una base de usuarios de unos pocos miles y sus actualizaciones automáticas son realmente un gran dolor.
En cada actualización, por alguna razón, docenas de usuarios se quedan "atrapados en el medio". Todo lo que obtienes es la excepción de "clase no encontrada" (si tienes suerte), o no es informativo "no se puede iniciar" desde JWS incluso antes de que llegue a tu código. Parece que la actualización está medio descargada. O, en otras palabras, no descarga y aplica la actualización de forma atómica Y tiene un almacenamiento en caché deficiente, por lo que relanzar la aplicación desde la misma URL no soluciona nada.
No hay forma de resolverlo más que borrar el caché JWS o proporcionar una URL diferente (por ejemplo, append ?dummyparam=jwssucks al final). Incluso yo, como desarrollador, lo golpeo a veces y no veo una forma de evitarlo.
Cuando funciona, funciona. Pero con demasiada frecuencia no es así, y luego es un gran dolor para usted y su servicio de ayuda. No lo recomendaría para uso empresarial o de misión crítica.
A partir de estas publicaciones, parece que al utilizar Web Start, es importante preocuparse por el servidor. El "gran dolor" de descargar la aplicación en cada inicio puede ser causado por un sello de tiempo incorrecto entregado desde el servidor. Aquí no se debe configurar la aplicación, sino el servidor para usar el almacenamiento en caché correctamente y no solo para deshabilitarlo. Acerca de Buggy Start, no estoy muy seguro, pero me parece que esto también puede deberse a una conexión no confiable.
La ventaja importante del inicio web es que funciona muy bien con OpenJDK bajo Linux. Los clientes de algunos desarrolladores felices usan Windows solamente pero mis clientes no.
HTML y JavaScript, mencionados en la pregunta inicial, son enfoques más ligeros que funcionan bien con tareas más pequeñas, como botones animados o incluso tablas interactivas. El nicho de Java parece estar relacionado con tareas mucho más complejas.
Creo que el motivo no es la seguridad ni el tiempo de inicio de la aplicación. Vamos a entender qué hay detrás de la escena antes de descubrir la causa raíz.
El Panel de control de Java tiene una configuración que permite a los usuarios usar la configuración de proxy predeterminada del navegador o anularla. En otras palabras, los equipos de infraestructura pueden personalizar las imágenes de instalación de Windows u OS para tener JVM preinstalado con configuraciones de proxy empresarial. Entonces creo que esto no es un problema en absoluto.
Java Web Start realmente almacena en caché todas las aplicaciones con configuraciones personalizables en el Panel de control de Java. Una vez que la aplicación se almacena en caché, la aplicación se "instala" al igual que otras aplicaciones. Aunque la ejecución por primera vez puede ser lenta, la segunda vez será rápida debido a la técnica de asignación de memoria inteligente de JVM. Por lo tanto, el tiempo de inicio podría ser un problema, pero muchos sitios web (incluso internos de la empresa) ahora se migran al portal. Un portal web normalmente contiene muchas bibliotecas no utilizadas para fines de desarrollo debido al hecho de que el portal en sí no anticipa qué tipos de portlets se crean e implementan en una página específica. Por lo tanto, la descarga de una sola página de portal podría consumir hasta MB y completar una página en más de 5 segundos; esta es solo una página y el almacenamiento en caché ayuda hasta en un 30%, pero todavía hay muchos componentes HTML / Javascript / CSS necesarios para descargar cada vez. Con esto, estoy seguro de que Java Web Start es una ventaja aquí.
Java Web Start no se descarga nuevamente si está almacenado en caché, siempre y cuando la copia del servidor NO esté actualizada. Por lo tanto, si, por ejemplo, un software de gestión de proyectos como MS Project, se completa utilizando SmartClient (similar a JWS), el intercambio de información entre el cliente y el servidor sería puramente datos sin presentación, como la actualización completa de la página del navegador. Incluso con la ayuda de Ajax, no elimina por completo la descarga de página completa. Además, muchas compañías consideran que Ajax es aún inmaduro y no seguro. Es por eso que Ajax es un tema candente en los círculos de desarrolladores pero aún no dentro del software empresarial. Con esto en mente, las aplicaciones de JWS definitivamente tienen más ventajas, como la forma en que las aplicaciones JWS se implementan y ejecutan en entornos protegidos, se firman y tienen una GUI mucho más interactiva.
Otras ventajas incluyen un desarrollo más rápido (más fácil de depurar en código y rendimiento), interfaz de usuario receptiva (no requiere Comet Servers para proporcionar funcionalidad PUSH) y ejecución más rápida (seguramente porque las computadoras cliente procesan GUI sin traducción como HTML / Javascript / CSS, y menos procesamiento de datos).
Después de todo esto, todavía no he tocado la pregunta, ¿por qué JWS no es tan famoso?
Mi opinión es que es lo mismo que el comentario de Brian Knoblauch, es sin conciencia.
Las personas de TI también se sienten atraídas por el despliegue de Tecnologías Web, Ajax PUSH, GWT, y todas esas palabras de moda las predisponen a la diversión de usar diferentes tecnologías o a resolver los desafíos técnicos en lugar de lo que realmente funciona para los clientes.
Eche un vistazo a Citrix. Creo que Citrix es realmente una gran idea. Citrix le permite construir sus propias granjas de aplicaciones detrás de la escena. Existen muchas estrategias de actualización e implementación que puede utilizar sin afectar la experiencia del cliente. La implementación de Citrix es extremadamente fácil, estable y segura. Las empresas todavía lo están usando. Sin embargo, creo que JWS es incluso mejor que Citrix. La idea de JWS es ejecutar aplicaciones en máquinas cliente en lugar de alojar toneladas de granjas de servidores donde las máquinas cliente son capaces de ejecutar estas aplicaciones. ¡Esto le ahorra a una compañía mucho dinero! Con JWS, el equipo de desarrollo aún puede construir lógica de negocios y datos en el lado del servidor. Sin embargo, sin la unidad de procesamiento web y dejar que las computadoras cliente realicen el proceso de renderizado, reduce en gran medida la cantidad de consumo de red y la potencia de procesamiento del servidor.
Otro ejemplo de por qué JWS es una idea increíble es Blackberry MDS. Las aplicaciones de Blackberry son en realidad aplicaciones de Java traducidas de Javascript. Con el estudio MDS de BB, usted usa la herramienta GUI para construir la GUI de la aplicación BB, codificando la lógica de la GUI en Javascript. Luego, las aplicaciones se traducen y despliegan en un servidor de BES. Luego, el servidor BES distribuirá estas aplicaciones a BB. En cada BB, ejecuta una delgada aplicación de Java con capacidad de representación gráfica y de red únicamente. Siempre que la aplicación requiera datos, se comunica con BES a través de servicios web para consumir servicios de otros servidores. ¿No es solo la versión de JWS BB? Ha sido extremadamente exitoso.
Finalmente, creo que JWS no es popular debido a la forma en que Sun lo anuncia. BB nunca anuncia lo buenas que son sus aplicaciones BB Java, creen que a los clientes ni les importará qué es. BB anuncia los beneficios de usar MDS para desarrollar aplicaciones: Rápido, Ahorro de costos, Retorno de negocios.
Solo mi, un poco largo, 2 centavos ... :)
Java Web Start es un sucesor de Applets de Java, y los applets se quemaron en torno al nuevo milenio. Pero, todavía creo que los Applets de Java son mucho mejores que GWT o Javascript.