Java

[kreen]

In un recente post si è menzionato Java.
Premesso che non è mia intenzione scatenare flames, anche se trattare tali argomenti nasconde questi pericoli, mi chiedo perché esiste tale diffidenza verso tale linguaggio.

http://www.idiom.com/~zilla/Computer/ja ... hmark.html
http://it.wikipedia.org/wiki/Project_Looking_Glass
http://attivissimo.blogspot.com/2007/02 ... vista.html
http://www.gnu.org/philosophy/java-trap.it.html
http://www.fsf.org/news/fsf-welcomes-gpl-java.html

[gil-galad]

Uso java per lavoro e personalmente non nutro diffidenza verso questo linguaggio.

Il discorso è che magari fino a qualche tempo fa non era del tutto libero e usarlo per scrivere applicazioni per linux faceva storcere il naso. La filosofia che porta avanti linux male si sposa nell'usare tool proprietari e chiusi per lo sviluppo di applicazioni.

Penso che le cose ora stanno cambiando, è stato rilasciato openjdk, ho seguito distrattamente il processo di liberalizzazione di java da parte di sun ma mi sembra che si sia a buon punto.

Poi per me forse è diverso rispetto agli altri, perchè ho iniziato a conoscere java proprio quando è nato. All'università il prof di sistemi di elaborazione puntò tutto su java e disse: "un giorno vi darà da mangiare". Per il momento posso dire che aveva ragione :P.

[aschenaz]

Io credo che la diffidenza sia soprattutto dovuta al fronte user.
Io uso quotidianamente applicazioni web basate soprattutto su java
e la cosa che personalmente mi infastidisce di più è la grande fame
di risorse che queste applicazioni hanno (o sembrano avere).
Un'altra cosa abbastanza seccante riguarda il fatto che vengono
richieste diverse (troppe) versioni di vm per applicazioni diverse
(sul pc che uso in ufficio ce n'è almeno sei...) e non è raro che si
verifichino incompatibilità. Ma non escludo che questa situazione
sia dovuta ad una certa leggerezza da parte della società che
gestisce l'informatizzazione della mia amministrazione...

[Blizzard]

Non è diffidenza. Ma un po di antipatia per la presunzione di deizzarsi dinanzi linguaggi come il C/C++ (chiamatela guerra di religione ).

Java parte molto sborone al grido di "compile once, run everywhere". La vedo come andare al supermercato e acquistare l'acqua in ebbollizione da usare con la pasta.
Sono stati parecchi i casi in cui librerie java sono os-dipendenti e, pertanto, le applicazioni non sono portabili.
Quel grido vale specificatamente se si utilizza il classpath di SUN e librerie portabili. C/C++ se scritti basandosi sulla STL e sulle librerie portabili hanno lo stesso effetto al grido di "write once compile everywhere".

Con java puoi creare eseguibili ed usarli su vari os. Ma il bytecode è stata anche una delle cose più reversibili che mi sia capitata nell'orecchio (sbaglio o si ricostruisce tranquillamente anche il codice java vero e proprio?).
Ovviamente nel mondo GPL e simili il fatto di distribuire bin-only è una cosa stupida.

Java è semi-interpretato. Per quanto possa essere veloce una vm comunque c'è un layer in più. Lotus Sinphony in confronto ad OpenOffice ed Eclipse (ma anche NetBeans) in confronto alla suite KDevelop ne sono un esempio (anche per caricare jedit mi ricordo ci voleva parecchio tempo su Windows).
Mi avevano detto anche che il DE che era basato su java per il SUN OS era una piattola (ma questo non l'ho visto con i miei occhi).

IMHO Java è palloso a certi livelli... ma questo è, e rimane una cosa mia.

Programmazione limitata solo ai campi per cui è disponibile una virtual machine (scritta in altri linugaggi :P).

Java ha una struttura comunque niente male ed è ottimo per alcuni generi di applicativi non time critical.
Se un giorno mi ritroverò a sviluppare con java non mi lamenterò più di tanto (anche perchè i pc di quel momento forse riusciranno a digerire l'IDE )
Il mio problema è che quando è uscito lo hanno divinizzato che pareva dovesse diventare l'unico linguaggio del nuovo millennio. Il fatto che molti (anche riviste ecc...) ci hanno creduto di brutto (insieme al .NET).
A conti fatti oggi non mi sembra che abbia seppellito gli altri linguaggi, anche se a livello aziendale e sui vecchi cellulari si è imposto.

Gio

[cymon]

Il principale problema di JAVA, a mio parere, è che la sua filosofia è fortemente orientata alle aziende e non necessariamente miete consensi nei campi un po' più indipendenti.
Non parlo delle strategie SUN, dei pacchetti prodotti o del modo in cui viene distribuito, JAVA è un linguaggio talmente rigido che esiste, dato un problema, uno e un solo modo per risolverlo e le capacità e l'estro del programmatore sono spesso limitate, vista la mostruosa disciplina che impone.
Questo, è vero, rende a volte poco divertente scriverlo, ma dall'altra parte permette alle aziende di assumere mediocri programmatori (e ce ne sono in giro TANTI) e impedire che siano eccessivamente farraginosi, permette di scrivere i grandi progetti ragionando per blocchi e vedendo quanto scritto su carta riportato in modo mediamente fedele nel codice e agevola flussi di rilasci e modifiche modulari, limitando i side effects.
Con l'attuale diffusione di JAVA il principio della portabilità è venuto un po' a cadere, è molto comune che si abbia bene in mente su che piattaforma si andrà a deployare un tal applicativo e le migrazioni (ringraziandiddio) non sono cose di tutti i giorni, sicuramente la cosa aveva un senso alla nascita, in cui il mondo dell'informatica era un po' più magmatico...
Per quello che riguarda le prestazioni la nomea che JAVA sia piuttosto avido è stata per lungo tempo una triste realtà, ma oggi direi che le sue richieste, per quanto esose, siano raffrontabili con quelle di tutti gli altri tipi di software di una certa complessità...

[kreen]

Non è diffidenza. Ma un po di antipatia per la presunzione di deizzarsi dinanzi linguaggi come il C/C++ (chiamatela guerra di religione ).

Anch'io trovo antipatico quando presentano un prodotto come una sorta di "soluzione definitiva". Java, inoltre ha avuto per molto tempo delle lacune inspiegabili rispetto al C++, pur essendo credo nato dopo. Per esempio, il primo che mi salta in mente, gli enumeratori.

A differenza del C++ (non riesco ad accostarlo al C, sono due linguaggi completamente diversi), però non è mai fermo, ma in continuo miglioramento. E non credo, personalmente, sia un fatto negativo.

Java parte molto sborone al grido di "compile once, run everywhere".

Già, la cosa funziona se chi implementa le macchine virtuali e chi scrive i programmi, seguono lo "standard" SUN. A differenza del C++, nativamente viene formito un insieme di classi per gli ambienti grafici. Non capisco perché tu e cymon lo definiate poco divertente o palloso. Credo che il lavoro di progettazione che richiede sia molto stimolante, ovvero l'analisi, la definizione delle classi, delle interfacce. Sicuramente, come scrive cymon, non lascia quegli spazi che il C++ lascia. Che rappresentano anche un pericolo, perché maggior libertà implica maggior rischio.

Java ha una struttura comunque niente male ed è ottimo per alcuni generi di applicativi non time critical.

In effetti, per applicazioni time critical, o anche realtime, Java è totalmente inadatto.

Mi avevano detto anche che il DE che era basato su java per il SUN OS era una piattola (ma questo non l'ho visto con i miei occhi).

Io ho visto la presentazione effettuata nel lontano 2003 (lontano in misura informatica) e devo ammettere che i presupposti non erano affatto male (se si pensa che era il 2003). Essendo un progetto opensource, il suo sviluppo è dipeso dalla buona volontà... penso che sia il motivo della lentezza dal punto di vista dello sviluppo. Ma se pensi che nel 2003 i desktop 3d neanche se li immaginavano (almeno, da ciò che mi ricordo).

Questo, è vero, rende a volte poco divertente scriverlo, ma dall'altra parte permette alle aziende di assumere mediocri programmatori (e ce ne sono in giro TANTI) e impedire che siano eccessivamente farraginosi, permette di scrivere i grandi progetti ragionando per blocchi e vedendo quanto scritto su carta riportato in modo mediamente fedele nel codice e agevola flussi di rilasci e modifiche modulari, limitando i side effects.

Ce ne sono troppi, non tanti Ma un buon prodotto software, anche se artigianale, ha bisogno, secondo me, di molto più che un buon programmatore. La codifica è importante, ma il progetto a monte è fondamentale. Quello che scrivi, cioè cheagevola i rilasci e le modifiche, mi sembra un punto a favore del linguaggio, una nota di merito.

Un altra cosa abbastanza seccante riguarda il fatto che vengono
richieste diverse (troppe) versioni di vm per applicazioni diverse
(sul pc che uso in ufficio ce n'è almeno sei...)

Pare strano. Credevo che ogni nuovo JRE fosse retrocompatibile con le applicazioni scritte per le precedenti versioni.

Uso java per lavoro e personalmente non nutro diffidenza verso questo linguaggio.

Che tipo di applicazioni sviluppi, per curiosità?

[conraid]

Al di là di licenze più o meno libere, non ti sembra che "a parità di funzionalità" le applicazioni scritte in JAVA sono più lente e più avide di risorse?

[gil-galad]

Uso java per lavoro e personalmente non nutro diffidenza verso questo linguaggio.

Che tipo di applicazioni sviluppi, per curiosità?

Applicazioni desktop con SWT e web J2EE.

[aschenaz]

Un'altra cosa abbastanza seccante riguarda il fatto che vengono
richieste diverse (troppe) versioni di vm per applicazioni diverse
(sul pc che uso in ufficio ce n'è almeno sei...)

Pare strano. Credevo che ogni nuovo JRE fosse retrocompatibile con le applicazioni scritte per le precedenti versioni.

Te lo confermo: ogni volta che esce un nuovo software scritto in
Java, nelle specifiche c'è scritto quale vm pretende e non c'è
modo di farlo funzionare altrimenti.
Prova a vedere, per esempio, Gerico 2008:
http://www.agenziaentrate.it/ilwwcm/con ... co+2008+1/
Tra l'altro, c'è scritto che richiede la vm 1.5.0 e invece vuole la 1.4.0
(mi dicono: non l'ho verificato personalmente...).
Ma questo è solo la punta dell'iceberg: non posso farti vedere
tutti gli applicativi riservati (che stanno nell'intranet).

[kreen]

Al di là di licenze più o meno libere, non ti sembra che "a parità di funzionalità" le applicazioni scritte in JAVA sono più lente e più avide di risorse?

Non posso risponderti, Conraid, perché non saprei cosa risponderti. Per saperlo dovrei vedere la medesima applicazione o qualcosa di simile scritta in Java e in altro linguaggio. Credimi:
1) non sto cercando di eludere la domanda.
2) non sono schierato nè pro nè contro Java.

Fino a poco tempo fa, pensavo che in effetti la JVM (che è comunque un interprete) e il meccanismo di Garbage Collector (che ogni tanto deve dire "Alt, è tempo di far pulizia"), fossero molto penalizzanti. Poi mi sono capitati dei link, uno dei quali l'ho riportato nel primo messaggio nel tentativo di fornire materiale per la discussione, che presentano asserzioni sul quasi allineamento tra C++ e Java.
Inoltre, ho visto quella demo su Looking Glass, diamine, nel 2003 ho comperato un AMD 2400 con un Giga di Ram, il tipo usa un Laptop (che Hardware girava all'epoca? Non lo so, ma non credo che il super top fosse paragonabile a quello attuale medio). Looking Glass è scritto in Java. Ed è sorprendente.

C++ è un ottimo linguaggio, io non lo conosco come vorrei (IMHO, il C++ è più complesso e pericoloso del C), ma credo personalmente che lo sia anche Java. Se volessi sviluppare un'applicazione di modellazione 3d, sicuramente non sceglierei Java. Per un gestionale, un applicativo di controllo industriale (sai, quelle interfacce dove clicchi qui e li' e avvi motori, pompe etc...), un IDE di programmazione, un player, una interfaccia per qualche programma Unix, tipo KPGP, KGet, o programmi tipo KolourPaint, Java mi semra un linguaggio che ha le medesime potenzialità del C++.

[kreen]

Te lo confermo: ogni volta che esce un nuovo software scritto in
Java, nelle specifiche c'è scritto quale vm pretende e non c'è
modo di farlo funzionare altrimenti.
...
Tra l'altro, c'è scritto che richiede la vm 1.5.0 e invece vuole la 1.4.0

Ahhh avevo capito il contrario. Certo, le nuove applicazioni richiedono le JVM più recenti perché chi ha scritto il software usa le aggiunte più recenti al linguaggio. Ad esempio, l'autoboxing l'inboxing sono aggiunte relativamente recenti e quindi le VM vetuste non riconoscono questi meccanismi.
Io facevo il discorso inverso, ossia che le nuove JVM supportano le vecchie applicazioni.
Ma succede lo stesso anche in Linux. Non ti è mai capitato durante un ./configure di beccarti messaggi che ti dicono che hai versioni di librerie vecchie?
Ma allora, perché gli amministratori del tuo sistema tengono le JVM vecchie?

[cymon]

Non capisco perché tu e cymon lo definiate poco divertente o palloso. Credo che il lavoro di progettazione che richiede sia molto stimolante, ovvero l'analisi, la definizione delle classi, delle interfacce. Sicuramente, come scrive cymon, non lascia quegli spazi che il C++ lascia. Che rappresentano anche un pericolo, perché maggior libertà implica maggior rischio.

La progettazione non dipende dal linguaggio di programmazione, la progettazione è SACRA a prescindere
I problemi di noiosità o pignoleria sono proprio a basso livello, quando cominci a scrivere le righe. JAVA non ammette sottintesi e non prende iniziative, non permette di violare nessuna regola e ogni cosa è in realtà un oggetto innestato in un altro oggetto che è un altro oggetto, spesso per capire il funzionamento di qualcosa bisogna risalire una complessa scala da cui non si può prescindere.
Considera che io mi considero un programmatore perl. La filosofia di perl è: tu dammi quello che vuoi, poi mi arrangio io a farlo funzionare. Ciò significa che, in certi contesti, non hai bisogno nemmeno di passargli le variabili in input. Questo lo rende "divertentissimo" e LETALE nelle mani sbagliate, perchè si può arrivare a scrivere codice meno chiaro di un binario. Il JAVA è il contrario, ogni cosa deve essere stabilita a monte. Gioie e dolori...

Ce ne sono troppi, non tanti Ma un buon prodotto software, anche se artigianale, ha bisogno, secondo me, di molto più che un buon programmatore. La codifica è importante, ma il progetto a monte è fondamentale. Quello che scrivi, cioè cheagevola i rilasci e le modifiche, mi sembra un punto a favore del linguaggio, una nota di merito.

Una assoluta nota di merito e, come ho detto, uno dei principali motivi per cui ha avuto tale fortuna aziendale. Ci sono linguaggi in cui, se non ragioni modularmente non è un problema, finchè non ti trovi di fronte a un problema e non sai come fare l'upgrade puntuale della funzionalità. JAVA se non ragioni modularmente NON FUNZIONA.

C'è anche un altro merito mostruoso che bisogna riconoscere alla SUN ed è quello di aver standardizzato la documentazione tramite javadoc. Quando installi una libreria JAVA di qualsiasi genere sai che da qualche parte potrai fare riferimento al javadoc che è abbastanza chiaro, ma soprattutto, è standard e quindi subito famigliare a un programmatore JAVA. Con gli altri linguaggi non c'è altrettanta istituzionalizzazione e la documentazione oscilla tra il criptico e "bhe, il codice è abbastanza chiaro di per sè".

[gil-galad]

Al di là di licenze più o meno libere, non ti sembra che "a parità di funzionalità" le applicazioni scritte in JAVA sono più lente e più avide di risorse?

Il fatto di essere avido di risorse è perchè la jvm deve garantire subito alle applicazioni ciò che serve.
Se poi parliamo di memoria, questa può essere gestita da parametri a riga di comando, in modo da ottimizzare per specifica applicazione il suo utilizzo. Meglio di me può descriverlo questa pagina web http://java.sun.com/performance/reference/whitepapers/tuning.html.

Una cosa da dire però, java non è un linguaggio interpretato in senso "sporco", in realtà il bytecode viene dato in pasto al JIT che si occupa di tradurlo in linguaggio macchina, allo stesso tempo la jvm analizza il codice in modo da ottimizzarlo. Questo è il motivo per cui all'avvio un applicazione java impiega del tempo per essere attiva.

Riguardo al bytecode, si può essere de compilato molto agevolmente per riavere il codice sorgente. Problema che non vedo in linux però, dato che siamo in regime di libertà garantita dalla gpl

p.s.
avevo commesso un errore nel postare il link al tuning della jvm, avevo preso il link sbagliato.

[conraid]

Fino a poco tempo fa, pensavo che in effetti la JVM (che è comunque un interprete) e il meccanismo di Garbage Collector (che ogni tanto deve dire "Alt, è tempo di far pulizia"), fossero molto penalizzanti. Poi mi sono capitati dei link, uno dei quali l'ho riportato nel primo messaggio nel tentativo di fornire materiale per la discussione, che presentano asserzioni sul quasi allineamento tra C++ e Java.

Bah... Eclipse sul mio pc non va (PIII 1ghz e 512 di ram), lo stesso thinfeeder (http://thinfeeder.sourceforge.net/) va molto lento paragonato ad akregator per esempio, e così altri programmi in java. Poi mi puoi dire che ho un pc vetusto, tutto vero, ma FF, OpenOffice, etc... ci girano tranquillamente.
Oppure mi puoi dire che quelle applicazioni fanno mille più cose dei loro corrispettivi, sarà anche vero... ma mi tengo i loro corrispettivi se per far girare tali applicazioni devo comprare un pc nuovo (alla Windows mode)

P.S.
è inutile che i benchmark del core siano simili se poi le librerie grafiche non lo sono, per esempio. A me che faccia calcoli nello stesso tempo del C++ importa poco, se poi non posso utilizzare un editor, un ide, un semplice programma con interfaccia nel mio pc

[kreen]

La progettazione non dipende dal linguaggio di programmazione, la progettazione è SACRA a prescindere

Sante parole. E' la parte che mi piace di più. Capire il problema e trovare una soluzione per risolverlo.

I problemi di noiosità o pignoleria sono proprio a basso livello, quando cominci a scrivere le righe. JAVA non ammette sottintesi e non prende iniziative, non permette di violare nessuna regola e ogni cosa è in realtà un oggetto innestato in un altro oggetto che è un altro oggetto, spesso per capire il funzionamento di qualcosa bisogna risalire una complessa scala da cui non si può prescindere.

Per questo si chiama programmazione ad oggetti Anche la main è all'interno di una classe
Il fatto che non permetta di violare nessuna regola secondo me è un pregio. Il compilatore Java è un rompib**e. Ma hai molti meno rischi che ti telefonino per insultarti in seguito ad un crash con conseguente perdita di dati e lavoro.

Considera che io mi considero un programmatore perl. La filosofia di perl è: tu dammi quello che vuoi, poi mi arrangio io a farlo funzionare. Ciò significa che, in certi contesti, non hai bisogno nemmeno di passargli le variabili in input. Questo lo rende "divertentissimo" e LETALE nelle mani sbagliate, perchè si può arrivare a scrivere codice meno chiaro di un binario. Il JAVA è il contrario, ogni cosa deve essere stabilita a monte. Gioie e dolori...

Non conosco assolutamente il Perl. Indubbiamente quella libertà richiede anche una learning curve a forma di log n. Ovvero, per non farsi male serve parecchio tempo. Ma, domanda provocatoria, se Java è ottimo in campo industriale, riduce il debug (non corri rischio di trovarti qualche puntatore malgestito) etc... non è ancora meglio per realtà più piccole? Se per sviluppare una applicazione servono es 800 ore/uomo, una realtà media impiega 8 persone, in circa 100 ore ha finito (parlando a spanne...). Un'azienda di 2/3 amici,colleghi impiega il triplo. Immaginati il debug... Debuggare un programma in C non è certo come debuggare un programma Java, dove la JVM ti piglia per le orecchie e ti da quattro schiaffoni. Il divertentissimo e LETALE, quando ci sono di mezzo dei clienti che pagano, può essere tragicamente LETALE. Non trovi?