Domanda

Recentemente ho usato un'applicazione Java Web Start. Ho lanciato dal mio browser Web utilizzando un collegamento jnlp incorporato nella pagina stavo vedendo. L'applicazione è stata scaricata, lanciato e ha lavorato bene. Essa ha avuto accesso al mio file system locale e ricordato le mie preferenze tra riavviarlo.

Quello che voglio sapere è il motivo per cui sono applicazioni Java Web Start non è un formato di distribuzione più popolare per le applicazioni complesse sul web? Perché gli sviluppatori spesso trascorrono molto tempo ed energia replicare la funzionalità desktop in html / javascript quando la potenza di un'applicazione desktop potrebbe essere consegnato più facilmente usando Java e Java Web Start?

So che in alcuni ambienti aziendali, per esempio bancario, sono modi relativamente popolari di fornitura di applicazioni di trading complesse per i clienti, ma perché non sono pervasiva in tutto il web nel suo complesso?

(Per il bene della discussione supponiamo un mondo in cui: fonti per il download sono "trusted" e le applicazioni sono "firmate" (cioè senza problemi di sicurezza), la velocità di download sono veloci (tempo di caricamento è veloce) e gli sviluppatori sanno Java (in i numeri sanno html / js / php)).

È stato utile?

Soluzione

Credo che la ragione non è di sicurezza, né di avvio tempo della app. Cerchiamo di capire cosa c'è dietro la scena prima di scoprire la causa principale.

Pannello di controllo Java ha impostazioni che consentono agli utenti di utilizzare le impostazioni proxy del suo navigatore di default o di sostituirle. In altre parole, le squadre di infrastrutture sono in grado di personalizzare il Windows o immagini di installazione del sistema operativo ad avere JVM pre-installato con le impostazioni del proxy aziendale. Quindi credo che questo non è un problema a tutti.

Java Web Start in realtà memorizza tutte le applicazioni con impostazioni personalizzabili nel Pannello di controllo Java. Una volta che l'applicazione è in cache, l'applicazione è "installato" proprio come altre applicazioni. Sebbene esecuzione prima volta può essere lento, la seconda volta sarà veloce dovuto tecnica allocazione di memoria intelligente di JVM. Così inizia il tempo potrebbe essere un problema, ma un sacco di siti web (anche aziendale interna) vengono ora migrati a portale. Un portale web contiene normalmente un sacco di librerie inutilizzate per scopi di sviluppo a causa del fatto che il portale stesso non prevede che tipo di portlet sono costruiti e distribuiti su una pagina specifica. Pertanto, il download di una singola pagina del portale potrebbe consumare fino a MB e completare una pagina in più di 5 secondi; questa è solo una pagina e la cache aiuta fino al 30%, ma ci sono ancora un sacco di componenti / Javascript / CSS HTML necessari per scaricare ogni volta. Con questo, sono sicuro che Java Web Start è un vantaggio qui.

Java Web Start non scarica di nuovo se si è memorizzato nella cache fino a quando la copia sul server non viene aggiornato. Pertanto, se, ad esempio un software di project management come MS Project, è completato utilizzando SmartClient (simile a JWS), lo scambio di informazioni tra il client e il server sarebbe puramente dati senza presentazione come aggiornamento a piena pagina del browser. Anche con l'aiuto di Ajax, non elimina piena pagina di download del tutto. Inoltre, un sacco di aziende considerano l'Ajax di essere immaturo e non garantito ancora. È per questo che l'Ajax è un tema caldo nei circoli degli sviluppatori, ma non all'interno di software per le imprese ancora. Con questo in mente, JWS apps sicuramente hanno più vantaggi come ad esempio come le applicazioni JWS sono distribuite ed eseguite in sandbox, firmato, e hanno interfaccia grafica molto più interattivo.

Altri vantaggi includono lo sviluppo più veloce (più facile per eseguire il debug di codice e delle prestazioni), un'interfaccia utente reattiva (non richiede Comet Server per fornire funzionalità PUSH), e l'esecuzione più veloce (di sicuro, perché i computer client rende GUI senza traduzione come HTML / Javascript / CSS, e meno l'elaborazione dei dati).

Dopo tutti questi, non ho toccato la domanda ancora, perché JWS non è così famoso?

La mia opinione è che è lo stesso che il commento di Brian Knoblauch, è senza consapevolezza.

gente IT sono troppo attratti dalla campagna pubblicitaria di Tecnologie Web, Ajax PUSH, GWT, e tutte quelle parole d'ordine di loro orientamento verso il divertimento di utilizzare diverse tecnologie o per risolvere sfide tecniche, invece di quello che sta davvero lavorando per i clienti fanno.

Date un'occhiata a Citrix. Credo che Citrix è in realtà una grande idea. Citrix permette di costruire le proprie aziende agricole app dietro la scena. Ci sono tonnellate di aggiornamento e implementazione delle strategie si può andare per senza alcun impatto per l'esperienza del cliente. distribuzione Citrix è estremamente semplice, stabile e sicuro. Le aziende stanno ancora usando. Tuttavia, credo che JWS è anche meglio di Citrix. L'idea di JWS è quello di eseguire applicazioni su macchine client, invece di tonnellate di hosting di server farm in cui le macchine client sono in grado di eseguire queste applicazioni stesse. Ciò consente di risparmiare una società un sacco di soldi !!! Con JWS, team di sviluppo può ancora costruire logica di business e dati sul lato server. Tuttavia, senza l'unità di elaborazione web e lasciare che i computer client fanno il processo di rendering, riduce notevolmente la quantità di consumo della rete e la potenza di elaborazione del server.

Un altro esempio del perché JWS è un'idea sorprendente è BlackBerry MDS. applicazioni BlackBerry sono in realtà applicazioni Java translated da Javascript. Con lo studio MDS di BB, si utilizza lo strumento GUI per costruire BB applicazione GUI, codifica logica GUI in Javascript. Poi applicazioni sono poi tradotti e distribuiti su un server BES. Quindi il server BES distribuirà queste applicazioni a BB. Su ogni BB, si corre un sottile App Java con il rendering grafica e networking solo capacità. Ogni volta che l'applicazione richiede i dati, comunica con BES attraverso i servizi web di consumare i servizi da altri server. Non è questo solo versione JWS BB? E 'stato un grande successo.

Infine penso JWS non è popolare a causa di come Sun pubblicizza. BB mai pubblicizza quanto bene le loro applicazioni Java sono BB, credono che i clienti non sarà nemmeno si preoccupano di cosa si tratta. BB pubblicizza i vantaggi di utilizzare MDS per sviluppare applicazioni:. Veloce, risparmio sui costi, commercio di ritorno

Solo i miei, un po 'lungo, 2 centesimi ...:)

Altri suggerimenti

Un ostacolo importante per Java Web Start è probabilmente che è comunque necessario avere una JVM installato prima si può anche tentare di scaricare e avviare l'applicazione. Ognuno ha un browser. Non tutti hanno una JVM.

Modifica Da allora ho acquisito una certa esperienza hands-on webstart ed è ora possibile aggiungere questi due punti:

  • Il Deployment Toolkit sceneggiatura e la JVM modulare rilasciato da qualche parte intorno Java 1.6u10 che la prescrizione JVM meno problematico dal momento che può scaricare automaticamente una JVM e il nucleo API e avviare il programma di Wile scaricando il resto.
  • Web Start è seriamente bacato. Anche tra i Java 1.6 release c'era una che scaricato l'intera applicazione ogni volta, e un altro, che scaricato e poi non riuscita con un messaggio di errore oscura. Tutto sommato, non posso raccomandare davvero fare affidamento su un sistema così fragile.

Credo che sia soprattutto a causa di una mancanza di consapevolezza. Funziona molto bene. Piuttosto senza soluzione di continuità. App solo download, se è la prima volta, c'è stato un aggiornamento, o se l'utente finale ha eliminato la cache. Ottimo modo per distribuire desktop di conclamata apps che l'utente non dovrà preoccuparsi di aggiornare manualmente!

Il problema con Webstart è, che in realtà hanno a 'iniziare' qualcosa che non è affatto così veloce anche con una connessione veloce, mentre con una webapp si inserisce l'URL e l'applicazione è lì.

Anche un sacco di cose possono andare male con webstart. Forse l'utente previsto non ha i privilegi necessari, o la delega di webstart è stato configurato correttamente, o qualcosa è andato storto con dipendenze JRE o semplicemente non c'è Java installato, in primo luogo. Così, per la media John Doe in internet non è affatto piacevole.

In ambienti controllati come una società è una soluzione buona e facile, in molti casi.

Ho lavorato su un'applicazione JWS-schierato per alcuni anni su una base di utenti di un paio di migliaia di persone e le sue aggiornamenti automatici sono in realtà un dolore enorme.

In ogni aggiornamento, per qualche motivo decine di utenti di ottenere "bloccato in mezzo". Tutti si ottiene è la "classe non trovato" eccezione (se siete fortunati), o uninformative "in grado di lanciare" da JWS prima che arrivi anche al codice. Sembra che l'aggiornamento viene scaricato a metà. O, in altre parole, non scaricare e applicare l'aggiornamento atomicamente ed è povera di caching in modo che rilanciare l'applicazione della stessa URL non risolve nulla.

Non c'è modo per risolvere in altro modo che a svuotare la cache JWS o fornire un URL diverso (per esempio accoda ?dummyparam=jwssucks alla fine). Anche io come sviluppatore ha colpito a volte e non vedo un modo per aggirare.

Quando funziona, funziona. Ma troppo spesso non è così, e poi è un dolore enorme per voi e il vostro helpdesk. Non lo consiglio per le imprese o mission-critical uso.

Non è un problema molto grande e cioè che non permette di "avviare il programma immediatamente e quindi controllare e scaricare gli aggiornamenti in background" implementazioni, che è ciò che il comportamento di fatto di applicazioni stanno convergendo a.

La considero personalmente così grande un fastidio che stiamo attivamente alla ricerca di un'altra tecnologia che prevede che.

Da questi posti sembra che quando si utilizza Web Start, è importante fare una buona cura per il server. Il "grande dolore" di scaricare l'applicazione su ogni avvio può essere causato da errati di data e ora fornita dal server. Qui non l'applicazione, ma il server devono essere configurati per utilizzare la cache correttamente e non solo per disattivarlo. A proposito di inizio buggy, non sono più di tanto sicuro, ma mi sembra che anche questo può essere causato da connessione non affidabile.

Importante vantaggio di partenza Web è che funziona bene con OpenJDK sotto Linux. I clienti di alcuni sviluppatori felici utilizzare solo Windows, ma i miei clienti non lo fanno.

HTML e JavaScript, citato nella domanda iniziale, sono approcci più leggeri che funzionano bene con le attività più piccole, come pulsanti animati o anche tavoli interattivi. Java nicchia sembra in tutto molto più complessi compiti.

Java Web Start è una specie di un successore di applet Java e applet ha bruciato intorno al nuovo millennio. Ma, io continuo a pensare applet Java sono il modo migliore di GWT o Javascript inferno.

Java Web Start vs embedded Java Applet

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top