Java 7 | Putem descărca JAR-urile applet-urilor în paralel? (Programare, Java, Jar, Procesare Paralelă, Applet, Descărcați)

Manchanda. P a intrebat.
a intrebat.

Aplicația noastră web depinde în mare măsură de applet-urile Java. Pentru fiecare Applet Java avem mai multe fișiere jar semnate care conțin clasa applet și clasele dependente. Numărul acestor JAR-uri poate ajunge până la 70-80 pentru fiecare applet.

Dacă ne uităm la jurnalele consolei Java, se pare că fișierele JAR sunt descărcate și procesate unul câte unul, într-o manieră secvențială tipică. Acest lucru determină o întârziere în încărcarea unui applet atunci când memoria cache JRE este goală.

Pentru a depăși acest aspect, una dintre opțiunile pe care le luăm în considerare este descărcarea JAR-urilor în paralel. Următoarele Condiție de cursă în descărcarea paralelă a jars pentru applet-uri și web-start bug discută o problemă legată de descărcarea paralelă a JAR-urilor:

Așadar, întrebările mele sunt:

  • JRE descarcă JAR-urile pentru applet-uri în paralel în mod implicit, iar jurnalele din consola Java nu prezintă o imagine corectă?
  • Dacă cele de mai sus sunt corecte, atunci cum se poate valida dacă JAR-urile sunt descărcate în paralel?
  • În cazul în care cele de mai sus nu sunt corecte, cum putem descărca JAR-uri în paralel? cum ar fi o abordare de cod personalizat sau un indicator pentru JRE.

1 răspunsuri
Andrew Thompson

Poate ar putea fi realizat prin:

  1. Implementarea applet-ului utilizând Java Web Start.
  2. Specificând Jars ca lazy descărcare.
  3. Lansarea unui număr de Thread instanțe, adică.
  4. Utilizați DownloadService (sau serviciile aferente) ale API JNLP.

OTOH, bănuiesc că adevăratul blocaj este lățimea de bandă a conexiunii utilizatorului. 70-80 Jars pare enorm!

V-ați gândit să ofuscați codul? Denunț adesea capacitatea software-ului de ofuscare de a împiedica oamenii să fure codul (dacă sunt cu adevărat hotărâți, nimic nu îi va opri), dar făcând acest lucru se poate comprima adesea Jars standard cu încă 50-60%.

Un alt lucru pe care ar trebui să-l analizați este Pack-200, care ar putea oferi, de asemenea, beneficii în ceea ce privește scăderea dimensiunii descărcării necesare.

Comentarii

  • Vă mulțumim pentru răspunsul rapid. Permiteți-mi să explorez această opțiune pentru fezabilitate. În ceea ce privește numărul de fișiere jar, da, sunt de acord că este un număr mare, dar, din nou, aplicația noastră este o aplicație veche. Am luat în considerare ofuscarea pentru securitate, precum și micșorarea. Cu toate acestea, s-a renunțat la acest lucru deoarece ne îndepărtăm de Applets. Mulțumiri –  > Por Manchanda. P.
  • Am aruncat o privire rapidă la Ghidul de migrare. Aplicația noastră utilizează intensiv comunicarea de la java la js/js la java. Această caracteristică nu este susținută de JNLP. Fragmentul relevant este: O aplicație Java Web Start nu rulează în cadrul browserului web. Prin urmare, dacă applet-ul dvs. are vreo dependență de browser (de exemplu, comunicații Java to JavaScript / JavaScript to Java prin intermediul browserului), codul de comunicare nu va mai funcționa. API-urile care sunt afectate includ: –  > Por Manchanda. P.
  • Da, avem în vedere reducerea numărului de JAR-uri. Cu toate acestea, explorăm, de asemenea, posibilitatea de a descărca JAR-urile în paralel, astfel încât combinația celor două (număr mai mic de jars + descărcare în paralel) să ne ajute să creștem performanța Applet. Mulțumiri și salutări –  > Por Manchanda. P.