Newsgroup: it.comp.java
Titolo: 5 buoni motivi...

Ciao a tutti,
premetto che mi occupo di sistemi e non ho grandissime esperienze di
programmazione, tolto qualche trascorso di C all'universita' e di
Visual Basic per esigenze di lavoro.
Del C mi ricordo una semantica "severa" che ho ritrovato in Java,
anche se con tutte le novita' del mondo OOP.
Il resto lo ricordo poco, tranne la portabilita' e la velocita'.
Del Visual Basic apprezzo tuttora la semplicita', l'immediatezza per
costruire applicazioni ad uso personale spendendo pochi minuti.
Non apprezzo invece la sintassi legata al passato e la frustrante e
complicata portabilita'. In esecuzione e' soddisfacente.
Il Java lo conosco poco. Da qualche mese piu' un corso intensivo.
Mi ricorda il C per la pulizia del codice e per l'uso rigoroso dei
tipi di dati.
Pero', anche se  capisco i motivi, sono molto molto *spaventato* dalla
lentezza e dalla pesantezza di un'applicazione, ma anche di un'applet,
scritta in Java.
Per una semplice finestra, JFrame ma anche JPanel, gestito con Swing
viene letteralmente divorata la piu' preziosa delle risorse di una
macchina: la memoria.
Ma anche i cicli di CPU si sprecano, temo.
Mi confermate il disagio?
Eventualmente, come aggirare il problema?
Grazie!
Sono attratto e spaventato allo stesso tempo...
Bye,
   Ricky

 Sono attratto e spaventato allo stesso tempo...
per quanto riguarda il post, anche io mi trovo nella stessa angosciosa [!
:-)  ] situazione di incertezza:
insomma, qualcuno mi saprebbe dire "perchè java"?
Cosa ha di meglio (in concreto e "sul campo": di apologie astratte, in libri
e articoli sull'argomento, ne ho lette abbastanza) rispetto ai linguaggi già
largamente utilizzati?
ciao

 Ma anche i cicli di CPU si sprecano, temo.
Ti ricordo che i cicli di CPU inutilizzati in un PC entry-level di oggi
(cioe` dai 500MHz in su) si sprecano *ugualmente* :-)
In altre parole, ormai non dovrebbero esserci grossi problemi per
eseguire le applicazioni client con GUI Swing.
E con i miglioramenti della versione 1.3, le applicazioni con GUI non
troppo complessa girano accettabilmente anche su un "obsoleto" Pentium
200.

eseguire le applicazioni client con GUI Swing.
...sul mio Duron 700 con 256 MB di RAM non ero piu' abituato a vedere
una finestra che viene disegnata... non in tempo reale! :-(
Su dei notebook dotati di 32 MB di RAM e di Celeron < 500 Mhz il
risultato e' sconfortante.
Per un informatico ci sono tutte le scusanti tecniche del mondo e la
sofferenza viene in parte mitigata.
Ma per un venditore che utilizza il portatile per gestire clienti e
prodotti potrebbe significare uno stato di malumore imbarazzante...
Se compilassi con JIT otterrei migliori risultati?
Bye,
   Ricky

 e di Celeron < 500 Mhz il risultato e' sconfortante.
A parte la RAM, secondo me c'e` qualcosa che non torna. Che JDK/JRE
hai usato? Il JIT e` di default con la versione 1.3.
Ciao,
 P.
+++ Boing Boom Tschak

hai usato? Il JIT e` di default con la versione 1.3.
L'ho installata solo oggi. Non sapevo nemmeno che contenesse gia' il
JIT.
Come lo uso? E qual e' l'eseguibile?
Bye,
   Ricky

 writes:
R> Del C mi ricordo una semantica "severa" che ho ritrovato in Java,
R> anche se con tutte le novita' del mondo OOP.
R> Il resto lo ricordo poco, 
R> tranne la portabilita' 
Ahem :) :). La portabilità del C si può avere a patto di usare SOLO la
libreria  standard del  linguaggio, non  fare alcuna  assunzione sulla
mappatura  in memoria  dei dati  (i.e. byte  ordering,  allineamento -
anche se questo  è controllabile in molti compilatori)  ed in generale
sull'architettura della macchina.
R> e la velocita'.
Lo hanno chiamato C perché ogni altro nome era troppo lento :) :) :)
R> Del Visual Basic apprezzo tuttora la semplicita', l'immediatezza per
R> costruire applicazioni ad uso personale spendendo pochi minuti.
Solo se produci  cose "previste". Quando devi fare  cose per terzi con
cose non previste...
R> Non apprezzo invece la sintassi legata al passato 
Orrida.
R> e la frustrante e
R> complicata portabilita'. 
Assente
R> Pero', anche se  capisco i motivi, sono molto molto *spaventato* dalla
R> lentezza e dalla pesantezza di un'applicazione, ma anche di un'applet,
R> scritta in Java.
"Tu  mette applet  in  browser,  tu chiede  guai!"  disse Orso  Fulvo,
parente di  Orso Grigio... Le JVM  dei browser sono  broken. Inoltre o
sono eseguite in un ambiente "noto per la sua leggerezza" (Netscape) o
sono eseguite in "ambiente ostile" (Inderned Exploder).
Mettere una applet in un browser  perché "E' di moda inderned, gu gu!"
è  stolto.   Ultimamente poi  vedo  che  si ritorna  all'accentramento
dell'esecuzione  dell'elaborazione,   lasciando  ai  client   solo  la
presentazione, sopratutto se di mezzo ci sono reti lente...
R> Per una semplice finestra, JFrame ma anche JPanel, gestito con Swing
R> viene letteralmente divorata la piu' preziosa delle risorse di una
R> macchina: la memoria. Ma anche i cicli di CPU si sprecano, temo.
R> Mi confermate il disagio?
Io avevo  un pop client  che mi  ero scritto in  VB... 70 k  di codice
compilato, 4 mega di impronta...
Swing è molto carino ma molto pesante in quanto è java puro, se usi il
vecchio   AWT  che   usa  i   controlli   di  sistema   vai  molto   +
veloce. Probabilmente trovando il modo di pilorare il double buffering
(tracci tutto in un buffer e spari a video quando tutti i tracciamenti
sono terminati)  dell'intera immagine della finestra  si otterrebbe un
buonissimo speedup.
Ho idea  che l'idea  originale mirasse verso  un ambiente  "alla LISP"
dove fai partire l'interprete (la  JVM) all'inizio e la stacchi quando
fai  logoff. Vedi la  sperimentazione delle  JavaStation o  l'idea del
Network Computer.  L'uso a "lancia applicazione, lancia  nuova jvm" mi
sa che è  penalizzante. D'altro canto non c'è  una javashell, o almeno
una nota.
\begin{echelon}
Ft. Meade Semtex Ortega North Korea $400 million in gold bullion
assassination kibo class struggle Rule Psix KGB supercomputer
explosion BATF CIA nuclear
\end{echelon}
\begin{avviso}
 
Attenzione: Leggersi lo header riguardo al mio e-mail!
Warning: read header for infos about my e-mail.
\end{avviso}
+----------------------------------------------------------------+
| Gian Uberto Lauri * "So, are you working on fixing that bug    |
| 
sa...@eng.it
      *  *now* or leaving it until later ?" - YES  |
+----------------------------------------------------------------+

 presentazione, sopratutto se di mezzo ci sono reti lente...
Le Applet stanno facendo una brutta fine per vari motivi: sono stata la
prima "manifestazione" di Java quando il linguaggio era ancora immaturo;
soprattutto sono rimaste coinvolte nella "guerra dei browser" che per
una tecnologia in crescita legata al browser stesso (purtroppo a causa
delle VM proprietarie) ha rappresentato un grosso intralcio. Flash,
essendo un plug-in separato dalla distribuzione del browser, non ha
avuto di questi problemi.
Cio` non toglie che il concetto di applicativo "mobile" distribuito su
richiesta sul client non sia un concetto valido. Anzi, sarebbe ora che
ci rendesse conto di quanto sia rozza l'architettura attuale della
maggior parte delle web-app, basate interamente sul browser. Rozza sia
perche` e` sbagliato centralizzare completamente l'elaborazione (che
significa continue richieste al server anche solo per visualizzare in
modo diverso i dati gia` trasmesso una volta..) sia perche` i browser
sono prodotti ancora rozzi (l'HTML standard secondo il w3c non lo usa
nessuno, la teorizzata separazione tra struttura e presentazione
praticamente non esiste, non parliamo poi dei vari *script..) - anche se
quest'ultimo aspetto riguarda per lo piu` gli sviluppatori e non gli
utenti.
Tanto per fare un esempio, sarei molto piu` contento se per
l'home-banking potessi usare un applet Java con interfaccia Swing
piuttosto che il solo browser.
Insomma, a volte mi chiedo perche` si cantino tanto le lodi delle nuove
tecnologie. Secondo me nei fatti siamo ancora molto indietro :-)

 Come lo uso? E qual e' l'eseguibile?
Non devi fare nulla in particolare. Prova 
p.es
. a usare un po' la demo
di Swing, su un PC a 500MHz avvertirai un po' di differenza con
un'applicazione nativa, ma non cosi' tanto da essere sgradevole.

> presentazione, sopratutto se di mezzo ci sono reti lente...
PC> Le Applet stanno facendo una brutta fine per vari motivi: sono stata la
PC> prima "manifestazione" di Java quando il linguaggio era ancora immaturo;
E sono state utilizzate per fare cose banali.
PC> Cio` non toglie che il concetto di applicativo "mobile" distribuito su
PC> richiesta sul client non sia un concetto valido.
Tra  la teoria e  la pratica  c'è di  mezzo la  velocità del  mezzo di
distribuzione.
PC> e` sbagliato centralizzare completamente l'elaborazione (che
PC> significa continue richieste al server anche solo per visualizzare in
PC> modo diverso i dati gia` trasmesso una volta..)
Ni. In  applicazioni come l'home banking  è indispensabile l'integrità
del codice  che con  un applet  non puoi garantire  in quanto  per sua
natura un'applet è decompilabile e modificabile.
PC> Insomma, a volte mi chiedo perche` si cantino tanto le lodi delle nuove
PC> tecnologie. Secondo me nei fatti siamo ancora molto indietro :-)
Siamo in Namibia per quello...
\begin{echelon}
Marxist assassination nuclear Mossad fissionable Soviet plutonium $400
million in gold bullion jihad explosion KGB Albanian security kibo
Panama


> Su dei notebook dotati di 32 MB di RAM
PC> ..ci metterei al massimo Windows 3.11 :-)
Linux  senza Gnome  e con  un  Window Manager  leggero come  BlackBox,
niente demoni inutili e possibilmente con kernel monolitico.
\begin{echelon}
Clinton spy Peking CIA Treasury fissionable nuclear Ortega Albanian
bomb radar Saddam Hussein KGB Delta Force smuggle


 natura un'applet è decompilabile e modificabile.
Uhm, pero` non vedo dove potrebbe essere il problema, voglio dire
nell'Applet ci starebbe la GUI per la parte relativa alle transazioni, e
qualche applicativo per consultare i movimenti, l'andamento dei miei
titoli.. non vedo come la decompilazione del codice potrebbe essere
sfruttata per scopi maliziosi. Tanto, in ogni caso, una convalida delle
operazioni deve essere effettuata anche a livello di server.

e come si fa a compilare in codice nativo?
ps. come uso il JIT?
rhymes
rhy...@tiscalinet.it


                                                               ^^^^^^^^^^^^^^^^^
Ottenere codice nativo invece e` tutt'altra storia e richiede dei tool
esterni al jdk. Ti consiglio di cercare fra i vecchi post del ng, xche`
se ne e` parlato molto a riguardo.
Spero di essere stato chiaro.
Maggiori info le trovi sicuramente nella documentazione allegata al jdk.
-- 
Ciao,  |  I play Russian roulette everyday, a man's sport,
Matteo |  With a bullet called life, yeah called life, (SUGAR)

 writes:
PC> Uhm, pero` non vedo dove potrebbe essere il problema, voglio dire
PC> nell'Applet ci starebbe la GUI per la parte relativa alle transazioni, e
PC> qualche applicativo per consultare i movimenti, l'andamento dei miei
PC> titoli.. 
Beh,  se un'applet  avesse solo  queste funzioni  allora  l'applet non
serve, basta  molto probabilmente il meccanismo dei  form, di benefici
ne  vedo pochini:  il sort  dei dati  e il  rendering dei  grafici dei
titoli.
\begin{echelon}
Treasury NSA munitions SEAL Team 6 Marxist SDI domestic disruption
Kennedy explosion Uzi class struggle Mossad $400 million in gold
bullion FSF Albanian


sono eseguite in "ambiente ostile" (Inderned Exploder).
No beh, l'idea era di creare un'applicazione, niente applet.
Forse la voglia di un'interfaccia accattivante, leggi Swing, e' troppo
penalizzante per dei portatili con poca memoria e dei "vecchi"
Celeron.
Bye,
   Ricky


http://www.pabasoftware.com

 largamente utilizzati?
La portabilita' e la possibilita' di fare le applet.
Se per te queste non e' importante, ti dico subito che non hai
assolutamente nessun motivo per usare Java.
Se cerchi un linguaggio ad oggetti c'e' C++, se C++ e' troppo difficile
usa Delphi o aspetta C#. Se cerchi un linguaggio facile e veloce c'e'
Visual Basic. Sul lato server va un po' meglio, ma anche li' se tutti i
tuoi server side girano su un solo OS perche' non usare ASP o PHP o il
grande Perl?
A mio parere gli unici motivi per usare Java sono portabilita' e applet.
Poi Java offre una serie di plus, come quello di essere OO (per me e' un
plus), di essere + facile e sicuro di C++ (vedi garbage collection,
puntatori impliciti, obbligo di usare le eccezioni, libreria di classi
immensa).
Java e' inoltre l'unico linguaggio con il quale puoi scrivere
un'interfaccia utente che girera' senza modifiche su Win/MacOS/Unix vari
e questo puo' essere importantissimo nella programmazione distribuita.
Certo, tutto questo si paga con una incredibile lentezza, ma quale altro
linguaggio ti offre queste possibilita'?
Gia' il porting di un programma C/C++ e' complesso, diventa una
riscrittura da capo quando c'e' anche una interfaccia grafica.
Il punto e' che Java ha un'immagine legata a Internet per via delle
applet, e quindi e' di moda. La verita' e' che Java e' un linguaggio
estremamente potente che offre come tutti i linguaggi alcuni vantaggi e
alcuni svantaggi.
Nella scelta del linguaggio da utilizzare per un'applicazione, vanno
prese in considerazione le varie alternative e scelta quella che
risponde meglio ai requisiti, in termini di facilita'/velocita' di
sviluppo, prestazioni, sicurezza, estendibilita'... non e' affatto detto
che Java sia la scelta migliore!
Quindi non c'e' un "perche' Java", o almeno per ogni perche' Java c'e'
un "Perche' NON Java".
Cio' detto, Java resta un bellissimo linguaggio, e siccome i
programmatori si divertono a lavorare con un linguaggio bello puo' darsi
che gli salti in testa di usarlo anche quando ci sarebbe una scelta
oggettivamente migliore.


> largamente utilizzati?
TP> La portabilita' e la possibilita' di fare le applet.
TP> Se per te queste non e' importante, ti dico subito che non hai
TP> assolutamente nessun motivo per usare Java.
Hmmm.... Va be che a me Java piace perché è bello...
TP> Se cerchi un linguaggio ad oggetti c'e' C++, se C++ e' troppo difficile
TP> usa Delphi o aspetta C#. Se cerchi un linguaggio facile e veloce c'e'
TP> Visual Basic. Sul lato server va un po' meglio, ma anche li' se tutti i
TP> tuoi server side girano su un solo OS perche' non usare ASP o PHP o il
TP> grande Perl?
C# credo che soffrirà della stessa 'carenza' che ha Windows rispetto a
Unix...
TP> A mio parere gli unici motivi per usare Java sono portabilita' e applet.
Lascerei stare le applet...
TP> Poi Java offre una serie di plus, come quello di essere OO (per me e' un
TP> plus), di essere + facile e sicuro di C++ (vedi garbage collection,
TP> puntatori impliciti, obbligo di usare le eccezioni, libreria di classi
TP> immensa).
Bing! Il signore ha indovinato :) :) :) :) :)
Fuori dalle  pagliacciate, hai tirato fuori un'argomento  non da poco,
la sicurezza. Tu  pensa a creare un  server o meglio a un  CGI. Se non
hai il programmatore C (C++) sensibile all'argomento questo, visto che
deve  leggere  da stdin  dirà  "che cavolo,  alloco  un  vettore di  X
caratteri sullo stack e uso  la gets(), tanto nessuno manderà un input
cosi gross<buffer overrun>"...
Il   venerabile  Perl   può   presentare  problemi   analoghi  se   il
programmatore  non è  più  che attento,  anche  perché é  in grado  di
prendere in input del codice e farlo eseguire...
In java al più credo ti  buttino giù l'applicazione o se va tanto male
la JVM... Come danno è minore.
TP> La verita' e' che Java e' un linguaggio
TP> estremamente potente che offre come tutti i linguaggi alcuni vantaggi e
TP> alcuni svantaggi.
Concordo al 100%
\begin{echelon}
genetic SEAL Team 6 Nazi Kennedy smuggle KGB terrorist class struggle
nuclear colonel NSA South Africa bomb counter-intelligence
arrangements
