[Linux-Biella] Java e flame [Era: certificazione ISO 9001 Agenzia delle Entrate]

[Marco Ermini]

On 9/20/07, Emanuele Aina <em a nerd.ocracy.org> wrote:
[...]
> In questo hai ragione, HotSpot è molto veloce e, a parte le carenze
> della sintassi, le pecche del linguaggio, la vecchiaia delle istruzioni
> della VM,

Puoi magari fare qualche esempio? io di questi luoghi comuni ne ho
sentiti a bizzeffe... poi quando si vanno a vedere i dettagli si
sciolgono come neve al sole...


> la scarsità della libreria standard
>

Tralasciamo il fatto che dovresti darmi una definizione di "librerie
standard"... ti stai riferendo a Java Standard Edition? perché anche
la Micro e la Enterprise edition sono assolutamente "standard". E non
mi venire a dire che sono "scarse", in quale altro linguaggio hai le
feature, per esempio, degli Enterprise Java Beans imposti come
standard?

Vediamo piuttosto quelle di C++... certo sono fantastiche in
confronto! Guarda che parli con qualcuno che ha sviluppato in C++ per
anni, ed ha visto quale merda (scusate) si trova in certe
implementazioni delle STL. Non parliamo del fatto che
l'implementazione di STL di GNU fa piangere (ammesso che funzioni?...
che mi ricordi io era una pena usare la multiple inheritance in C++
visto che la gran parte del codice che usava template semplicemente
non compilava... spero sia migliorato nel frattempo...). Oppure
parliamo del fatto che nel mondo Microsoft semplicemente non si usano,
ma abbiamo ALTRE librerie (ATL)

Tutto questo in Java semplicemente NON ESISTE. Non esiste primo perché
Java, nel bene e nel male, è uno standard imposto da una azienda (sì
lo so che esistono vari modi di essere coinvolti in community
programs, etc. ma non credo tu possa mai inventarti qualcosa che
dispiaccia a Sun), sia per le caratteristiche intrinseche nel
linguaggio: grazie alla semplificazione rispetto al C++,
l'implementazione di certe features è molto più semplice. Per esempio,
se devo implementare una classe con ereditarietà multiple da altre due
o più classi, non devo impazzire con i template che ovviamente
andranno in ciampanelle con GCC, mi basta usare Class Interface (o
meglio ancora: siamo tutti figli di Object in Java... quindi se
funziona con Object...).

Comunque sono ben accetti esempi concreti di:

- linguaggi con "librerie standard" più ricche di Java
- esempi di "pecche" del linguaggio Java
- esempi di "carenze di sintassi" del linguaggio Java (è diverso dal
punto precedente, o è solo per allungare l'elenco?...)
- esempi di "vecchiaia di istruzioni della VM" (?!?)

C'è sempre da imparare e sono sicuro che mi sono perso un sacco di
cose... illuminami ti prego


> e le assurde interfacce
> grafiche,

Tipo? immagino non ti riferisca agli IDE come Eclipse, che è stato
"portato" per C++ tanto era migliore delle schifezze che in genere si
usano per quest'ultimo (a parte in ambiente Windows dove esistono
ottime IDE per C++).

Se ti riferisci a Swing o AWT, ti invito, anche qua, a fare degli
esempi di interfacce migliori che siano anche multipiattaforma e parti
della "libreria standard" come piace definirla a te, per qualsiasi
linguaggio (non soltanto C++, ma anche Python o quello che
preferisci).


> il grosso probema di Java sono gli sviluppatori e i loro
> nefasti prodotti: in generale trovo le librerie di terze parti scritte
> in Java sempre molto mal fatte.

Resta il fatto che hai bisogno INFINITAMENTE meno di librerie di terze
parti in Java, di quanto non ti servano in QUALSIASI altro linguaggio.


> Considerando anche che gcj può compilare Java in codice nativo, si
> eliminano del tutto le critiche relative alla VM.

Considerando che gcj ha delle grosse limitazioni e in effetti PERDI i
vantaggi insiti nell'usare una VM (la scalabilità, la possibilità di
profiling, il dynamic binding, e senza considerare che una parte molto
ampia e molto interessante delle librerie Java - come le Enterprise -
semplicemente non compila) vedo assai poco interessante gcj.


>  > Non parliamo poi di tutti quei programmi in C o C++ che hanno memory
>  > leak - se ne trovano ancora persino in software sotto osservazione
>  > continua a livello mondiale come le glibc o Apache... figurati negli
>  > altri. Problemi simili in Java non ne hai
>
> Nei sistemi con garbage collector ci possono comunque essere memleak,
> basta dimenticare dei riferimenti in un hash (ed è una cosa abbastanza
> comune).

Non capisco a cosa ti riferisca: fammi un esempio.

In Java non ho certo di questi problemi. Mi posso "dimenticare" quello
che voglio, il garbage collector è quello più sofisticato presente per
qualsiasi linguaggio di programmazione, e deallocherà il mio hash non
appena esco dallo scope in cui l'ho utilizzato.


> Il maggior beneficio dal punto di vista della sicurezza è invece la
> protezione dai buffer overflow, ma ci sono apposite librerie anche per
> C/C++.

Da un punto di vista della sicurezza questo è senz'altro un beneficio,
anche se in C++ ti tocca affidarti a librerie di terze parti o a
profiler. Ma è sicuramente un beneficio minore rispetto al fatto che
comunque, qualsiasi cosa tu crei (da una utility command line, a un
server TCP/IP, a una applicazione web...) creandolo in Java, hai delle
funzionalità che sono uno standard che è parte delle specifiche Sun ed
è utilizzato e riutilizzato, quindi stra-testato. Se un motore JSP o
J2EE ha un problema, lo si "patcha" per tutte le applicazioni del
mondo che lo usano. Se ti sei scritto il tuo application server in
C++, sei lasciato a soffrire da solo.


Cordiali saluti
-- 
Marco Ermini
root a human # mount -t life -o ro /dev/dna /genetic/research
http://www.markoer.org/ - https://www.linkedin.com/in/marcoermini
"Jesus saves... but Buddha makes incremental back-ups!"