Newsgroup: it.comp.java
Titolo: [FAQ] it.comp.java v0.9

 piattaforme valide?? 
L'anno scorso fui responsabile del team che realizzo' alcune applicazioni 
Java 
presentate poi a SMAU96, per una societa' di software. 
Siccome la portabilita' era ed e' effettivamente la caratteristica piu' 
notevole 
di Java, volevamo dimostrarla facendo girare le applicazioni su diverse 
piattaforme contemporaneamente (lo so, lo so, e' marketing.. ma che ci si 
puo' 
fare? ;-) ); nella realizzazione, incontrammo alcuni problemi simili ai 
tuoi. 
Posso fare solo qualche considerazione: 
1. Java, *mediamente* richiede che si pensi in modo "pulito". Cosa strana 
per 
un 
oggetto di moda, e' dotato di una notevole qualita', ma richiede che chi ne 
fa 
uso sia altrettanto.. notevole, soprattutto in termini di progettazione. 
Quindi 
sfruttane a fondo le caratteristiche (distribuzione del codice su molte 
classi, 
GUI integrata, etc), ma evita come la peste "trucchi" e porcherie varie nel 
codice spicciolo - di norma vengono rifiutate da altre JVM. Usa, applica e 
fai 
applicare i modelli teorici e tecnici corretti - mai come in Java gli 
"accrocchi" si traducono velocemente in disastri. 
2. In media, Java e' *estrememamente* piu' portabile di qualunque cosa 
abbia 
mai 
visto (e, non so perche', nel mio lavoro mi sono capitati una quantita' di 
porting.. :) ). Cio' non toglie che considerare una buona mezza giornata 
per 
l'adattamento di ogni classe ad un comune denominatore di funzionamento non 
sia 
una stima irragionevole ;^). Rispetto alle giornate-uomo necessarie in 
altri 
contesti, e' comunque un tempo trascurabile. 
3. Attenzione che Sun supporta solo le versioni Win32, Solaris e, se non 
erro, 
MacOS - quindi le altre possono essere meno aggiornate o errate. 
4. Porta pazienza. L'ambiente e' nuovo, recentemente arricchito di una 
serie di 
funzionalita' che gli forniscono una potenza decisamente vasta e quindi 
necessita ancora di un po' di tuning. Del resto, i buoni affari si fanno 
con le 
novita', no? In effetti, gli unici problemi "veri" (non dovuti a 
impostazioni 
approssimate o ad analisi malfatte) che riscontrammo l'anno passato (con 
JDK1.0.2 e versioni di JVM nei vari browser non updated o semplicemente 
bacate) 
erano alla fin fine le & nei menu (che sotto solaris venivano 
visualizzate.. 
come &) e la differente gestione del multithreading nella versione WIN32 e 
Solaris. 
Detto questo, il mio parere e' che, con un po' di buon senso, di 
competenze, di 
incavolamenti e fatica costruire applicazioni complesse (non applet da 
effetto 
pagina www) e portabili e' molto piu' facile con Java che con qualunque 
altra 
cosa - e il risultato di solito merita lo sforzo. 
[T5.2] Prerequisiti per imparare Java 
      Subject:Imparare Java: devo conoscere C? 
 
From:p.fo...@cdc.it
 (Paolo Fontana) 
      Date:1997/12/03 
      Newsgroups:it.comp.java
Per usare Java è consigliabile già conoscere C o C++? grazie, Paolo 
      Subject:Re: Imparare Java: devo conoscere C? 
 
From:mi...@skm.to
 (Michele Beltrame) 
      Date:1997/12/03 
      Newsgroups:it.comp.java
Non e` indispensabile. Ovviamente aiuta. ;-) 
      Subject:Re: Imparare Java: devo conoscere C? 
      From:Cristiano Sadun <
cr...@NOSPAM.sun6.itim.mi.cnr.it
      > 
      Date:1997/12/04 
      Newsgroups:it.comp.java
Non particolarmente. Anzi, imho, se sei abituato al C e' peggio; viceversa, 
se 
conosci bene C++, fai *molto* in fretta. 
[T5.3] Java e C++ 
      Subject:Java e C++ 
      From:Andrea Baruzzo 
      Date:1999/04/08 
      Newsgroups:it.comp.lang.c++ 
Salve a tutto il NG. 
Vorrei proporre una discussione che confronti java e C++. 
C'è qualcuno di voi che, oltre ad avere esperienza in C++, ha sviluppato 
anche 
in java e può comunicarmi le sue impressioni usando i due linguaggi. 
Mi interesserebbe sapere dove a vostro giudizio sono i pregi e idifetti 
delle 
due soluzioni. Spero di non essere OT (almeno il 50% deldiscorso è inerente 
al 
NG: si parla comunque di C++, anche se come metro diconfronto viene 
proposto 
poi 
un altro linguaggio). 
Spero di non infastidirenessuno.Grazie a quanti vorranno rispondermi. Se 
l'argomento non lo riterrete diutilità per discuterne sul NG potete 
mandarmi le 
vostre impressioni in formaprivata via mail. 
Ciao a tutti 
Andrea 
      Subject:Re: Java e C++ 
      From:Marco Sarti 
      Date:1999/04/09 
      Newsgroups:it.comp.lang.c++
A mio parere java ha i seguenti vantaggi: 
- la portabilità del codice compilato (ovviamente) 
- maggiori soluzioni object oriented rispetto al C++. Appare unlinguaggio 
più 
"moderno" da questo punto di vista 
- Notevole supporto per applicazioni orientate alle reti 
Gli svantaggi invece sono: 
- Mancanza dei puntatori. Qualcuno gioisce per questo, ma i puntatori (e 
l'aritmetica dei puntatori) restano una grande potenza del C/C++- Quando 
c'è 
bisogno di applicare soluzioni native bisogna tornare dapapà C/C++ :-) [a 
questo 
proposito cfr. R1.17, -cris] 
Java non ti offre nel linguaggio la possibilità di creare codice non 
portabile, 
mentre nel C++ questa può essere una scelta. 
Questo è quello che mi viene in mente... 
      Subject:Re: Java e C++ 
      From:Cristiano Sadun 
      Date:1999/04/09 
      Newsgroups:it.comp.lang.c++
Be', ho sviluppato parecchio in entrambi i linguaggi, e dato che di 
mestiere 
faccio il designer di sw sono quelli che uso comunemente a meno di vincoli 
esterni. Sulle differenze tra Java a C++ un paio d'anni fa ci scrissi sopra 
una 
articolo da 15 pagine, e Java aveva un terzo della potenza che ha adesso 
:), 
quindi in breve si puo' dire molto poco. :) 
Comunque, Java nasce come una semplificazione di C++ *e* un potenziamento 
dello 
stesso: i vantaggi in brevissimo, a livello di linguaggio, capacita' 
espressive, 
ambienti e librerie (wow :) 
- maggiore portabilita'. E' possibilissimo scrivere codice portabile in 
C++, 
almeno finche' non c'e' di mezzo una GUI, ma e' *molto piu' difficile*. 
- supporto nativo al multithreading. C++ si deve appoggiare al s/o. 
- supporto nativo al networking. Per C++, come sopra. 
- migliore supporto al design OO, con la definizione specifica di 
interfacce e 
classi di implementazioni. C++ ha solo classi astratte come elementi di 
modellazione. 
- garbage collection. In C++ i memory leaks sono all'ordine del giorno, in 
java 
quasi non esistono. 
- non c'e' l'ereditarieta' multipla. Qui si va a gusti, ma la mia 
esperienza e' 
che l'e.m. complica le cose piu' di quanto non le aiuti. Non entro in 
dettagli 
altrimenti faccio un trattato :^) 
- gestione esplicita dei package. C++ ha i namespace - ma chiunque abbia 
provato 
a lavorare con librerie diverse e vincoli di contratto sa quanto possono 
valere.. :) 
- loading dinamico delle classi - il programma non e' quasi-monolitico come 
in 
C++. 
- una libreria standard da paura, gratis.- una curva di apprendimento un 
pochino 
meno ripida. Per usarlo efficacemente ovviamente, tanto quanto C++, bisogna 
conoscere l'OO - altrimenti si resta praticoni a vita. ;-) 
- supporto obbligatorio alle eccezioni. In C++ sono opzionali (e pochi 
programmatori le usano, dato che sono state aggiunte da relativamente 
poco), e 
i 
risultati sulla qualita' del codice si vedono. 
- tempi piu' veloci per lo sviluppo e una generale miglior qualita' del 
codice 
prodotto anche da programmatori non.. sopraffini (nella mia esperienza, una 
ratio 3/5gg a favore di java per sw di complessita' media). 
C++, d'altro canto: 
- e' strutturalmente piu' performante. Alcune caratteristiche di java (gc, 
architettura a VM, etc) lo rendono piu' lento. 
- e' stato recentemente standardizzato 
- non ha un un'unica radice per le gerarchie di oggetti. Io personalmente 
non 
lo 
vedo come vantaggio, ma c'e' chi lo fa. 
- non favorisce il downcast dinamico, che in Java e' una prassi 
- ha i template, che a volte sono decisamente comodi 
- ha STL, che e' potente e versatile - e soprtattuto ha un sacco di 
algoritmi 
ben fatti gia' pronti 
- consente di accedere direttamente al s/o - che a volte e' indispensabile 
- non e' facile da reverse-engineering-izzare (lo so e' orrido :) mentre 
java 
e' 
tutto sommato facilmente decompilabile. 
- di java si sono avute almeno 15 versioni in tre anni. Il linguaggio, 
anche se 
imho maturo, e' ancora giovane. 
Varie ed eventuali: 
- java obbliga (piu' o meno) ad una strutturazione dei moduli "una classe-
un 
file" (o poche classi *molto* correlate), C++ mantenendo la struttura 
header/codice a volte e' un incubo da ricompilare. 
- c++ "vive" (anche se in forme e quasi-standard diversi) commercialmente 
dai 
primi anni 80, java da meta' 90. Questo significa che e' piu' "accettato" 
anche 
in ambiti conservatori.. ottenere un contratto nominando C++, in molti 
ambiti, 
e' ancora piu' facile che non nominando java. 
Ovviamente ci sarebbe un libro di cose da scrivere.. comunque e' un inizio. 
[A tutto questo è seguita un'interessante (imho) discussione sul design 
object 
oriented e sulle features di Java e C++, che e' troppo lunga da riportare 
qui. 
Se volete leggere l'intero thread, usate 
www.dejanews.com
 cercando negli 
articoli di Aprile 1999 di it.comp.lang.c++ (vari subject), -cris] 
[T5.4] Soluzioni di reportistica per Java 
      Subject:Soluzioni di reportistica per Java (WAS: 'Java e DB2') 
      From:Bruno Bossola 
      Date:1999/11/08 
      Newsgroups:it.comp.java
Ciao a tutti, 
in un altro thread e' uscito fuori il problema "reportistica per java": 
siccome 
a mio parere e' un tema che va messo in evidenza, ecco l'analisi (vecchia 
ormai 
di un mese) svolta dal mio gruppo sui prodotti di report (non sono in 
nessun 
ordine!) disponibili attualmente e che siamo riusciti a trovare e valutare 
velocemente. 
Nome: JReport Professional 
Builder visuale: Si 
Costo: 995$ 
Licensing: 100 Desktop 
URL: 
http://www.jinfonet.com/designer.htm
 
Commento: molto buono, licenza troppo cara, specialmente server-side 
Nome: Enterprise Report Writer 
Builder visuale: Si 
Costo: 395$ 
Licensing: 100 Desktop 
URL: 
http://www.enterprisesoft.com/Products/ReportWriter.html
 
Commento: molto buono, licenza troppo cara, specialmente server-side 
Nome: InetSoft Style Report 
Builder visuale: No 
Costo: 495$ 
Licensing: Runtime free 
URL: 
http://www.inetsoftcorp.com/report/index.html
 
Commento: ottimo, licenza poco costosa, potente API, manca pero' di GUI 
(presente solo per preparazione report colonnari). Da usare solo con 
programmatori 
Nome: JJPRint 
Builder visuale: No 
Costo: ? 
Licensing: ? 
URL: 
http://www.finansys.com/jjprint_en.html
 
Commento: boh, sembra uno scherzo; libreria di API ultra-semplificata 
Nome: Parallel Crystal 
Builder visuale: Si (usa Crystal Report) 
Costo: ? 
Licensing: ? 
URL: 
http://www.mobileapps.com/products.htm
 
Commento: Non 100% Java, funziona inoltre solo con Server NT 
Nome: BeanSteet Paper 
Builder visuale: No 
Costo: ? 
Licensing: ? 
URL: 
http://www.beanstreet.com/paper/paper.html
 
Commento: buono solo per semplici report colonnari 
Nome: Crystal-Clear 
Builder visuale: Si (usa crystal report) 
Costo: ? 
Licensing: ? 
URL: 
http://www.inetsoftware.de/English/produkte/crystalclear/
 
Commento: sembra ottimo, utilizza i report di CRY 6 e 7, disponibile solo 
in 
beta, prevista uscita Q1-2000 
Nome: PrintLet 
Builder visuale: Si (almeno sembra) 
Costo: 300% 
Licensing: ? 
URL: 
http://www.palmsoftware.com/
 
Commento: nessun commento su questo... sarebbe da rivedere 
Nome: Jclass 
Builder visuale: No (usa template XML) 
Costo: 300% 
Licensing: ? 
URL: whups! manca! 
Commento: orientato ai programmatori, sembra buono 
Comunque, FYI, noi usiamo Crystal-clear. Molto comodo, permette la 
generazione 
dei report con Crystal Report 6 (strumento collaudato, diciamo :-)) e 
funziona 
a 
2/3 livelli con app.server dedicato e modulino da scaricare sul client. 
Anche 
ERW e JReport secondo me sono ottimi, peccato per i costi :-( 
Se avete dei programmatori (e tempo) a disposizione vi consiglio comunque 
InetSoft Style Report, sembra veramente ok! 
Poi c'e' sempre la vecchia soluzione "artigianale" HTML, da considerare con 
attenzione in molti casi. 
Postate sul NG altri pareri/soluzioni, e anche commenti aggiuntivi rispetto 
ai 
nostri (molto unilaterali), please! 
Ciao, 
Bruno. 
      NOTA IMPORTANTE Questa versione e' ancora largamente incompleta - ne 
      faccio il post per avere un po' di feedback e trovare contributi e 
      ...contribuenti! 
      NOTA (in qualche modo importante): nel periodo Giugno/Settembre 1998 
      (causa miei impegni di lavoro et similia) *non* sono state fatte 
      modifche/aggiunte. 
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun/

FAQ di it.comp.java
Vista la quantita' di messaggi che arrivano del tipo:
1) quali libri per incominciare
2) quale sdk mi consigliate
3) perche' javac HelloWorld.java non va,
non si potrebbe realizzare una mini-FAQ con le risposte a queste
domande, da postare settimanalmente, in modo che chiunque legga il
newsgroup per la prima volta se la ritrovi tra i messaggi?
Ciao,  
 P.    === Replace "punto" with "." to get my email address.

 newsgroup per la prima volta se la ritrovi tra i messaggi?
Concordo pienamente. Tempo fa ho cercato di aprire una discussione
simile. L'idea della mini-FAQ č buona. Cristiano ?
Ciao,
-- 
Massimiliano Bigatti
Java Consulting (Open Consulting)
http://members.xoom.com/bigmax74

simile. L'idea della mini-FAQ č buona. Cristiano ?
L'idea e' ottima. Qualche tempo fa presi a postare settimanalmente un mini-
sunto che conteneva, tra le altre cose, un riferimento alla FAQ e consigli vari 
(la trovi du dejanews). 
Il fatto e' che il mio robot per l'invio automatico sui ng e' alla ricerca di 
una casa (oltre a necessitare di qualche manutenzione, e' in alfa da cinque 
mesi ;-) e non sempre posso postare a mano. Inoltre su it.faq i tempi di 
latenza sono in media buoni, credo, ed esiste dejanews (anche se ho cominciato 
a mettere la FAQ in X-No-Archive per vedere se qualcuno si lamenta ;-), ma 
dalla prossima torno al modo normale, magari aggiungendo un Expire header.. ma 
quanti server gli onorano?)
Morale: finche' il mio robot non torna in vita (ah, il codice - java - e' 
pubblico: lo trovi sul mio sito), ho deciso di tentare di rispondere a queste 
domande semplicemente inviando l'URL della FAQ in mail o sul ng. 
Trovo la cosa - in assenza di bot - piu' economica, e maggiore la probabilita' 
che il newbie in questione la legga. Possiamo provare con questo approccio nel 
frattempo.
Inoltre ho la sensazione che, per certi newbies, il post dovrebbe essere 
giornaliero.. e anche cosi' non lo leggerebbero. :) Del resto, sono newbies 
apposta, no? :)
