Newsgroup: it.comp.java
Titolo: [FAQ] it.comp.java v1.04

 
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:  Dopo circa tre anni, questa versione - anche se comunque incompleta -
assume la numerazione 1.0. Gioia, gaudio e champagne - se volete spedirmelo,
chiedetemi l'indirizzo. ;-) 
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun

 --------------------------------------------------------------------------


Inserire soltanto i link magari
Le faq vengono tradizionalmente postate su usenet una volta la settimana, 
per chi non ha/non vuole usare browser web, e per garantire che siano 
accessibili su dejanews (google groups) anche se il sito TIN e' giu'.
Per me e' indifferente.


 wrote in message
news:Xns91187BBA9F3...@194.19.1.61...


esempio 
Non si possono allegare messaggi su gruppi non binari. Peraltro, 
l'uuencoding renderebbe il tutto tre volte piu' ingombrante.
Nota che il subject e' *sempre* [FAQ] it.comp.java v....
Filtra i msg che iniziano con [FAQ] quando fai il download e. .voila'.


Si potebbe allegare un documento di testo zippato al messaggi oper esempio
Niente allegati. Solo sulla gerarchia it.binari.* sono ammessi, anche
se qualche server... va fuori specifica.
Allo stesso modo, niente messaggi HTML o MIME.
Qualcuno li riceve ugualmente, altri no (io ad es.): va tutto a
scapito di chi li spedisce... ;-)
-- 
Ciao
	Fabrizio C.