Newsgroup: it.comp.java
Titolo: AIUTO "Accademico" (o filosofico?): SVANTAGGI DI JAVA

Non è un problema vero e proprio, ma vorrei raccogliere opinioni: Quali sono
i difetti di Java?
Lo scopo è quello di aggiungere, nel mio lavoro di tesi (che ha come oggetto
una interfaccia costruita in Java), un paragrafino (anke solo di 1
paginetta) con "Critiche rivolte a Java" - che finirebbe dopo gli
innumerevoli suoi vantaggi (^_^).
Magari poi vi metto nei ringraziamenti ;-)
G.in.A.
M'b

 innumerevoli suoi vantaggi (^_^).
Di che tesi si tratta?
-- 
   [   [  [ JJ ]  ]   ]  | Proponi la tua professionalita' su
                         | 
http://www.siforge.org

 Lo scopo č quello di aggiungere, nel mio lavoro di tesi (che ha come





 innumerevoli suoi vantaggi (^_^).
Moltissimo dipende dal punto di vista della tua tesi: per dire, parli di 
teoria dei linguaggi di programmazione, oppure di applicabilita' concreta 
(e magari commerciale)? L'identica caratteristica puo' essere considerata 
vantaggio o svantaggio nei due contesti. Ad esempio, prendi le recenti 
estensioni Microsoft a C++ per farlo funzionare in .NET.. ;-)
Dal primo punto di vista, Java e', come ogni linguaggio, un compromesso tra 
certi aspetti teorici (magari in se conflittuali) e le necessita' pratiche 
e il contesto storico in cui e' nato. L'esempio tipico che il C++ista di 
fara' e' la mancanza di tipi generici.
Come sempre in questi casi, l'ottica "vantaggio/svantaggio" ha poco senso: 
l'essenziale e' capire perche' _se_ scelte di design sono state fatte (o 
sono semplicemente "capitate" ;-), e perche', il che crea dei limiti 
definiti per l'ambito di applicabilita' teorico del linguaggio; o meglio, 
fornisce dati su quando (e quanto) sia o meno vantaggioso usarlo in un 
certo ambito di applicabilita'.
La _stessa_ caratteristica puo' essere vista indifferentemente come 
vantaggio o svantaggio, a questo livello - dato che l'idea stessa che un 
linguaggio abbia quante piu' features possibili o supporti vari paradigmi 
di programmazione non e' di per se' assoluta. 
Anche cose apparentemente iper-assodate, tipo l'esigenza di un solido type 
system statico in realta' non lo sono - domani ti esce il linguaggio 
PincoPallo che non ce l'ha e la cosa viene presentata come una 
"facilitazione per l'utente" (sic, nessuno ricorda XSLT? :-)
Dal punto di vista pratico/commerciale, per applicazioni comuni, l'unico 
svantaggio di Java e' che, per scelta Microsoft, l'integrazione con Windows 
e' di gran lunga meno facile di quanto potrebbe. E Windows, praticamente e 
commercialmente, pesa. :)
Inoltre, i toolkit GUI standard tendono ad essere o brutti (AWT) o lentucci 
(Swing). La SWT di IBM/Eclipse da questo punto di vista e' moltissimo 
promettente - ma appunto e' un pacchetto "esterno".
Poi e' chiaro che dovessi fare number crunching, io *non* userei Java.. ;-)
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

 ha scritto nel messaggio
news:Xns92BE679C5385Dcr...@130.133.1.4...



Questa e' una "scelta" nell'implementazione del run-time di Java.
In C++ l'implementazione dei template e' efficiente perche' il tutto e'
risolto direttamente dal Parser del compilatore che "sostituisce
staticamente" il tipo effettivo con quello generico direttamente sull'albero
di sintassi astratta.
Questo pero' ha un difetto notevole: non si possono creare delle librerie
che forniscono classi generiche facendo uso di template in quanto per
ricompilare il tutto sarebbe necessario fornire anche il codice sorgente dei
template stessi.
I "template" di Java (scusate la forzatura), che fanno uso della classe
Object, risolvono il tutto a run-time con dei cast ovviamente costosi, ma
permettono di scrivere delle librerie generiche (es. le Collection), e
distribuire quindi solo i file .class
Ciao

innumerevoli suoi vantaggi (^_^).
A parer mio una delle grosse mancanze di java sono i template. Questo
ti obbilga a degli orribili cast.
Comunque un mio amico ha mandato a sun un progetto per implementarli
nel linguaggio e a quanto pare e' piaciuto perche' l'hanno chiamato
dalla America chiedendogli di andare in sun a realizzare il progetto.
Parte tra poco e vedremo come va a finire.
Questo dimostra comunque che la mancanza dei template e' un problema
sentito dagli stessi progettisti del linguaggio.
L'altro problema che mi intristisce e' di carattere commerciale e si
chiama C#. Fra poco la MS comincera' a spingere e a togliere supporto
Java dai suoi prodotti (vedi RMI da IE). Chi vivra' vedra'.
--
Ciao.
Mario Maroncelli
mar...@mclink.it

: Svantaggi:
: 
: E' un linguaggio tipizzato, ma non avendo i template ha una implementazione 
: carente delle Collections (che ti costringono continunamente a fare cast, che 
: ricorda, costano a Runtime un typecheck).
: 
io *voglio* un linguaggio tipizzato. non amo i linguaggi non
tipizzati perche' il compilatore non puo' fare controlli sulle
chiamate ai metodi (puo' essere fatto solo a runtime).
in java (e c# ed altri) il compilatore mi fa risparmiare tempo.
ps: i template (generics) saranno aggiunti nel jdk 1.5
: La reflection e' piu' lenta che in un linguaggio dinamico.
:
forse, comunque nel jdk 1.4 e' stata velocizzata moltissimo.
 
: Ha i tipi primitivi per cui non e' ad oggetti puro (=poco uniforme).
:
vero.
 
: I Bean si basano su qualche convenzione nominale per trovare le proprieta' 
: (setXX/getXX): questo non e' "male" di per se' ma non e' possibile cambiare 
: questa convenzione.
:
e allora? questa convenzione ha dimostrato di essere conveniente, per cui
perche' dovremmo cambiarla?
 
: Purtroppo non e' molto veloce, in parte per il linking dinamico a runtime, in 
: parte perche' il javac non e' un ottimo compilatore, in parte per come e' 
: pensata l'ereditarieta'.
:
non saranno molto veloci le swing, ma il resto delle classi non sono poi
cosi' lente come sostieni. e' vero che il javac non e' un gran compilatore
ma ci pensa l'hotspot a ottimizzare il codice. non e' un gran male, anche
se effettivamente potrebbe essere meglio...
la storia del "come e' pensata l'ereditarieta'" potresti spiegarla meglio?
 
: Il linguaggio tende ad aumentare in modo esagerato il numero di classi: per es 
: per una gui con 4 bottoni con 4 eventi, hai bisogno spesso di 4-5 classi di 
: appoggio.
:
non mi sembra poi cosi' grave, c'e' di peggio...
 
: Come e' ovvio, scarsa integrazione con il S.O. (questa e' una caratteristica 
: piu' che un difetto perche' puo' rivelarsi un vantaggio...)
:
vero, ma posso sempre farmi una funzione in c usando jni.
 
: Le versioni sono spesso incompatibili tra loro (prova a ricompilare un applet 
: per jdk 1.0.2 con il jdk1.4...) e la  specifica del linguaggio non e' ANSI ma e' 
: POSSEDUTA dalla Sun.
:
il jdk 1.0.2 e' molto diverso dalle versioni successive, estremamente migliorate.
molti metodi dell'1.0.2 sono deprecati, ed inoltre e' difficile trovare codice
per 1.0.2 ancora in uso. detto questo hai ragione, ci potrebbero essere problemi
di compilazione, ma in pratica non capitano mai. ormai oggigiorno tutto il
codice e' scritto per 1.3.1 e successivi.
per quanto riguarda il fatto che la specifica non sia ansi... meglio cosi',
altrimenti a quest'ora avremmo uno standard de facto, quella della ms, non
quello della sun (e naturalmente i due non sarebbero compatibili, per ovvie
ragioni). invece non essendo uno standard ufficiale la ms non ha potuto far
molti danni (a parte crearsi il suo java personale: c#)
ciao!

 Parte tra poco e vedremo come va a finire.
beh, con tutto il rispetto del tuo amico, non ci allarghiamo: ad aiutare 
si, a realizzarlo mi sembra un po' troppo. Il progetto e' partito da un 
bel po'. (e c'erano gia' delle implementazioni al di fuori del linguaggio)
Personalmente, non sento un gran bisogno dei template (in passato 
credevo di si).
uL


I template di Java, quelli veri del jdk1.5(dovevano arrivare nell'1.4 o 
sbaglio?) non creeranno questo problema; non ho trovato le specifiche, 
ma penso che: innanzitutto il templating sarà semplicemente da oggetto a 
oggetto(non potrò avere un parametro del template che diventa int, ma 
solo Integer), spero non ci siano member function template, ovvero che 
il parametro del template venga passato solo al costruttore e che non ci 
siano metodi templatizzabili(per quelli va benissimo il polimorfismo, 
dato che comunque il metodo dovrà chiamare qualcosa del parametro a tipo 
variabile, anche se un metod(qualcosa) i vari qualcosa potrebbero avere 
solo object in comune ma il metodo potrebbe fare overloading, ad esempio 
gli passo una stringa con un percorso o un oggetto file con quel 
percorso); infine il template non farà altro che automatizzare i cast in 
uscita e dire che in una collection entrano solo alcuni e non altri(con 
controllo compile-time e non run-time, che è il vantaggio principale). 
Tra l'altro in Java, dato che il templating va fatto tra tipi in fondo 
identici(sono sempre 4/8 byte di puntatori), instanziare un template non 
costerà nulla, così non ci sarà bisogno dei .class; invece in C++ 
instanziare un template costa perché il compilatore deve sapere il tipo 
effettivo prima di creare l'instanza(cioè da vector<t> creare 
vector<int>) deve sapere ad esempio quanto occupa int, e ciò rende quasi 
impossibile mettere solo nel .o il codice, dato che per istanziarlo deve 
essere profondamente modificato e riottimizzato(bisogna dire che lo 
standard prevede che un template possa essere compilato e perlomeno il 
compilatore comau implementa o quasi lo standard).
Riguardo invece i metodi getter/setter, il problema in realtà è che se 
tu usi un campo e vuoi mettere a un certo punto una proprietà, il 
cambiamento non è trasparente: devi modificare tutto il sorgente che la 
usa; invece ci vorrebbero le property dentro il linguaggio(secondo me 
renderebbe + veloci i javaBean, riducendo la complessità della 
reflection necessaria).
 > Ciao
 >
 >
 >
-- 
Paolo Giarrusso, Blaisorblade
Togliere solo REMOVEONLYTHIS per rispondere
Linux Kernel 2.4.19 on an i686
Firma "made in Vim"



Scusa... la parte del mio amico era solo un commento e non mi sono
dilungato a spiegare.
Il progetto nasce da una ricerca universitaria dove il mio amico in
realta' ha contribuito molto poco e in fase di realizzazione della sua
tesi. Il tutto poi e' stato mandato alla sun che ha risposto dicendo
"interessante... venite a spiegarcelo" e quindi lui parte. Chiaramente
sun avra' gia' le sue idee ma probabilmente prima di rendere tutto
definitivo sentira' anche questo nuovo parere.
Prendi il tutto come un rumors. Se vuoi maggiori notizie contattami in
email.
