Newsgroup: it.comp.java
Titolo: Compilazione Condizionale

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. Un meccanismo simile, insomma, a quello messo a disposizione dal
C.
Grazie, Rick.

 ha scritto nel messaggio
news:a6go7s$jr7$1...@lacerta.tiscalinet.it...

La compilazione non appartiene a Java, ma a software accesori che compilano
i sorgenti in questo linguaggio notoriamente interpretato,....
Puoi riformularmi la domanda....

 wrote in message
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


In Java non c'è nulla di simile al preprocessore del C.
ciao
tityrus

 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

 ha scritto nel messaggio
news:afTi8.19527$tC3.5...@twister1.libero.it...

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.
Grazie, Rick.

 ha scritto nel messaggio
news:b3f7f768e182f4a8b3e...@mygate.mailgate.org...

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?
Grazie, Rick.

 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.


 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

 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è.....

 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.

 tradotte in bytecode in base a determinate condizioni.
Come gia' ti hanno detto, usa un preprocessore C.



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

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.
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

  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 :-)

La mia speranza č che diventino presto parte delle nostre CPU :-)
Sfortunatamente Intel va a braccetto con Microsoft.....purtroppo...

 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à....



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

 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. :-)


 alcuna utilità.
L'utilità arriva nel momento in cui in fase di test vuoi inserire un certo
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.

 parti dipendenti dalla piattaforma.
Quello e' solo *un* modo di usare il preprocessore.



Giusto, ma la stessa cosa succede se usi un precompilatore :-)
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.


 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.


 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à.

 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.

 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...

 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. :)


 dall'os va per "cavoli suoi"; il bytecode no.
Lo strato application, che io sappia, sta al di fuori del kernel,
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.

>
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 :-)


 Spero di non aver capito male :-)
Tu che dici.... :)

 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....

 detto che il pc sia il futuro dell'informatica.
Bello....cmq per un bel pezzo nei processori Intel non ci sarà la JVM....

 io credo di no....
Allora mi sbaglio; quale č la differenza?

 Allora mi sbaglio; quale è la differenza?
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++,...

J> Emulazione = Interprete ?
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.)

 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.

 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".

 (The JavaTM Virtual Machine Specification 2nd ed.)
La prima implementazione del prototipo JVM emulava il set di istruzioni
della stessa in software ospitati da dispositivi portatili....Effettivamente
Java nasce per collegare tra loro elettrodomestici...

 (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...


 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...


Grazie per l'appoggio Jigi,
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

 sostieni questo, allora ho capito male, scusatemi.
Non particolarmente in quell'occasione, e soprattutto _non_ nel followup 
alla tua nota. :)


 send the sorgents files....