Cosa ne pensate del linguaggio JAVA?

[dimaios]

A parte i dettagli sulla semantica del linguaggio ed i paradigmi impiegati su cui si può discutere all'infinito direi che Java è stato concepito molto tempo fa e per l'epoca ( 1995 ) rappresentava una novità interessantissima.
Molte delle idee sono state successivamente copiate in altri linguaggi/framework.
Il problema non è se Java sia bello o brutto ma cosa ci devo fare.

Se dovessi iniziare lo sviluppo oggi, a meno che non si tratti di una applicazione enterprise con necessità di retro compatibilità ( es. Applicazioni in ambito bancario assicurativo ecc.) lo eviterei sicuramente per due motivi.

1. Prestazioni mediocri in termini di velocità.
2. Bassa produttività se confrontato con altre tecnologie.

L'impiego di .NET in combinazione con il C# fornisce un ambiente favorevole per la prototipizzazione rapida.

Il C++ rimane sempre e comunque il top, il padre di tutti i linguaggi di programmazione, un obbligo per chi vuole fare il programmatore di professione.
Attualmente sviluppo molto in C++ 11 e leggo le specifiche del C++ 14.... impressionante anche se il grosso salto c'è stato con l'introduzione del C++ 11.
Non parliamo poi della STL .... veramente eccellente ... un lavoro di altissima qualità in termini di ingegneria del software.

Tools? Visual Studio 2012 professional e quando passerò al C++ 14 sicuramente il Visual Studio 2013.
Ho provato diversi IDE e alla fine non ho dubbi ... nessuno è perfetto ma tra quelli che ho impiegato è il meno imperfetto.
Capisco che parlare bene di un prodotto Microsoft non sia di moda ma a me non interessa .... a mio avviso è un grandissimo prodotto e non sono assolutamente fanatico dell'azienda di Redmond.

[TardoFreak]

Risposte molto interessanti!

Ora vorrei provare a fare un giochino.

Supponiamo che domani immettessero nel mercato un processore quad (o 256 ) core progettato apposta per eseguire bytecode di Java con tutti gli annessi e connessi in modo da rendere l' esecuzione dei programmi velocissima, al pari del C++ se non più veloce, il giudizio cambierebbe?

[fairyvilje]

Supponiamo che domani immettessero nel mercato un processore quad (o 256 ) core progettato apposta per eseguire bytecode di Java con tutti gli annessi e connessi in modo da rendere l' esecuzione dei programmi velocissima, al pari del C++ se non più veloce, il giudizio cambierebbe?

Premesso che la java virtual machine avrebbe un'architettura abbastanza limitata se fosse un processore reale come si può leggere da qui. Per quello che mi rirguarda il giudizio dato non cambierebbe affatto. Le mie erano critiche specialmente al linguaggio e poi se vogliamo anche al resto, ma solo in secondo luogo sulla velocità di esecuzione del codice. Java può essere compilato per una piattaforma nativa ad ogni modo ma l'esecuzione rimane molto più lenta dello stesso programma compilato in C++. Il garbage collector è uno dei molti motivi

[fairyvilje]

Mi incuriosisce il fatto che il Java o si odi o si ami, in entrambi i casi alla follia.

Il fatto è che come già detto java è un linguaggio che di base è più sicuro per il programmatore. Chi ci programma si trova di fronte ad un ambiente con un potente sistema di eccezioni sistematicamente disegnato. Ogni operazione illegale nella libreria standard (ma anche nella jvm stessa, se non sbaglio le eccezioni esistono nativamente) ne genera una una, quindi si ha sempre la sicurezza che un errore non possa passare inosservato e vada risolto o esplicitamente ignorato nel codice per proseguire.
In C++ il sistema delle eccezioni per quanto esistente e ben sviluppato è poco usato nelle librerie standard non solo perché appesantirebbe l'esecuzione runtime del codice ma aggiungerebbe una verbosità non indifferente.
Nonostante questo il C++ permette comunque di scrivere le proprie eccezioni, di lanciarle e gestirle in modo opportuno. Riassumendo questo punto l'idea è questa. Immaginiamo che stiamo cercando di nutrire un unicorno rosa. Ecco due possibili approcci nei due linguaggi

JAVA evitando le eccezioni se possibile

Codice: Seleziona tutto

if(MyLittleFarm.hasMagicPinkUnicorn()){
  MyLittleFarm.feedMagicPinkUnicorn(150);
}
else{
  System.out.print("My magic pink unicorn is gone away...");
}


JAVA

Codice: Seleziona tutto

try{
   MyLittleFarm.feedMagicPinkUnicorn(150);
}
catch(OhNoMyMagicPinkUncornIsGoneException e){
  System.out.print("My magic pink unicorn is gone away...");
}


C++

Codice: Seleziona tutto

if(!MyLittleFarm.feedUnicorn(150)){
  std::cout<<"My magic pink unicorn is gone away...";
}


C++ with exceptions

Codice: Seleziona tutto

try{
   MyLittleFarm.feedUnicorn(150);
}
catch(BadUnicornException& e){
  if(e.isGone())System.out.print("My magic pink unicorn is gone away...");
}


Ironia a parte Java cerca di utilizzare eccezioni dal nome molto verboso che spiega nei dettagli le caratteristiche del problema. In C++ se proprio necessarie alle volte nemmeno si usano oggetti ma si lanciano interi presi da enumerazioni .
E ad ogni modo in C++ spesso e volentieri si preferisce allegare il risultato di una certa operazione al return della stessa, magari sotto forma di bool. In java questo si tende a fare solo nei membri chiamati isXXX o hasXXX.
Sono due approcci diversi e solitamente per i neofiti si preferisce quello del java perché evidenzia ed esplicita i problemi a scapito delle prestazioni e della verbosità del codice. Le eccezioni in java infatti sono oggetti e come tali vanno costuite, usate ed eliminate.

Prosegue...

[c1b8]

E ad ogni modo in C++ spesso e volentieri si preferisce allegare il risultato di una certa operazione al return della stessa, magari sotto forma di bool. In java questo si tende a fare solo nei membri chiamati isXXX o hasXXX.
Sono due approcci diversi e solitamente per i neofiti si preferisce quello del java perché evidenzia ed esplicita i problemi a scapito delle prestazioni e della verbosità del codice. Le eccezioni in java infatti sono oggetti e come tali vanno costuite, usate ed eliminate.

Perdonami ma questa non l'ho capita...

Alcuni dicono che Java non sia un linguaggio ad oggetti "puro" perché consente ancora l'utizzo di tipi base come int, byte boolean ecc. non obbligando all'utilizzo di oggetti (Integer, Boolean, ecc.), capisco male o tu dici che sia preferibile non utilizzare oggetti ma tipi base?

[fairyvilje]

Un'altra bella storia è quella del ciclo di vita degli oggetti. Ed uno dei motivi che fa preferire java o un linguaggio come il C++.
Semplificando si può dire che esistono due tipi di oggetti: quelli statici ovvero noti al tempo della compilazione e quelli dinamici che vanno costruiti run-time.

I primi hanno un ciclo di vita estremamente semplice in quanto possiedono uno scope esplicito ovvero un campo di validità noto al compilatore. Sono tipicamente salvati riservando spazio sullo stack, vengono costruiti dal compilatore prima di eseguire il codice nello scope e distrutti una volta usciti dallo stesso. Non fanno scherzi e sono dei bravi oggetti.
L'alternativa sono gli oggetti dinamici. Quando l'esistenza di un oggetto (o la decisione del suo tipo) dipende da informazioni che deve fornire l'utente al momento dell'esecuzione di un certa istanza del programma il compilatore non è in grado di conoscere a priori la sua esistenza o meno. Si sfrutta quindi un meccanismo di creazione e distruzione dinamica degli oggetti, gestito dal sistema run-time del programma.

Ora C++ e Java divergono nel modo in cui gli oggetti dinamici vengono usati. C++ usa gli operatori new e delete, mentre Java pur mantenendo l'operatore new per la costruzione di un oggetto, rimanda la sua distruzione ad un meccanismo automatico chiamato garbage collection, letteralmente "raccolta della spazzatura" XD. Il metodo del C++ è deterministico riguardo il ciclo di vita di un oggetto. Vuol dire che a patto di non scrivere il codice in modo errato, posso dire quando si stia costruendo e quando si stia distruggendo.
La garbage collection invece è un sistema non deterministico, posso dire quando vado a costruirlo ma non so quando verrà distrutto. Ai fini del programmatore l'oggetto cessa di esistere quando nessuna referenza memorizza più il suo indirizzo, ma di fatto lui resterà in memoria fino a quando il sistema di pulizia non deciderà che sia necessario fare qualcosa. Questo implica che il C++ potrà avere costruttori e distruttori espliciti, mentre java solo il costruttore.

OGGETTI IN C++

Codice: Seleziona tutto

struct TestObject{
  TestObject(){std::cout<<"Costruzione";}
  ~TestObject(){std::cout<<"Distruzione";}
  void sayHello(){std::cout<<"Ciao";}
};

//...
{ // Le parentesi graffe definiscono uno scope
TestObject temp;
temp.sayHello();
}
//...


Questo codice incompleto entrando nello scope visualizzerà qualcosa del tipo

Codice: Seleziona tutto

CostruzioneCiaoDistruzione

La vita di temp è completamente legata ad uno spazio deterministico.
Ora java quasi non usa oggetti statici quindi è impossibile fare un confronto. Concentriamoci sugli oggetti dinamici.

OGGETTI DINAMICI IN C++

Codice: Seleziona tutto

struct TestObject{
  TestObject(){std::cout<<"Costruzione";}
  ~TestObject(){std::cout<<"Distruzione";}
  void sayHello(){std::cout<<"Ciao";}
};

//...
{ // Le parentesi graffe definiscono uno scope
TestObject *temp=new TestObject();
temp->sayHello();
delete temp;
}
//...


Questo codice incompleto entrando nello scope visualizzerà qualcosa del tipo

Codice: Seleziona tutto

CostruzioneCiaoDistruzione

Nonostante il risultato sia uguale sotto cambia tutto. "temp" è ora un puntatore di tipo TestObject. E' new che costruisce realmente l'oggetto e alla fine si limita a restituire un indirizzo che verrà memorizzato in temp. Quindi temp non è più l'oggetto ma un suo nome di riferimento. Uscendo dallo scope il compilatore saprà che deve eliminare solo il puntatore temp e non l'oggetto puntato che va rimosso esplicitamente dal delete. Tutto questo è tremendamente pericoloso e potente. Non voglio dilungarmi sulla questione, ce ne sarebbe tanto da dire su oggetti zombie e dintorni. Pongo giusto qualche domanda per la riflessione.
Cosa succede se non eseguo il delete?
Cosa succede se copio il riferimento anche su un altro puntatore di scope più ampio, eseguo un delete sul primo e continuo ad usare l'altro puntatore come se niente fosse?
Queste domande hanno risposte spaventosissime ed è il motivo per cui (come al solito) java ha preferito non implementare una funzionalità piuttosto che risolverne i problemi. Quindi java non usa i puntatori. Dal momento che lasciare il ciclo di vita in mano al programmatore è rischioso java decide di farsene carico come meglio può. Al posto dei puntatori usa le referenze non costanti, elimina l'artimentica dei puntatori su di esse, e si assume il controllo della distruzione degli oggetti senza più referenze che ci fanno riferimento.

OGGETTI DINAMICI IN JAVA

Codice: Seleziona tutto

//...
{ // Le parentesi graffe definiscono uno scope
TestObject temp=new TestObject();
}
//...


Alla fine dello scope temp cessa di esistere (le referenze sono a tutti gli effetti statiche) e l'oggetto costruito da new va nel limbo in attesa che la garbage collecting lo chiami a se.

Conclusioni
Java risolve il problema, i programmatori sono felici perché non si devono preoccupare che la gestione errata dei loro oggetti dia vita o zombie o memory leak. Le prestazioni cadono inesorabilmente a causa di questo lento meccanismo e gli oggetti perdono la possibilità di implementare i distruttori, che se effettivamente hanno perso molti dei motivi di esistere non sarebbero comunque inutili.
Si poteva risolvere diversamente? Assolutamente si ed è ciò che si fa in C++ con gli smart pointers, costruiti da noi o presi da librerie esterne. Sono oggetti statici come le referenze java che al termine del loro scope si occupano di liberare la memoria assicurandosi che non ci siano in giro oggetti zombie e buchi di memoria.
Ecco alcune informazioni al rigurado
La cosa bella è che questi sistemi non impediscono al programmatore di implementare altre soluzioni, cosa che Java con la garbage collection non permette.

[fairyvilje]

Perdonami ma questa non l'ho capita...
Alcuni dicono che Java non sia un linguaggio ad oggetti "puro" perché consente ancora l'utizzo di tipi base come int, byte boolean ecc. non obbligando all'utilizzo di oggetti (Integer, Boolean, ecc.), capisco male o tu dici che sia preferibile non utilizzare oggetti ma tipi base?

Che prevedono di rimuovere con Java 10 secondo voci
Ad ogni modo io non dico che sia preferibile niente sto solo descrivendo tipici metodi di programmazione con uno sguardo a come le librerie standard dei due linguaggi sono implementate.

Intendevo dire che in C++ spesso piuttosto che scrivere una classe per le eccezioni, si lanciano tipi nativi come eccezioni per questioni di prestazioni. Un bel throw 5 per intenderci.
Oppure si impone sulle funzioni un valore di ritorno booleano o intero per capire se è andato tutto bene o meno (come nella gestione degli stream per intenderci). In Java di consuetudine si usano ritorni boolean solo nelle funzioni del tipo hasXXX o isXXX. isReady()? hasNextToken()? isAPony()?
Il fatto che in java si preferiscano le eccezioni e che si usino sempre oggetti come tipo di eccezione lanciato rende il codice più verboso e il programma più lento perché entra il gioco la garbage collecting.

[TardoFreak]

Il tuo punto di vista è interessante perché, ripeto, diametralmente opposto al mio.
Personalmente il garbage collector lo considero una vera e propria genialata, ed i vari obblighi che Java impone una garanzia per un codice sicuro ed affidabile che veramente mi piace.

Ma forse questo dipende anche dalle esperienze personali.

Io vivo da sempre di C e francamente non mi dispiacerebbe che, in talune situazioni, il compilatore fosse un po' più rigido verso certe operazioni (eventualmente bypassando intenzionalmente la rigidità quando serve).
Penso che per certe applicazioni sia meglio poter usare un coltellino con la punta arrotondata con la maestrina (il compilatore) che ti da qualche bacchettata, piuttosto che avere una bomba atomica in mano con il rischio di farsela esplodere sotto le chiappe.

[DarwinNE]

Gli interventi di fairyvilje sono molto interessanti e mettono bene in luce certe differenze fondamentali tra i due linguaggi di programmazione. Differenze che è bene conoscere quando c'è da fare una scelta del tipo Java/C++ in maniera oculata.

Io sviluppo due programmi in questo momento. Uno è FidoCadJ che conoscete bene e che è scritto in Java (30kLOC) e che si basa in maniera abbastanza profonda su Swing e sul sistema grafico java.awt.Graphics2D di Java (che è eccellente).
Un altro è un software di calcolo scientifico, senza interfaccia grafica (circa 15kLOC) scritto in C++ che si basa su BLAS, LAPACK, FFTW3 e cose di questo genere, manipolando matrici che in memoria occupano 1 o 2 GiB ciascuna. Mi serve per fare cose di questo genere:
http://www.opticsinfobase.org/josaa/abs ... a-29-3-367

Sono due progetti molto diversi e quando ho iniziato il secondo non ho pensato neppure per un secondo di scriverlo in Java, se non altro perché non esiste un tipo di dato complex in questo linguaggio, devo interfacciarmi con librerie in Fortran e C e perché un garbage collector non va molto d'accordo con oggetti grandi come le matrici che devo trattare.
Personalmente, sono contento che applicazioni come FidoCadJ sfruttino il garbage collector perché è un problema in meno e perché dalle statistiche che ho fatto il GC incide poco sulla velocità totale del programma in certe situazioni in cui ho potuto fare il profiling. Adesso come adesso, non scriverei un programma GUI in C++ (e difatti ho scritto in Java un viewer per permettermi di vedere cosa produce il mio programma in C++). Problemi diversi richiedono strumenti diversi. Si può piantare un chiodo battendoci sopra con una pinza, ma non è detto che sia la maniera migliore per procedere.

Spezzo una lancia a favore del meraviglioso sistema di segnalazione di eccezioni Java a runtime! Quanto è bello poter avere tutte le informazioni sul punto esatto in cui un errore si è verificato, rispetto ad un laconico "bus error". Il discorso di fairyvilje è verissimo: le eccezioni sono meno usate in C++ che non in Java nella libreria standard e sono più lente di un valore ritornato per segnalare il risultato di una condizione anomala (poi uno si dimentica di verificarlo, ma gli strumenti di analisi del codice aiutano in questo).
Tuttavia, in tutti i linguaggi le eccezioni sono da usare con molta cautela ed, appunto, per segnalare situazioni... eccezionali! Mi pare che Strostroup medesimo spenda molto inchiostro nel suo libro sul C++ per dire di non abusare delle eccezioni e ricordo di molte raccomandazioni in questo senso anche in testi su Java.
Ma che bello avere un messaggio chiaro quando si usa male un Vector, che viene mostrato in maniera affidabile in runtime!!! A chi non è mai capitato?

Invece i discorsi del tipo "Java è lento" mi mettono sempre un po' a disagio, perché non mi paiono per forza legati al linguaggio in se stesso, ma piuttosto a tante cose corollarie, pure se importanti. Sul linguaggio, non è che ci sia poi tutta questa gran differenza con il C++. Su certe cose sì, su altre, meno (e c'è molta letteratura in merito).
Per esempio, in un programma interattivo, l'impressione di velocità che l'utente riceve è in gran parte basata su quanto in fretta vengono ridisegnati gli elementi grafici (finestre, bottoncini).
Ora, un'applicazione basata su Swing è molto diversa da un'applicazione basata su AWT, oppure Android. Eppure stiamo sempre parlando dello stesso linguaggio. Swing è sicuramente più lento di una chiamata nativa per disegnare un bottone, perché... Swing disegna il bottone da zero praticamente senza chiedere nulla al sistema operativo e senza sfruttare scorciatoie che questo eventualmente mette a disposizione.

Un'altra cosa che ho notato è che in certi casi ci sono dei problemi di installazione di Java: prestazioni grafiche soddisfacenti sono possibili unicamente se l'accelerazione grafica avviene via hardware. Questo potrebbe non essere attivo in certi casi (per esempio, l'ho notato in certi bug report con utenti che usano distribuzioni Linux con configurazioni un po' particolari). Se Java JVM non è installato bene, è normale che le prestazioni del software che ci gira sopra siano scadenti.

Ci sono poi scelte politiche che poco hanno a che vedere con l'aspetto tecnico...
A livello del sistema operativo, l'impressione che ho è che Java è più o meno apertamente osteggiato in ambito Apple (forse anche da Microsoft), che hanno tutto l'interesse a fare in modo che un programma in Java giri in maniera insoddisfacente. Per esempio, FidoCadJ su MacOSX (oltretutto non può essere distribuito tramite l'AppStore) impiega un look&feel che non è quello fornito da Apple, ma è Quaqua, il risultato degli eccezionali sforzi di un singolo sviluppatore indipendente: http://www.randelshofer.ch/quaqua/
Eh, già... Android è il principale concorrente di iOS ed è basato su Java
Il risultato è che un software Java su MacOSX (da qualche anno a questa parte, perché prima non era affatto così quando Cocoa era supportato in Java) viene scoraggiato e sembra sempre un po' bruttino o non integrato con l'aspetto generale del sistema e l'utente tende a dare la colpa al linguaggio o agli sviluppatori...

Se Java fosse così lento, perché è così diffuso da tanti anni nelle applicazioni mobili (a parte iOS) dove notoriamente la potenza di calcolo è così limitata?

Comunque, esiste il linguaggio ed esistono gli strumenti per aiutare il programmatore. Io mi sono innamorato degli strumenti di analisi statica e dinamica del codice (PMD, Findbugs per Java, cppcheck e valgrind per C++).

TardoFreak, sono esistiti processori che masticano bytecode Java: http://en.wikipedia.org/wiki/Java_processor

[TardoFreak]

... Se Java fosse così lento, perché è così diffuso da tanti anni nelle applicazioni mobili (a parte iOS) dove notoriamente la potenza di calcolo è così limitata?
...

Osservazione molto acuta.