Compilazione Condizionale
Rick Hunter
parti del codice devono essere compilate solo se certe condizioni sono
verificate. Un meccanismo simile, insomma, a quello messo a disposizione dal
C.
Grazie, Rick.
Observer
"Rick Hunter" <bar...@Toglimi.tiscalinet.it> ha scritto nel messaggio
news:a6go7s$jr7$1...@lacerta.tiscalinet.it...
i sorgenti in questo linguaggio notoriamente interpretato,....
Puoi riformularmi la domanda....
Davide Bianchi
news:a6go7s$jr7$1...@lacerta.tiscalinet.it...
No, ma nessuno ti impedisce di mettere
#ifdef _SOMEVALUE_
...
#endif
nel sorgente e poi passare il file .java al precompilatore C
prima di compilarlo con javac. Io lo faccio (e' ottimo per
rimuovere tutti i System.err.out() prima di avere la
versione definitiva del sorgente).
Davide
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
tityrus
In Java non c'è nulla di simile al preprocessore del C.
ciao
tityrus
pole
"Observer" <nigh...@tiscalinet.it> wrote in message
news:afTi8.19527$tC3.5...@twister1.libero.it...
>
[...]
> La compilazione non appartiene a Java, ma a software accesori che
compilano
> i sorgenti in questo linguaggio notoriamente interpretato,....
... beh, non sarei cosě drastico :-). Dopotutto javac sta per "Java
compiler". Ok che si tratta di
bytecode, ma č pur sempre una compilazione. A parte il discorso del JIT
compiler, IMHO per linguaggio interpretato si intende un linguaggio in cui
viene interpretato direttamente il codice sorgente, come ad esempio
JavaScript o molti altri linguaggi di script.
In Java (credo) si parla piů propriamente di "macchina virtuale", quella per
cui il bytecode "č" codice macchina.
Il fatto che non ci sia precompilazione credo sia una scelta dettata da
altri motivi.
Spero di non aver detto troppe c*** :-)
Ciao a tutto il NG
pole
Rick Hunter
"Observer" <nigh...@tiscalinet.it> ha scritto nel messaggio
news:afTi8.19527$tC3.5...@twister1.libero.it...
compilato in bytecode dal javac (per l'appunto).
La mia domanda è quindi: esiste in java qualche costrutto che consenta di
indicare al javac che alcuni parti di codice non devono essere tradotte in
bytecode in base a determinate condizioni.
Grazie, Rick.
Rick Hunter
"Davide Bianchi" <dav...@davidebianchi.net> ha scritto nel messaggio
news:b3f7f768e182f4a8b3e...@mygate.mailgate.org...
come faccio a separe il precompilatore dal compilatore?
Grazie, Rick.
Davide Bianchi
> Scusa ma non so molto di c. Normalmente uso il vc++ o il gcc. In questi
> casi come faccio a separe il precompilatore dal compilatore?
Con il vc non ne ho idea, con gcc mi pare sia gcc -e, ma se fai un
gcc --help o man gcc te lo dice lui.
Cristiano Sadun
news:52c73a4715883f703e5...@mygate.mailgate.org:
> Con il vc non ne ho idea
cl /P <file>
--
Life's something u don't get out alive..
ObjectZone - http://space.tin.it/computer/csadun
Observer
certi
> > > parti del codice devono essere compilate solo se certe condizioni sono
> > > verificate. Un meccanismo simile, insomma, a quello messo a
disposizione
> > dal
> > > C.
> > La compilazione non appartiene a Java, ma a software accesori che
> compilano
> > i sorgenti in questo linguaggio notoriamente interpretato,....
> > Puoi riformularmi la domanda....
> Certo. In java non esiste compilazione in codice macchina ma il codice
viene
> compilato in bytecode dal javac (per l'appunto).
> La mia domanda è quindi: esiste in java qualche costrutto che consenta di
> indicare al javac che alcuni parti di codice non devono essere tradotte in
> bytecode in base a determinate condizioni.
Probabilmente non ho ancora capito il problema....scusami.
Cmq, la traduzione del sorgente in bytecode è l'operazione che rende
eseguibile dalla jvm la classe, tutto ciò che non è tradotto non è
eseguibile, e non avrebbe motivo d'esistere,.... Se vuoi far implementare 2
classi distinte a partire dallo stesso sorgente a seconda del verificarsi di
condizioni ben precise.... dovrai avere un programma a parte che intercetta
le condizioni, modifica in automatico il sorgente e lancia il compilatore
prima e la jvm dopo sulla nuova classe, ....
A priori questo tipo di programmazione è scorretto a dir poco,.... ma vorrei
sapere in pratica cosa ci devi fare e perchè.....
Observer
> compilano
> > i sorgenti in questo linguaggio notoriamente interpretato,....
>
> compiler". Ok che si tratta di
> compiler, IMHO per linguaggio interpretato si intende un linguaggio in cui
> viene interpretato direttamente il codice sorgente, come ad esempio
> JavaScript o molti altri linguaggi di script.
per
> cui il bytecode "è" codice macchina.
> Il fatto che non ci sia precompilazione credo sia una scelta dettata da
> altri motivi.
> Spero di non aver detto troppe c*** :-)
:)
La compilazione va vista in sintesi nel quadro della portabilità e della
compressione che ne deriva; se ti va potresti fare programmi direttamente in
bytecode.... o meglio crearti un editor ad oc. Dato che i sistemi basati su
jvm vanno considerati a parte, la jvm è per implementazione un
interprete....solo che ti è concesso di scrivere il sorgente in un modo
tanto semplice per l'uomo da essere difficilmente interpretato rispetto allo
specifico bytecode.
Nota: i linguaggi compilatori generano codice che messo in esecuzione
dall'os va per "cavoli suoi"; il bytecode no.
Cristiano Sadun
> La mia domanda è quindi: esiste in java qualche costrutto che consenta
> di indicare al javac che alcuni parti di codice non devono essere
> tradotte in bytecode in base a determinate condizioni.
Come gia' ti hanno detto, usa un preprocessore C.
Bruno Bossola
>Mi chiedevo se in java esiste un qualche modo per specificare che certi
>parti del codice devono essere compilate solo se certe condizioni sono
>verificate.
>
Qualcosa di simile e' possibile farlo sfruttando un'apposita peculiarita' del compilatore
java, che in certe documentate condizioni elimina il codice e non lo compila.
class Sample
{
static final boolean DEBUG = false;
public static void main(String args[])
{
if (DEBUG) System.out.println("[stampa di debug]");
System.out.println("Hello world!");
}
}
A conferma, decompilando con JAD si ottiene questo codice:
// Decompiled by Jad v1.5.7g. Copyright 2000 Pavel Kouznetsov.
// Jad home page: http://www.geocities.com/SiliconValley/Bridge/8617/jad.html
// Decompiler options: packimports(3)
// Source File Name: temp.java
import java.io.PrintStream;
class Sample
{
Sample()
{
}
public static void main(String args[])
{
System.out.println("Hello world!");
}
private static final boolean DEBUG = false;
}
E' sufficiente che la variabile sia final boolean e il sistema funziona: quando e' a false
il codice viene rimosso, quando e' a true viene compilato.
Ciao,
Bruno.
---
| Bruno Bossola
| A Java Software Engineer :-)
| http://digilander.iol.it/bbossola
Jigi
utilità in C nel fatto che lo stesso codice può così essere compilato su
piattaforme diverse condizionando la compilazione delle parti dipendenti
dalla piattaforma.
Essendo Java intrinsecamente astratto dalla piattaforma, ciò non ha più
alcuna utilità. In Java come certo saprai, sono state escluse una serie di
numerose feature già presenti in altri linguaggi, poiché ritenute (a torto o
a ragione) un surplus inutile che ne avrebbe soltanto complicato la
struttura.
Una delle caratteristiche di Java è in fatti quella di voler essere più
semplice, scaricandosi del peso di strutture che possono essere evitate
senza troppe rinunce da parte del programmatore. Io penso che probabilmente,
non avendo un background C non verrebbe mai in mente l'utilità della
preprocessazione alla compilazione, e non ne ho mai sentito la mancanza :-).
Ciao,
Luigi
Jigi
> interprete....
Forse era cosě una volta, ora molto del codice viene compilato in codice
nativo quando necessario, dalla JVM.
Poi non č propriamente corretto dire che Java č interpretato. Per come la
vedo io Java č un linguaggio compilato (javac), il cui codice č eseguito da
una macchina virtuale. Anche il bytecode puň essere successivamente
compilato in linguaggio nativo e molto spesso č proprio ciň che avviene in
memoria. Esistono microprocessori in grado di eseguire il bytecode cosě
com'č. La mia speranza č che diventino presto parte delle nostre CPU :-)
Observer
"Jigi" <rocky...@hotmail.com.nospam.org> ha scritto nel messaggio
news:a6j557$76k$1...@lacerta.tiscalinet.it...
> > la jvm č per implementazione un
> > interprete....
> Forse era cosě una volta, ora molto del codice viene compilato in codice
> nativo quando necessario, dalla JVM.
Che io sappia non č l'unico interprete che lo faccia...
> Poi non č propriamente corretto dire che Java č interpretato. Per come la
> vedo io Java č un linguaggio compilato (javac), il cui codice č eseguito
da
> una macchina virtuale.
Se ti chiamo il compilatore Pascal PascalVirtualMachine, secondo te
funzionano allo stesso modo....č interprete....fidati
> Anche il bytecode puň essere successivamente
> compilato in linguaggio nativo e molto spesso č proprio ciň che avviene in
> memoria.
....immagino tu sappia che differenza c'č tra JVM e JIT....
>Esistono microprocessori in grado di eseguire il bytecode cosě
> com'č.
....e sai cosa hanno implementato nei transistori della rom?.....un
interprete od un compilatore, secondo te?
>La mia speranza č che diventino presto parte delle nostre CPU :-)
Sfortunatamente Intel va a braccetto con Microsoft.....purtroppo...
Observer
> L'utilità di compilare una parte di codice in modo condizionale trova la
sua
> utilità in C nel fatto che lo stesso codice può così essere compilato su
> piattaforme diverse condizionando la compilazione delle parti dipendenti
> dalla piattaforma.
> Essendo Java intrinsecamente astratto dalla piattaforma, ciò non ha più
> alcuna utilità. In Java come certo saprai, sono state escluse una serie di
> numerose feature già presenti in altri linguaggi, poiché ritenute (a torto
o
> a ragione) un surplus inutile che ne avrebbe soltanto complicato la
> struttura.
mi risulta principalmente più che un surplus un potenziale fonte di problemi
per i newbies o la portabilità....dopotutto la gestione dei tread che in C
non c'è ....non è il maximum della semplicità....
pole
> :)
> La compilazione va vista in sintesi nel quadro della portabilità e della
> compressione che ne deriva; se ti va potresti fare programmi direttamente
in
> bytecode.... o meglio crearti un editor ad oc. Dato che i sistemi basati
su
> jvm vanno considerati a parte, la jvm è per implementazione un
> interprete....solo che ti è concesso di scrivere il sorgente in un modo
> tanto semplice per l'uomo da essere difficilmente interpretato rispetto
allo
> specifico bytecode.
> Nota: i linguaggi compilatori generano codice che messo in esecuzione
> dall'os va per "cavoli suoi"; il bytecode no.
>
Ciao Observer
grazie per la tua interessante spiegazione. Mi pare che si possa essere
d'accordo su questo:
1) Il linguaggio Java viene "compilato" in bytecode, che NON è codice
nativo;
2) Il bytecode risultante dalla compilazione viene "interpretato" a runtime
dalla JVM, che (credo) simula in tutto e per tutto (o quasi) una macchina
reale, creando un'astrazione che permette di vedere tutti i sistemi come se
fossero identici.
E' quello che si deduce anche dall'intro del tutorial della Sun
http://java.sun.com/docs/books/tutorial/getStarted/intro/definition.html
dove tra l'altro c'è scritto:
"You can think of Java bytecodes as the machine code instructions for the
Java Virtual Machine (Java VM). "
... che mi sembra ciò che intendevo io: il bytecode "è" codice macchina *per
la JVM*.
Mi pare però di capire che le specifiche della JVM diano libero spazio alle
modalità di esecuzione del bytecode, e qui rientrano i "compilatori" JIT che
creano al volo "codice nativo" specifico per la piattaforma su cui girano.
Ma una JVM potrebbe anche "essere" una macchina reale, come nel caso dei
processori PicoJava, e in questo caso il bytecode non sarebbe più
"interpretato" ma direttamente eseguito.
A questo punto mi pare chiaro che (all'interno delle specifiche Sun) non
siamo nel caso di un linguaggio puramente compilato (es. C ), ma neanche nel
caso "puramente interpretato" (es. JavaScript).
Spero di non aver capito male :-)
Ciao a tutti
pole
Cristiano Sadun
news:3c8cc916...@news.inet.it:
> E' sufficiente che la variabile sia final boolean e il sistema
> funziona: quando e' a false il codice viene rimosso, quando e' a true
> viene compilato.
L'unica cosa ad tener presente con quella tecnica e' che quando si usano
costanti (final static) queste vengono appunto considerate dal compilatore
...costanti per l'eternita', quindi il loro valore e' *copiato* in altre
classi che ne fanno uso. Di conseguenza, se il loro valore cambia, si
devono ricompilare *tutte* le classi che vi accedevano, pena bug fantasiosi
e apparentemente incomprensibili. :-)
Rick Hunter
news:a6j4gc$u26$1...@pegasus.tiscalinet.it...
sua
> utilità in C nel fatto che lo stesso codice può così essere compilato su
> piattaforme diverse condizionando la compilazione delle parti dipendenti
> dalla piattaforma.
> Essendo Java intrinsecamente astratto dalla piattaforma, ciò non ha più
> alcuna utilità.
numero di istruzioni di debug che nella release finale vuoi togliere per
rendere il codice più veloce senza doverti ripassare tutto il codice riga
per riga ed eliminarle a mano.
Ciao, Rick.
Cristiano Sadun
news:a6j4gc$u26$1...@pegasus.tiscalinet.it:
> L'utilitą di compilare una parte di codice in modo condizionale trova
> la sua utilitą in C nel fatto che lo stesso codice puņ cosģ essere
> compilato su piattaforme diverse condizionando la compilazione delle
> parti dipendenti dalla piattaforma.
Quello e' solo *un* modo di usare il preprocessore.
Bruno Bossola
>> funziona: quando e' a false il codice viene rimosso, quando e' a true
>> viene compilato.
>
>L'unica cosa ad tener presente con quella tecnica e' che quando si usano
>costanti (final static) queste vengono appunto considerate dal compilatore
>...costanti per l'eternita', quindi il loro valore e' *copiato* in altre
>classi che ne fanno uso. Di conseguenza, se il loro valore cambia, si
>devono ricompilare *tutte* le classi che vi accedevano, pena bug fantasiosi
>e apparentemente incomprensibili. :-)
>
Inoltre se sei un buon designer OO, e vuoi rispettare OCP
(http://www.objectmentor.com/resources/articles/ocp.pdf), le variabili le dichiari
private, e il problema non esiste.
Cristiano Sadun
> Giusto, ma la stessa cosa succede se usi un precompilatore :-)
Si', e' che con quello viene piu' naturale pensarci. :)
Bruno Bossola
>bbos...@hotmail.com (Bruno Bossola) wrote in
>news:3c8de0e9...@news.inet.it:
>
>> Giusto, ma la stessa cosa succede se usi un precompilatore :-)
>
>Si', e' che con quello viene piu' naturale pensarci. :)
>
Gia, ma tieni conto che se sviluppi OO (se ne applichi i principi la tua variabile non
sarà certamente pubblica) non hai il problema che descrivi tu, e lo scrivi in maniera
molto piu' chiara ed elegante. Questo conta, parecchio: lo preferisco _decisamente_ al
confronto di vedere nel mio codice sparse delle #if e #else.
In ogni caso, sicuramente si puo' risolvere in alternativa con una soluzione completamente
OO, ma in questo caso (ricordiamoci che dovremmo rispondere al post originale, altrimenti
apriamo pure un altro thread) sconsiglio l'uso di un precompilatore e consiglio invece
l'uso dell'apposita feature del linguaggio.
Jigi
> per i newbies o la portabilità....dopotutto la gestione dei tread che in C
> non c'è ....non è il maximum della semplicità....
Nessuno ti obbliga a scrivere applicazioni multithread, o
multipiattaforma o multilinguaggio. Il fatto che in Java ci sia un
framework per scrivere applicazioni multithread ha permesso
l'evoluzione verso J2EE, altrimenti molto più complicato se ogniuno
doveva scriversi la propria implementazione. Il fatto che tu usi per
esempio JSP, o EJB, non sempre vuol dire che conosci i problemi della
programmazione concorrente, eppure puoi farlo benissimo perché ci sono
livelli di astrazione che ti permettono di farlo. Se non ti interessa
scrivere un'applicazione multithread lo puoi benissimo fare. Però fai
lo stesso in C, e raccontami... E' tutta un'altra complessità.
Jigi
Emulazione = Interprete ?
> Che io sappia non è l'unico interprete che lo faccia...
Quindi è un demerito?
> ....immagino tu sappia che differenza c'è tra JVM e JIT....
Credo di sì, JVM usa proprio JIT per compilare in memoria sezioni di
bytecode per velocizzarne l'esecuzione.
La compilazione nativa, ne sono al corrente è un'altra roba.
> Sfortunatamente Intel va a braccetto con Microsoft.....purtroppo...
Un'azienda va sempre a braccetto con la tecnologia che gli offre
possibilità di business maggiore. Può darsi che oggi sia Microsoft,
può darsi che domani non lo sia più. Nessun impero dura per sempre. Il
mercato dei microprocessori su embedded e pda, non è certo guidato da
microsoft, e intel dovrà presto fare i conti con questa realtà. Non è
detto che il pc sia il futuro dell'informatica.
Jigi
> "Jigi" <rocky...@hotmail.com.nospam.org> wrote in
> news:a6j4gc$u26$1...@pegasus.tiscalinet.it:
>
> > L'utilitą di compilare una parte di codice in modo condizionale trova
> > la sua utilitą in C nel fatto che lo stesso codice puņ cosģ essere
> > compilato su piattaforme diverse condizionando la compilazione delle
> > parti dipendenti dalla piattaforma.
>
> Quello e' solo *un* modo di usare il preprocessore.
Ok... puņ essere il via per un progetto opensource (sempre che non
esisti gią) come make -> ant. Precompilazione multipiattaforma ? :-)
Nostalgia nostalgia canaglia...
Cristiano Sadun
> ricordiamoci che
> dovremmo rispondere al post originale, altrimenti apriamo pure un
> altro thread
LOL era appunto quello che mi limitavo a fare, non avendo tempo per altro:
un'informazione pratica.
*Se* il tizio ha deciso di - o e' abituato a - usare un preprocessore, e
decide di passare alla tecnica che indicavi, e' meglio che tenga presente
quel bit di informazione piuttosto che no, altrimenti finira' probabilmente
nelle grane ed il fatto che qualcuno gli dica "non hai fatto le cose da
buon designer OO" non lo aiutera' a togliersene. :-)
Non era una contestazione, o qualcosa che dicesse che il metodo da te
proposto non fosse valido. Ma *se* decide di usarlo (senza esperienza di
membri final static in Java) e' bene che sappia etc. Chiaro ora? :-)
Poi la comparazione tra preprocessore, uso di costanti, discussioni
sull'accessso eccetera sono interessantissime, ma sono un'altra cose e
appunto richiedono piu' tempo di quello che ho al momento. :)
Jigi
> dall'os va per "cavoli suoi"; il bytecode no.
poiché un'applicazione nativa si interfaccia all'OS per ottenere
servizi attraverso le chiamate di sistema. Quindi non va affatto per i
cavoli suoi. Vedendo le cose dal punto di vista Java, l'OS è la JVM.
Bruno Bossola
>proposto non fosse valido. Ma *se* decide di usarlo (senza esperienza di
>membri final static in Java) e' bene che sappia etc. Chiaro ora? :-)
>
anche la tua informazione non era completa, e ho ritenuto necessario completarla: ho
semplicemente detto che gli attributi _devono_ essere privati, e siccome non mi piace
imporre dall'alto alcunche', ho motivato questa euristica con un principio OO (ocp).
Tu pero' poi hai detto che viene piu' naturale pensare ad un precompilatore: beh, a me no,
e ho cercato di motivare pure questo, dichiarando anche quale soluzione sceglierei
personalmente e perche' (sempre a causa di OO). Ed e' questo il punto:
>
>Cristiano Sadun wrote:
>>Come gia' ti hanno detto, usa un preprocessore C.
>>
Qui non si sta discorrendo di "comparazione tra preprocessore e uso di costanti", ma si
sta cercando scegliere una soluzione ad un problema: il preprocessore e' la soluzione
peggiore. Invece, quel piccolo attributo boolean (privato) visto con gli occhi del
paradigma OO, incapsula, nasconde ed astrae in modo estremamente elegante la compilazione
condizionale, ed e' disponibile nativamente nel linguaggio. Quella e' la prima scelta. Hai
fatto bene ad evidenziarne i problemi, ma non altrettanto bene fai sostenendo l'uso di un
preprocessore, che gia' era penoso da usare in C. Se invece non sostieni questo, allora ho
capito male, scusatemi.
Questa e' la mia opinione, poi ovviamente, ci mancherebbe, chiunque usi o continui ad
usare quello che gli pare dopo avere letto le nostre riflessioni. E spero di essere stato
chiaro anche io :-)
Observer
runtime
> dalla JVM, che (credo) simula in tutto e per tutto (o quasi) una macchina
> reale,
> creando un'astrazione che permette di vedere tutti i sistemi come se
> fossero identici.
E i codici del processore da dove li prende ?....non è che per caso è
implementata per lo specifico sistema nel momento in cui la JVM viene
istallata ....
> E' quello che si deduce anche dall'intro del tutorial della Sun
> http://java.sun.com/docs/books/tutorial/getStarted/intro/definition.html
Non l'hai dedotto bene.... dopotutto però hai ragione ....è un
tutorial....dovrà pur dare qualche vaga idea....
> dove tra l'altro c'è scritto:
> "You can think of Java bytecodes as the machine code instructions for the
> Java Virtual Machine (Java VM). "
..."You can think of Basic codes as the machine code instructions for the
Basic Interpreter Virtual Machine (Basic IVM Non l'hai mai sentita?
Strano....), ...but you must know that it isn't"
> ... che mi sembra ciò che intendevo io: il bytecode "è" codice macchina
*per
> la JVM*.
Casomai per JOS montato sugli NC....
Stai fraintendendo dei concetti semplificati e distorti per i non addetti al
lavoro, ....cerca delle fonti più dettagliate....prova Thinking in Java.
> Mi pare però di capire che le specifiche della JVM diano libero spazio
alle
> modalità di esecuzione del bytecode,
> e qui rientrano i "compilatori" JIT che
> creano al volo "codice nativo" specifico per la piattaforma su cui
girano.
? cmq da i compilatori jit in poi è corretto...
> Ma una JVM potrebbe anche "essere" una macchina reale, come nel caso dei
> processori PicoJava,
Questa me la scrivo.... :)
> e in questo caso il bytecode non sarebbe più
> "interpretato" ma direttamente eseguito.
Sarebbe comunque interpretato....però se non ci vuoi credere ...
> A questo punto mi pare chiaro che (all'interno delle specifiche Sun) non
> siamo nel caso di un linguaggio puramente compilato (es. C ), ma neanche
nel
> caso "puramente interpretato" (es. JavaScript).
> Spero di non aver capito male :-)
Tu che dici.... :)
Observer
> Nessuno ti obbliga a scrivere applicazioni multithread, o
> multipiattaforma o multilinguaggio.
> Il fatto che in Java ci sia un
> framework per scrivere applicazioni multithread ha permesso
> l'evoluzione verso J2EE, altrimenti molto più complicato se ogniuno
> doveva scriversi la propria implementazione. Il fatto che tu usi per
> esempio JSP, o EJB, non sempre vuol dire che conosci i problemi della
> programmazione concorrente, eppure puoi farlo benissimo perché ci sono
> livelli di astrazione che ti permettono di farlo. Se non ti interessa
> scrivere un'applicazione multithread lo puoi benissimo fare. Però fai
> lo stesso in C, e raccontami... E' tutta un'altra complessità.
E per questo che Java parte dal c e c++ e ne migliora tanti aspetti....
Observer
> > funzionano allo stesso modo....è interprete....fidati
> Emulazione = Interprete ?
> > Che io sappia non è l'unico interprete che lo faccia...
> Quindi è un demerito?
no una cosa normale...
> > ....immagino tu sappia che differenza c'è tra JVM e JIT....
> Credo di sì, JVM usa proprio JIT per compilare in memoria sezioni di
> bytecode per velocizzarne l'esecuzione.
io credo di no....
> La compilazione nativa, ne sono al corrente è un'altra roba.
I compilatori che usano la compilazione JIT, compilano in linguaggio
macchina.....è accademica
> > Sfortunatamente Intel va a braccetto con Microsoft.....purtroppo...
> Un'azienda va sempre a braccetto con la tecnologia che gli offre
> possibilità di business maggiore. Può darsi che oggi sia Microsoft,
> può darsi che domani non lo sia più. Nessun impero dura per sempre. Il
> mercato dei microprocessori su embedded e pda, non è certo guidato da
> microsoft, e intel dovrà presto fare i conti con questa realtà. Non è
> detto che il pc sia il futuro dell'informatica.
Bello....cmq per un bel pezzo nei processori Intel non ci sarà la JVM....
Jigi
> > Credo di sě, JVM usa proprio JIT per compilare in memoria sezioni di
> > bytecode per velocizzarne l'esecuzione.
> io credo di no....
Observer
> > > Credo di sì, JVM usa proprio JIT per compilare in memoria sezioni di
> > > bytecode per velocizzarne l'esecuzione.
> > io credo di no....
Se JVM usasse JIT (immagino tu intenda dire che lo integra...) l'esecuzione
viene velocizzatya rispetto a cosa? ... Cmq JVM compila in memoria un
istruzione del Bytecode alla volta, quindi le interpreta; i compilatori JIT
compilano effettivamente tutto il codice delle classi interessate, prima
della loro esecuzione, cosi si che al momento dell'esecuzione si ottiene un
risparmio di tempo, ...anzi si raggiungono le velocità di esecuzione del
c++,...
Jigi
O>chi emulerebbe cosa?
Secondo me nel caso di JVM si parla più propriamente di emulazione che non
di interpretazione.
The first prototype implementation of the Java virtual machine, done at Sun
Microsystems, Inc., emulated the Java virtual machine instruction set in
software hosted by a handheld device that resembled a contemporary Personal
Digital Assistant (PDA).
(The JavaTM Virtual Machine Specification 2nd ed.)
Jigi
>> reale,
>? ...di quale JVM parli?....io non credo.....
The Java virtual machine is an abstract computing machine. Like a real
computing machine, it has an instruction set and manipulates various memory
areas at run time. It is reasonably common to implement a programming
language using a virtual machine; the best-known virtual machine may be the
P-Code machine of UCSD Pascal.
(The JavaTM Virtual Machine Specification 2nd ed.)
> lavoro, ....cerca delle fonti più dettagliate....prova Thinking in Java.
L'ho letto dalla prima all'ultima pagina. Dov'è che spiega quello che dici?
Non ricordo nulla di simile, ma rileggo volentieri il brano che spiega
quello che tu dici, se me lo indichi.
> > Ma una JVM potrebbe anche "essere" una macchina reale, come nel caso dei
> > processori PicoJava,
> Questa me la scrivo.... :)
Scrivilo bello grosso:
The Java virtual machine does not assume any particular implementation
technology, host hardware, or host operating system. It is not inherently
interpreted, but can just as well be implemented by compiling its
instruction set to that of a silicon CPU. It may also be implemented in
microcode or directly in silicon.
(The JavaTM Virtual Machine Specification 2nd ed.)
> > e in questo caso il bytecode non sarebbe più
> > "interpretato" ma direttamente eseguito.
> Sarebbe comunque interpretato....però se non ci vuoi credere ...
Note that the term "compiler" is sometimes used when referring to a
translator from the instruction set of a Java virtual machine to the
instruction set of a specific CPU. One example of such a translator is a
just-in-time (JIT) code generator, which generates platform-specific
instructions only after Java virtual machine code has been loaded.
(The JavaTM Virtual Machine Specification 2nd ed.)
> > A questo punto mi pare chiaro che (all'interno delle specifiche Sun) non
> > siamo nel caso di un linguaggio puramente compilato (es. C ), ma neanche
> > nel caso "puramente interpretato" (es. JavaScript).
> > Spero di non aver capito male :-)
> Tu che dici.... :)
Io sono d'accordo con lui.
Java è un linguaggio compilato, poiché sottoposto a compilazione e
assemblaggio di codice a basso livello per una macchina a stack. Che poi il
bytecode sia successivamente interpretato / tradotto (o tutt'è due come è
molto più comune) per essere eseguito su piattaforme diverse, questo lo
sappiamo tutti.
Per me, si tratta più propriamente di emulazione che non di interpretazione.
Spero di aver citato brani sufficientemente ufficiali da non dover essere
ritenuti "per non addetti ai lavori". Ai posteri l'ardua sentenza.
P.S.
Il tono di derisione è meglio tenerlo lontano da queste discussioni.
Jigi
l'esecuzione
> viene velocizzatya rispetto a cosa? ... Cmq JVM compila in memoria un
> istruzione del Bytecode alla volta, quindi le interpreta; i compilatori
JIT
> compilano effettivamente tutto il codice delle classi interessate, prima
> della loro esecuzione, cosi si che al momento dell'esecuzione si ottiene
un
> risparmio di tempo, ...anzi si raggiungono le velocità di esecuzione del
> c++,...
One example of such a translator is a
just-in-time (JIT) code generator, which generates platform-specific
instructions only after Java virtual machine code has been loaded.
Non tutto il codice, solo alcune sezioni. Inoltre JVM e JIT lavorano insieme
(mixed mode), e di fatto sono integrate nel JRE.
Quella di cui tu parli si chiama compilazione nativa, e non c'entra nulla
con la compilazione JIT che sta per Just In Time, non "tutto in un botto".
Observer
> The first prototype implementation of the Java virtual machine, done at
Sun
> Microsystems, Inc., emulated the Java virtual machine instruction set in
> software hosted by a handheld device that resembled a contemporary
Personal
> Digital Assistant (PDA).
> (The JavaTM Virtual Machine Specification 2nd ed.)
della stessa in software ospitati da dispositivi portatili....Effettivamente
Java nasce per collegare tra loro elettrodomestici...
Observer
> The Java virtual machine is an abstract computing machine. Like a real
> computing machine, it has an instruction set and manipulates various
memory
> areas at run time. It is reasonably common to implement a programming
> language using a virtual machine; the best-known virtual machine may be
the
> P-Code machine of UCSD Pascal.
> (The JavaTM Virtual Machine Specification 2nd ed.)
processore....altro che macchina hardware....
>
> > lavoro, ....cerca delle fonti più dettagliate....prova Thinking in Java.
> L'ho letto dalla prima all'ultima pagina. Dov'è che spiega quello che
dici?
> Non ricordo nulla di simile, ma rileggo volentieri il brano che spiega
> quello che tu dici, se me lo indichi.
Non l'ho mai letto , ....alcuni dicono che è il migliore....te l'ho
consigliato,....
> > > Ma una JVM potrebbe anche "essere" una macchina reale, come nel caso
dei
> > > processori PicoJava,
> > Questa me la scrivo.... :)
> Scrivilo bello grosso:
Ti rispondo poco sotto...
> The Java virtual machine does not assume any particular implementation
> technology, host hardware, or host operating system. It is not inherently
> interpreted, but can just as well be implemented by compiling its
> instruction set to that of a silicon CPU. It may also be implemented in
> microcode or directly in silicon.
> (The JavaTM Virtual Machine Specification 2nd ed.)
Deduco che tu non abbia studiato l'elettronica dei
microprocessori....quindi....nei processori viene implementata la JVM o
nalla rom come microcode (scritto nel vero linguaggio macchina del
processore) od implementata con transistor ed operazionali a formare il vero
e proprio core....nei picoJava si usa il microcode....che non ci crederai è
in sostanza sempre un interprete....
>
> > > e in questo caso il bytecode non sarebbe più
> > > "interpretato" ma direttamente eseguito.
> > Sarebbe comunque interpretato....però se non ci vuoi credere ...
> Note that the term "compiler" is sometimes used when referring to a
> translator from the instruction set of a Java virtual machine to the
> instruction set of a specific CPU. One example of such a translator is a
> just-in-time (JIT) code generator, which generates platform-specific
> instructions only after Java virtual machine code has been loaded.
> (The JavaTM Virtual Machine Specification 2nd ed.)
Porca vacca....ma capisci l'italiano....cioè l'inglese....i JIT sono
compilatori e si leggono tutto il il bytecode del programma e lo traducono
in linguaggio macchina..... la jvm non si avvale di essi,....non li
integra,....non ci fa un...vabbe hai capito...
Observer
> just-in-time (JIT) code generator, which generates platform-specific
> instructions only after Java virtual machine code has been loaded.
> Non tutto il codice, solo alcune sezioni. Inoltre JVM e JIT lavorano
insieme
> (mixed mode), e di fatto sono integrate nel JRE.
il mixed mode è UN modo di operare, ...sono integrate per semplificarti la
vita...
>
> Quella di cui tu parli si chiama compilazione nativa, e non c'entra nulla
> con la compilazione JIT che sta per Just In Time, non "tutto in un botto".
I Jit generano codice che peraltro viene salvato su disco tanto che se
riavvi il programma non dove essere ricompilato...
pole
news:a6m7f2$1u0$1...@pegasus.tiscalinet.it...
[...]
> Io sono d'accordo con lui.
> Java è un linguaggio compilato, poiché sottoposto a compilazione e
> assemblaggio di codice a basso livello per una macchina a stack. Che poi
il
> bytecode sia successivamente interpretato / tradotto (o tutt'è due come è
> molto più comune) per essere eseguito su piattaforme diverse, questo lo
> sappiamo tutti.
> Per me, si tratta più propriamente di emulazione che non di
interpretazione.
>
> Spero di aver citato brani sufficientemente ufficiali da non dover essere
> ritenuti "per non addetti ai lavori". Ai posteri l'ardua sentenza.
>
> P.S.
> Il tono di derisione è meglio tenerlo lontano da queste discussioni.
>
anch'io pensavo si discutesse solo per approfondire le nostre conoscenze :-/
In ogni caso è stata un'occasione di crescita (da un po' di punti di vista
:-))
Buon lavoro
pole
Cristiano Sadun
> Su questo sono d'accordo, ed era chiaro pure prima. Da parte mia ho
> solo rilevato che anche la tua informazione non era completa, e ho
> ritenuto necessario completarla: ho semplicemente detto che gli
> attributi _devono_ essere privati, e siccome non mi piace imporre
> dall'alto alcunche', ho motivato questa euristica con un principio OO
> (ocp).
Benone.
>
> Tu pero' poi hai detto che viene piu' naturale pensare ad un
> precompilatore:
Ridendo.. tutto sommato la cosa e' irrilevante, ma, giusto per il gusto
della discussione: rileggi, rileggi: :-)
<quote>
>Giusto, ma la stessa cosa succede se usi un precompilatore :-)
Si', e' che con quello viene piu' naturale pensarci. :)
</quote>
Nel contesto, "con quello" in italiano mi pare si intenda chiaramente:
significa "quando si usa un preprocessore viene piu' naturale pensarci",
dove il "-ci" sta per "ricompilare tutto quando si cambia una
#define/costante", che era anche lui chiaro, nel contesto.
Non certo "viene naturale pensare ad un preprocessore" (anzi, a me viene
talmente innaturale pensare a cpp in Java, che tempo fa dovettero dirmelo,
proprio su questo ng).
Nemmeno ho mai detto che il preprocessore e' la soluzione giusta, o la
migliore. Nell'altro subthread ho semplicemente detto "usa il
preprocessore", senza decorazione alcuna - proprio perche' non volevo
entrare in una discussione comparativa argomentata. Avrei potuto dire "usa
sed" - che pero' e' in genere meno immediato. :-)
LOL.. se c'e' qualcosa che e' evidente, nei miei post, e' quando
*argomento* qualcosa o quando no. ;-)
> Qui non si sta discorrendo di "comparazione tra preprocessore e uso di
> costanti",
Infatti, non quello di cui discorrevo io, me per quanto riguarda te,
cosa...
> ma si sta cercando scegliere una soluzione ad un problema:
> il preprocessore e' la soluzione peggiore.
..se no? :-)
In brevissimo, sull'uso del preprocessore, nel contesto adatto, non sarei
affatto cosi' apodittico - anzi. Da quando l'idea mi fu presentata qui
l'anno scorso, ho provato, osservato, e rivalutato certe mie precedenti
opinioni. Che sono ancora in evoluzione. Come dicevo, motivare il perche' e
il percome richiede tempo che al momento non ho. Quindi, per una volta la
mia opinione viene cosi', nuda e cruda - chi la vuole prendere, la prenda,
chi non la vuole, fatti suoi. :-)
(Semplicemente, esci un momento dal tuo appartamento mentale e *osserva* il
mondo. Ci sono letteralmente migliaia di applicazioni C/C++ che fanno uso
saggio del preprocessing. Ce ne sono altrettante che ne fanno un uso
pessimo. Ora, cerca di individuare le proprieta' comuni agli "usi saggi", e
vedere se se ne puo' trasportare qualcuno in Java.. ;-).
> Hai fatto bene ad evidenziarne
> i problemi,
Che era l'unico mio scopo. Il tizio prende la soluzione X, imho e' bene
indicarli i potenziali problemi anche se si decide di *non* illustrare
tutte le possibili soluzioni alternative ad X o farne una comparazione
dettagliata. :-)
> ma non altrettanto bene fai sostenendo l'uso di un
> preprocessore, che gia' era penoso da usare in C. Se invece non
> sostieni questo, allora ho capito male, scusatemi.
Non particolarmente in quell'occasione, e soprattutto _non_ nel followup
alla tua nota. :)
Jigi
> > quello che tu dici, se me lo indichi.
> consigliato,....
E' un ottimo consiglio, seguilo.
> > The Java virtual machine does not assume any particular implementation
> > technology, host hardware, or host operating system. It is not inherently
> > interpreted, but can just as well be implemented by compiling its
> > instruction set to that of a silicon CPU. It may also be implemented in
> > microcode or directly in silicon.
> > (The JavaTM Virtual Machine Specification 2nd ed.)
> Deduco che tu non abbia studiato l'elettronica dei
> microprocessori....quindi....nei processori viene implementata la JVM o
> nalla rom come microcode (scritto nel vero linguaggio macchina del
> processore) od implementata con transistor ed operazionali a formare il vero
> e proprio core....nei picoJava si usa il microcode....che non ci crederai č
> in sostanza sempre un interprete....
Deduci bene, non č il mio business.
> > > > e in questo caso il bytecode non sarebbe piů
> > > > "interpretato" ma direttamente eseguito.
> > > Sarebbe comunque interpretato....perň se non ci vuoi credere ...
> > Note that the term "compiler" is sometimes used when referring to a
> > translator from the instruction set of a Java virtual machine to the
> > instruction set of a specific CPU. One example of such a translator is a
> > just-in-time (JIT) code generator, which generates platform-specific
> > instructions only after Java virtual machine code has been loaded.
> > (The JavaTM Virtual Machine Specification 2nd ed.)
> Porca vacca....ma capisci l'italiano....cioč l'inglese....i JIT sono
> compilatori e si leggono tutto il il bytecode del programma e lo traducono
> in linguaggio macchina..... la jvm non si avvale di essi,....non li
> integra,....non ci fa un...vabbe hai capito...
Prenderň ripetizioni di elettronica e inglese; tu fa lo stesso:
"Observer" <nigh...@tiscalinet.it> wrote in message news:<B_8j8.2309$1S3....@twister1.libero.it>...
> send the sorgents files....