La creazione di file di classe Java è deterministica?

Quando si utilizza lo stesso JDK (ovvero lo stesso javaceseguibile), i file di classe generati sono sempre identici? Può esserci una differenza a seconda del sistema operativo o dell'hardware ? Ad eccezione della versione JDK, potrebbero esserci altri fattori che determinano differenze? Esistono opzioni del compilatore per evitare differenze? C'è una differenza solo in teoria o Oracle javacproduce effettivamente file di classe diversi per le stesse opzioni di input e compilatore?

Aggiornamento 1 Mi interessa la generazione , cioè l'output del compilatore, non se un file di classe può essere eseguito su varie piattaforme.

Aggiornamento 2 Con "Stesso JDK", intendo anche lo stesso javaceseguibile.

Update 3 Distinzione tra differenza teorica e differenza pratica nei compilatori Oracle.

[MODIFICA, aggiunta di una domanda parafrasata]
"Quali sono le circostanze in cui lo stesso eseguibile javac, se eseguito su una piattaforma diversa, produrrà un bytecode diverso?"

Mettiamola così:

Posso facilmente produrre un compilatore Java completamente conforme che non produce mai lo stesso .classfile due volte, dato lo stesso .javafile.

Potrei farlo modificando tutti i tipi di costruzione di bytecode o semplicemente aggiungendo attributi superflui al mio metodo (cosa consentita).

Dato che la specifica non richiede che il compilatore produca file di classe identici byte per byte, eviterei di dipendere da tale risultato.

Tuttavia , le poche volte che ho controllato, la compilazione dello stesso file sorgente con lo stesso compilatore con le stesse opzioni (e le stesse librerie!) Ha prodotto gli stessi .classfile.

Aggiornamento: di recente mi sono imbattuto in questo interessante post sul blog sull'implementazione di switchon Stringin Java 7 . In questo post del blog, ci sono alcune parti rilevanti, che citerò qui (enfasi mia):

Al fine di rendere l'output del compilatore prevedibile e ripetibile, le mappe e set utilizzati in queste strutture dati sono LinkedHashMaps e LinkedHashSets piuttosto che solo HashMapse HashSets. In termini di correttezza funzionale del codice generato durante una data compilazione, usare HashMape HashSetandrebbe bene ; l'ordine di iterazione non ha importanza. Tuttavia, troviamo vantaggioso che javacl'output di non vari in base ai dettagli di implementazione delle classi di sistema .

Questo illustra abbastanza chiaramente il problema: al compilatore non è richiesto di agire in modo deterministico, purché corrisponda alle specifiche. Gli sviluppatori del compilatore, tuttavia, si rendono conto che in genere è una buona idea provare (a condizione che non sia troppo costoso, probabilmente).

Non vi è alcun obbligo per i compilatori di produrre lo stesso bytecode su ciascuna piattaforma. Dovresti consultare l' javacutilità dei diversi fornitori per avere una risposta specifica.

Mostrerò un esempio pratico per questo con l'ordinamento dei file.

Diciamo che abbiamo 2 file jar: my1.jare My2.jar. Vengono inseriti nella libdirectory, fianco a fianco. Il compilatore le legge in ordine alfabetico (poiché questo è lib), ma l'ordine è my1.jar, My2.jarquando il file system non fa distinzione tra maiuscole e minuscole e My2.jar, my1.jarse distingue tra maiuscole e minuscole.

L' my1.jarha una classe A.classcon un metodo

public class A {
     public static void a(String s) {}
}

Lo My2.jarha lo stesso A.class, ma con diversa firma del metodo (accetta Object):

public class A {
     public static void a(Object o) {}
}

È chiaro che se hai una chiamata

String s = "x"; 
A.a(s); 

compilerà una chiamata al metodo con una firma diversa in casi diversi. Quindi, a seconda della sensibilità al maiuscolo / minuscolo del tuo filesystem, otterrai come risultato una classe diversa.

Risposta breve - NO

Risposta lunga

Non è bytecodenecessario che siano gli stessi per piattaforme diverse. È il JRE (Java Runtime Environment) che sa esattamente come eseguire il bytecode.

Se segui la specifica Java VM , verrai a sapere che non è necessario che il bytecode sia lo stesso per piattaforme diverse.

Passando attraverso il formato del file di classe , mostra la struttura di un file di classe come

ClassFile {
    u4 magic;
    u2 minor_version;
    u2 major_version;
    u2 constant_pool_count;
    cp_info constant_pool[constant_pool_count-1];
    u2 access_flags;
    u2 this_class;
    u2 super_class;
    u2 interfaces_count;
    u2 interfaces[interfaces_count];
    u2 fields_count;
    field_info fields[fields_count];
    u2 methods_count;
    method_info methods[methods_count];
    u2 attributes_count;
    attribute_info attributes[attributes_count];
}

Controllo della versione minore e principale

minor_version, major_version

I valori degli elementi minor_version e major_version sono i numeri di versione minore e maggiore di questo file di classe. Insieme, un numero di versione maggiore e uno secondario determinano la versione del formato del file di classe. Se un file di classe ha il numero di versione principale M e il numero di versione minore m, indichiamo la versione del suo formato di file di classe come Mm Pertanto, le versioni del formato di file di classe possono essere ordinate lessicograficamente, ad esempio 1.5 <2.0 <2.1. Un'implementazione di Java virtual machine può supportare un formato di file di classe della versione v se e solo se v si trova in un intervallo contiguo Mi.0 v Mj.m. Solo Sun può specificare quale intervallo di versioni può supportare un'implementazione di Java virtual machine conforme a un determinato livello di rilascio della piattaforma Java

Leggendo di più attraverso le note a piè di pagina

1 L'implementazione della Java virtual machine della versione 1.0.2 di JDK di Sun supporta le versioni del formato file di classe dalla 45.0 alla 45.3 inclusa. Le versioni JDK di Sun 1.1.X possono supportare formati di file di classe delle versioni comprese tra 45.0 e 45.65535 incluse. Le implementazioni della versione 1.2 della piattaforma Java 2 possono supportare formati di file di classe delle versioni comprese tra 45.0 e 46.0 incluse.

Quindi, indagare su tutto ciò mostra che i file di classe generati su piattaforme diverse non devono essere identici.

In primo luogo, non esiste assolutamente alcuna garanzia del genere nelle specifiche. Un compilatore conforme potrebbe indicare l'ora della compilazione nel file di classe generato come attributo aggiuntivo (personalizzato) e il file di classe sarebbe comunque corretto. Tuttavia, produrrebbe un file diverso a livello di byte su ogni singola build, e banalmente.

In secondo luogo, anche senza questi fastidiosi trucchi, non c'è motivo di aspettarsi che un compilatore faccia esattamente la stessa cosa due volte di seguito a meno che sia la sua configurazione che il suo input non siano identici nei due casi. La spec non descrivono il nome del file di origine come uno degli attributi standard, e l'aggiunta di righe vuote al file di origine potrebbe cambiare la tabella di numero di riga.

In terzo luogo, non ho mai riscontrato differenze nella build a causa della piattaforma host (a parte quella attribuibile alle differenze in ciò che era sul classpath). Il codice che varia in base alla piattaforma (cioè, le librerie di codice nativo) non fa parte del file di classe e la generazione effettiva del codice nativo dal bytecode avviene dopo il caricamento della classe.

In quarto luogo (e soprattutto) puzza di un cattivo odore di processo (come l' odore di un codice, ma per come si agisce sul codice) volerlo sapere. Esegui la versione del codice sorgente, se possibile, non della build e, se è necessario eseguire la versione della build, versione a livello di intero componente e non sui singoli file di classe. Preferibilmente, usa un server CI (come Jenkins) per gestire il processo di trasformazione della sorgente in codice eseguibile.

Credo che, se si utilizza lo stesso JDK, il byte code generato sarà sempre lo stesso, senza relazione con l'harware e il sistema operativo utilizzato. La produzione del codice byte viene eseguita dal compilatore java, che utilizza un algoritmo deterministico per "trasformare" il codice sorgente in codice byte. Quindi, l'output sarà sempre lo stesso. In queste condizioni, solo un aggiornamento del codice sorgente influenzerà l'output.

Nel complesso, devo dire che non vi è alcuna garanzia che la stessa sorgente produrrà lo stesso bytecode quando compilata dallo stesso compilatore ma su una piattaforma diversa.

Analizzerei scenari che coinvolgono lingue diverse (code-page), ad esempio Windows con supporto per la lingua giapponese. Pensa a caratteri multibyte; a meno che il compilatore non presuma sempre di dover supportare tutti i linguaggi, potrebbe ottimizzare per ASCII a 8 bit.

C'è una sezione sulla compatibilità binaria nella specifica del linguaggio Java .

Nell'ambito della compatibilità binaria da rilascio a rilascio in SOM (Forman, Conner, Danforth e Raper, Proceedings of OOPSLA '95), i binari del linguaggio di programmazione Java sono compatibili con i binari sotto tutte le trasformazioni rilevanti che gli autori identificano (con alcuni avvertimenti con rispetto all'aggiunta di variabili di istanza). Usando il loro schema, ecco un elenco di alcune importanti modifiche compatibili con i binari che il linguaggio di programmazione Java supporta:

• Reimplementazione di metodi, costruttori e inizializzatori esistenti per migliorare le prestazioni.

• Modifica di metodi o costruttori per restituire valori sugli input per i quali in precedenza generavano eccezioni che normalmente non dovrebbero verificarsi o non sono riuscite entrando in un ciclo infinito o provocando un deadlock.

• Aggiunta di nuovi campi, metodi o costruttori a una classe o interfaccia esistente.

• Eliminazione di campi, metodi o costruttori privati ​​di una classe.

• Quando viene aggiornato un intero pacchetto, l'eliminazione di campi di accesso, metodi o costruttori di classi e interfacce predefiniti (solo pacchetto) nel pacchetto.

• Riordinare i campi, i metodi o i costruttori in una dichiarazione di tipo esistente.

• Spostare un metodo verso l'alto nella gerarchia delle classi.

• Riordinare l'elenco delle superinterfacce dirette di una classe o interfaccia.

• Inserimento di nuovi tipi di classe o interfaccia nella gerarchia dei tipi.

Questo capitolo specifica gli standard minimi per la compatibilità binaria garantita da tutte le implementazioni. Il linguaggio di programmazione Java garantisce la compatibilità quando i binari di classi e interfacce sono misti che non si sa provengono da sorgenti compatibili, ma le cui sorgenti sono state modificate nei modi compatibili qui descritti. Si noti che stiamo discutendo la compatibilità tra le versioni di un'applicazione. Una discussione sulla compatibilità tra le versioni della piattaforma Java SE esula dallo scopo di questo capitolo.

Java allows you write/compile code on one platform and run on different platform. AFAIK ; questo sarà possibile solo quando il file di classe generato su una piattaforma diversa è uguale o tecnicamente uguale, cioè identico.

modificare

Quello che intendo tecnicamente con lo stesso commento è questo. Non è necessario che siano esattamente gli stessi se si confrontano byte per byte.

Quindi, come da specifica, il file .class di una classe su piattaforme diverse non ha bisogno di corrispondere byte per byte.

Per la domanda:

"Quali sono le circostanze in cui lo stesso eseguibile javac, se eseguito su una piattaforma diversa, produrrà un bytecode diverso?"

L' esempio di Cross-Compilation mostra come possiamo usare l'opzione Javac: -target version

Questo flag genera file di classe che sono compatibili con la versione Java specificata durante l'invocazione di questo comando. Quindi i file di classe differiranno a seconda degli attributi che forniamo durante la compilazione usando questa opzione.

Molto probabilmente, la risposta è "sì", ma per avere una risposta precisa, è necessario cercare alcune chiavi o la generazione di guide durante la compilazione.

Non riesco a ricordare la situazione in cui questo accade. Ad esempio, per avere un ID per scopi di serializzazione, è hardcoded, cioè generato dal programmatore o dall'IDE.

PS Anche JNI può importare.

PPS Ho scoperto che javacè scritto in java. Ciò significa che è identico su piattaforme diverse. Quindi non genererebbe codice diverso senza una ragione. Quindi, può farlo solo con le chiamate native.

Ci sono due domande.

Can there be a difference depending on the operating system or hardware? 

Questa è una domanda teorica e la risposta è chiaramente sì, è possibile esserci. Come altri hanno già detto, la specifica non richiede che il compilatore produca file di classe identici byte per byte.

Anche se ogni compilatore attualmente esistente producesse lo stesso codice byte in tutte le circostanze (hardware diverso, ecc.), La risposta domani potrebbe essere diversa. Se non si prevede mai di aggiornare javac o il sistema operativo, è possibile testare il comportamento di quella versione in circostanze particolari, ma i risultati potrebbero essere diversi se si passa, ad esempio, da Java 7 Update 11 a Java 7 Update 15.

What are the circumstances where the same javac executable, when run on a different platform, will produce different bytecode?

È inconoscibile.

Non so se la gestione della configurazione è il motivo per cui poni la domanda, ma è un motivo comprensibile per preoccuparti. Il confronto dei codici byte è un controllo IT legittimo, ma solo per determinare se i file di classe sono cambiati, non per determinare se i file di origine lo hanno fatto.

La metterei in un altro modo.

In primo luogo, penso che la domanda non sia sull'essere deterministici:

Ovviamente è deterministico: la casualità è difficile da ottenere in informatica e non c'è motivo per cui un compilatore la introduca qui per nessun motivo.

Secondo, se lo riformuli in base a "quanto sono simili i file bytecode per uno stesso file codice sorgente?", Allora No , non puoi fare affidamento sul fatto che saranno simili .

Un buon modo per assicurarti di ciò è lasciare il .class (o .pyc nel mio caso) nel tuo stadio git. Ti renderai conto che tra i diversi computer del tuo team, git nota le modifiche tra i file .pyc, quando non sono state apportate modifiche al file .py (e .pyc comunque ricompilato).

Almeno questo è quello che ho osservato. Quindi metti * .pyc e * .class nel tuo .gitignore!