2012-08-31 11 views
5

Stavo considerando se un progetto Java poteva produrre 2 jars: uno per java7 e uno per java6, sì, il codice sorgente potrebbe usare alcune nuove funzionalità java7.Possiamo usare jdk7 javac per compilare il codice con le caratteristiche java7 bytecode java6

modo per generare il vaso java6, la riga di comando sarebbe come:

javac -target 1.6 -bootclasspath jdk1.6.0\lib\rt.jar -extdirs "" MyApp.java 

Sfortunatamente, emette semplicemente un errore:

javac: target release 1.6 conflicts with default source release 1.7 

Secondo this document, dovrebbe essere possibile per jdk6 vs jdk5, qualcuno sa perché non funziona in jdk7 vs jdk6? ho fatto qualcosa di sbagliato, o è solo ufficialmente non supportato?

Grazie.

+2

[Questa è la documentazione cross-compilation per Java 7.] (http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#crosscomp-example) 'OldCode. si prevede che java' venga scritto sul livello sorgente di destinazione. La sintassi IIRC, Java 5 e Java 6 sono le stesse. – McDowell

+0

@McDowell che significa che il codice sorgente non dovrebbe contenere nessuna nuova funzionalità java7, giusto? –

+0

corretto. Se stai cercando di scegliere come target Java 6 con il codice Java 7, probabilmente dovrai consultare uno strumento di terze parti specializzato. – McDowell

risposta

5

AFAIK, la fonte e l'obiettivo devono essere gli stessi. Anche per Java 6. L'unica eccezione è la sorgente può essere 1.1 e la target 1.0.

Dato che la JVM presenta poche differenze tra l'ultima JVM per Java 6 e Java 7, suggerisco di considerare l'aggiornamento. Anche Java 6 sarà, End Of (gratuito) di servizio nel novembre 2012, che tre mesi da oggi ...

+1

d'accordo. aggiornamento o downgrade. la cross-compilazione è molto dolorosa. – Thilo

+1

@PeterLawrey "Nov 2010, che tra tre mesi." Siamo tornati indietro nel tempo? e perché sono bloccato nel 2012 ?? :) Scusa non potevo aiutare me stesso. – JTMon

+0

@ JTMon Sono appena tornato! Non in Cina, ovviamente, perché è illegale lì. ;) –

2

Anche se fosse possibile in genere è una cattiva idea - se vuoi essere sicuro che il tuo codice funzionerà java 6 quindi devi crearlo su java 6. Ogni nuova versione di java introduce nuove classi nella libreria di classi e aggiunge nuovi metodi alle classi esistenti, e anche se si imposta il compilatore java 7 per generare un bytecode compatibile con 6 ha vinto 'prendi i casi in cui chiami un metodo solo 7.

+0

* "non rileverà i casi in cui si chiama un metodo solo 7". * Lo sarà sicuramente se si utilizza l'opzione 'bootclasspath' correttamente. –

+1

Vero, ma se hai a disposizione un'installazione di Java 6 in modo da poter mettere le sue librerie di classi sul bootclasspath di Java 7, allora perché non limitarti a compilare e utilizzare Java 6 in primo luogo ... –

+1

* "Java 6 installazione "* Per installazione si intende JDK. Bootclasspath può funzionare con 'rt.jar' per un precedente JRE ** installato o, ancora più importante, il' rt.jar'della versione precedente, senza 'install' necessario. Se si stanno compilando i codici per 1.7 e 1.6, oltre a un codice per i dispositivi legacy che eseguono 1.3, è molto più semplice gestire un gruppo di Jars in fase di esecuzione rispetto a un gruppo di JDK installati (con un gruppo di 'java. home' valori e ..). –

Problemi correlati