Newsgroup: it.comp.java
Titolo: Perchè Java ?

Non capisco quale grosso vantaggio si ha nel utilizare una JVM anzihč
compilare in codice macchina. 
In teoria creare una JVM per ogni piattaforma č tanto laborioso quanto
lo č creare un compilatore Java per ogni piattaforma; in pratica,
essendo la JVM scritta con un linguaggio di alto livello ed esistendo
un compilatore C o C++ per ogni piattaforma il porting di una JVM č
meno impegnativo ma rimane sempre da creare il JIT che deve ottenere
il codice macchina.
Dal momento che Java č un linguaggio molto ben strutturato e non
consente operazioni di basso livello come il C/C++, i progetti non
perderebbero portabilitą se venissero compilati in linguaggio macchina
anzichč in bytecode. Il ruolo della JVM potrebbe essere facilmente
sostituito da ua libreria per l'interfacciamento con il S.O. e i
drivers di basso livello. Questa sarebbe l'unica parte di codice da
ricompilare ed eventualmente adattare ad una piattaforma specifica.
lluminatemi sul perchč della JVM.
Grazie 1000.

 compilare in codice macchina.
Perchč non potresti prendere un jar da una macchina Windows e spostarlo su
una Solaris o Linux senza ricompilarlo. E la portabilitą č uno dei punti
chiave di Java.
Ciao,
 Stefano
----------
"X WindowSSS, teSSSoro mio... lo odieremo per SSSempre"
Bill Gollum
----------

 compilare in codice macchina. 
Prova a dare un'occhiata sul sito della SUN a quello che fanno le classi 
RMI *Remote Method Invocation*
E un esempio di perche JAVA.
Ciao,
Magellano

 ha scritto nel messaggio
news:3df4560...@powernews.libero.it...

Quello che hai detto andrebbe bene se ci limitiamo a un programma scritto
unicamente per girare in una macchina singola. Se perņ incominci a pensare
alle RMI, a Jini, alla proprietą java.rmi.server.codebase allora incominci a
capire il ruolo fondamentale di una JVM attiva.

 ricompilare ed eventualmente adattare ad una piattaforma specifica.
Tu chiedi un codice che se pur nativo sia portabile proprio grazie alla
mancanza di operazioni di basso livello; a mio avviso questo codice è 
proprio il bytecode e se hai problemi di perfomance quindi, tanto vale
ottimizzare quello.
Mi sembra che siano presenti ottimizzatori per quasi tutti gli OS, anche
se personalmente non ritengo Java un linguaggio tanto + lento di altri se
gestito correttamente.
Per Applet/RMI/ApplicationServer etc. guardati un po' di documentazione e 
ne capirai di + 
ciao
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

Scusate se m'intrometto...
Intanto voglio precisare che sono nuovo al Java, e provengo dal mondo C++...
Sinceramente ho provato ultimamente applet (abbastanza stupide) in java,
trovando tremendamente noioso l'aspettare cosě tanto per far sě che
l'interprete carichi la classe...
non riesco proprio a sincerarmi del fatto che il mondo dell'informatica da
un lato s'affanni a studiare metodi e algoritmi veloci e a prova di bomba
( es. teorie dell' O(n), algoritmi di fast-sorting, fast parsing etc..)
sviluppo di circuiti ultraveloci etc... Invece con la filosofia JVM tutta
questa fatica fatta dai vecchi kruscal, dijkstra, chomsky č andata via,
volatilizzata, perchč? se un linguaggio č portabile, non si puň compilare su
ogni OS e rendere la vita facile a tutto il mondo?(come avviene in c++). se
esiste un motivo valido affinchč sia meglio un interprete ad un codice da
compilare su varie piattaforme, vi prego convincetemi!
DANIELE
Ps. ancora non ho capito la scelta di impedire al programmatore JAVA di
liberare personalmete la memoria e di far intervenire il gc, scusate se mi
permetto ma questa situazione mi ricorda tanto il bambino di 6 anni che
prende i suo giocattoli, ci smanetta un poco e poi quando ha finito se ne va
via lasciando alla mamma l'onere di mettere a posto...

liberare personalmete la memoria e di far intervenire il gc, 
A questo punto saremmo ancora nel campo minato del C++, il codice Java
è garbage collected apposta per dover evitare al programmatore l'onere
di controllare tutti i riferimenti degli oggetti e liberarli di
conseguenza per evitare i famosi "memory-leaks"; non vedo perchè si
debba per forza tornare indietro. Con le macchine che abbiamo ora la
differenza non è cosi abissale come poteva esserlo nel 1991 tra
un'applicazione C++ e una Java, se non sbaglio ormai l'hw ha un costo
irrisorio rispetto al software
Rhymes

 mettere a posto... 
Bah, io invece la vedo un po' diversa. Mi ricorda una coppia che lavora 
tutto il giorno e prende una governante per tenere a posto la casa. 

 ahimè il primo approccio al linguaggio è quasi sempre quello.
Meno male che io sto nel quasi :( Non ho mai avuto una buona opinione
delle applet anche quando non conoscevo Java
Rhymes
--------------------------------
Inviato via 
http://usenet.libero.it

 delle applet anche quando non conoscevo Java
Almeno fino ad un po' di tempo fa, quando uno si avvicinava a java per un 
bel po' di tempo poteva rimanere convinto che con java non si potesse 
scrivere su disco...
Non nego che gli applet abbiano un loro impiego, solo che io li ho sempre 
visti molto, molto limitati come principio (programmi distribuiti che 
girano sul client, con tutti i limiti di sicurezza e pesantezza).

 via lasciando alla mamma l'onere di mettere a posto...
Soldi, soldi e soldi. Supponi, per un attimo, di essere un project manager,
o anche un cliente.
La tua esigenza primaria non e' di avere dei programmi ferrari, ma e' quella
di avere dei programmi affidabili, ad un prezzo contenuto, con una
manutenzione non troppo costosa. Quindi, non avrai piacere ad avere dei
programmatori che passano il loro tempo a capire dove possa avvenire il
memory leak, o in quale punto del codice/ in quali casi possa avvenire
l'accesso ad una zona di memoria non ancora allocata. Inoltre, un
programmatore esperto in C++ costa anche parecchio, per cui...
In pratica, cerca di guardare la situazione dal punto di vista di gestione
dei costi, piuttosto che da quello della voglia di dimostrare di essere un
ottimo programmatore C++, e la situazione ti sara' piu' chiara.
Ciao,
Luigi :)
p.s.:
non te la prendere, anche a me piace molto il C++, solo che bisogna
rassegnarsi all'idea che i linguaggi sono degli strumenti di lavoro, ed ogni
strumento e piu' adatto a svolgere determinati compiti piuttosto che altri.
Il programma real-time, per esempio, probabilmente verra' scritto in C++ (o
in C).
p.p.s.:
hai mai avuto una idea di come si complica la gestione dinamica della
memoria quando ci sono in gioco le eccezioni? Dai una occhiata al libro
"Exception C++", e forse inizierai a chiederti se e' il caso di dedicare
tanta parte del tuo tempo e delle tue energie mentali a fare cose che
potrebbe benissimo fare un garbage collector!

 cose che potrebbe benissimo fare un garbage collector!
In C/C++ proprio per questa ragione lo stile "predominante" è un punto di 
uscita per ogni funzione/metodo. Ci sono più correnti di pensiero a 
proposito, ma è evidente che il memoryleak è sempre in agguato. Le 
eccezioni sono una mazzata tremenda da questo punto di vista, io 
personalmente non riesco a farne uso in C++ sebbene costituiscano il modo 
migliore (secondo me) per gestire gli errori applicativi.

 mettere a posto... 
La scelta ha una motivazione semplicissima: dato un programmatore medio, si 
aumenta la produttivita' a parita' di sforzo o si diminuisce lo sforzo a 
parita' di produttivita'. Se riesci a toglierti per un momento dai 
paraocchi del programmatore ("questo linguaggio e' migliore di quell'altro, 
questa libreria e' migliore di quell'altra") ti accorgi che, in IT, questo 
e' estremamente importante.
-- 
Life's something u don't get out alive..
ObjectZone - 
http://space.tin.it/computer/csadun


Daniele

 tutto il giorno e prende una governante per tenere a posto la casa.
Peccato che il lavoro del programmatore sia la memoria; il programmatore è
il bambino, non il genitore!
(cmq la tua confutazione è carina!)
Dan

 migliore (secondo me) per gestire gli errori applicativi.
non ho mai parlato male del gc,ne dell'uso dell'aritm su punt. ... ho
semplicemente detto che reputo utile fornire la possibilità al programmatore
di deallocare expl.
Dan

 Peccato che il lavoro del programmatore sia la memoria; 
Il lavoro del programmatore è realizzare il programma. Gestire la memoria è 
(eventualmente) una necessità.

 di non poter deallocare quando io voglio mi sembra una gran stronzata.
Immagino non avrai problemi a spiegare perchè.


def. di  O( f(n) )
n     := quantità degli elementi
f(n) := funzione che calcola il costo di un algoritmo rispetto ad n
O(...) := significa che per ottenere il costo dell'algoritmo IMPLEMENTATO
bisogna moltiplicare (in genere) f(n) per un valo scalare dipendente dalla
macchina e dalla piattaforma.
ora converrai con me che usare una VM comporta una crescita esponenziale di
O( f(n) ) pur non variando f(n).
inoltre c'è una differenza abissale tra il concetto di algoritmo e quello di
implementazione di un Alg.


 Peccato che il lavoro del programmatore sia la memoria;
Il lavoro del programmatore è realizzare il programma. Gestire la memoria è
(eventualmente) una necessità.
-------------------------------------------------
ti sei risposto da solo :-)
Dn

 non ho mai parlato male del gc,ne dell'uso dell'aritm su punt.... 
Che c'entra l'aritmetica dei puntatori? Lo sai di cosa stavo parlando, 
vero?

 ti sei risposto da solo :-)
Vediamo un esempio più terra-terra.
Il lavoro di un tassista è portare a giro le persone. Cambiare l'olio alla 
macchina è una necessità. Il fatto che il tassista porta la macchina in 
officina a cambiare l'olio non significa che non faccia bene il suo lavoro. 

 ha scritto nel messaggio
news:Xns92E94329F34...@195.31.190.131...

porcavacca (chiedo scusa agli induisti) ho toppatto di brutto, mi riferivo a
:
-----------------
p.p.s.:
hai mai avuto una idea di come si complica la gestione dinamica della
memoria quando ci sono in gioco le eccezioni? Dai una occhiata al libro
"Exception C++", e forse inizierai a chiederti se e' il caso di dedicare
tanta parte del tuo tempo e delle tue energie mentali a fare cose che
potrebbe benissimo fare un garbage collector!
--------------------------
nn ho la + pallida idea di come habbia fatto a sbagliarmi, scusami, è il bug
della mezzanotte :-)
Dan

Scusami, O(f(n)) e' semplicemente una notazione per indicare la complessita'
asintotica (di un algoritmo o di un problema, specificato caso per caso).
O( f(n) )    ==     O( m * f(n) )
dove m e' una costante.
Dato che una virtual machine, ad una prima analisi, mi sembra che aggiunga
solo un fattore moltiplicativo (m) al tempo di esecuzione di una istruzione,
mi sembra che la complessita' asintotica sia identica.
Ciao,
Luigi
"** !! GnaSKuRu !! **" <gnask...@SPAMlibero.it> ha scritto nel messaggio
news:agOL9.26276$TC5.8...@twister1.libero.it...


 non ho proprio capito il nesso (*). Che centra il costo sw/hw?
Parlo degli ambiti in cui Java è utilizzato (il thread si intitola
Perchè Java :). Se sostituissimo il C++ (per quanto si può..) al Java
avremmo applicazioni più performanti ma anche costi di sviluppo
maggiori (ponendo un costo X per il sw di sviluppo C++ e un uguale
costo X per quello Java dovremmo aggiungere nel caso C++ un costo Y
maggiore per la formazione o il reperimento di programmatori esperti
che nel caso di Java sarebbe di certo minore). Quindi alla fine della
torta avremmo si un'applicazione leggermente più performante (che
probabilmente non ci serve a nulla) ma con costi (software + umani)
maggiore. Dato che un processore potente e un pò di ram costano di
meno di un programmatore C++.... :-)
Rhymes

 quello di implementazione di un Alg.
No, non c'e' differenza "abissale", perlomeno con architetture simili e 
all'interno di paradigmi simili - senno' l'idea di valutare algoritmi con 
la loro complessita' non l'userebbe nessuno. Ammenoche' la tua archiettura 
di calcolo non sia a carbonella.. ;-)


 Daniele
Giuseppe
-- 
__/\__ * this mail has been written by Talpa Stellare
\ TS / * che da piccolo una volta e' morto.
 |/\|  * icq# 78630739 - togli i caratteri maiuscoli x e-mail

>>liberare personalmete la memoria e di far intervenire il gc,
Serve a evitare errori di programmazione. Come metafora, potrei dire che 
in alcune biblioteche i lettori possono prelevare libri dagli scaffali, 
ma non gli e' consentito rimettere i libri al loro posto; tale attivita' 
e' riservata al personale. Lo scopo e' prevenire errori di collocamento 
dei libri.
La garbage collection obbligatoria non esiste solo in Java, ma anche in 
Smalltalk, Eiffel, C# e in tutti i linguaggi di scripting.
Comunque, sono daccordo con te nel ritenere il C++ sia superiore al Java 
come linguaggio di implementazione di algoritmi (sia numerici che non 
numerici). Ma la maggior parte dei programmatori non implementa 
algoritmi, li usa per implementare applicazioni. Se tutti gli algoritmi 
che servono sono implementati nella libreria standard, il problema si 
riconduce a chiedersi con quale linguaggio deve essere implementata la 
libreria standard.
-- 
	Carlo Milanesi
 
http://digilander.libero.it/carlmila