Come si può distribuire un gioco Java desktop senza una dipendenza del runtime Java?

È possibile trasformare un'applicazione Java in un pacchetto autonomo che funziona "out of the box"? All'utente finale non dovrebbe essere richiesto di installare alcun Java JRE, né il programma di installazione dovrebbe contenere un JRE e installarlo per l'utente.

La distribuzione finale dovrebbe contenere un eseguibile nativo (si spera uno per ciascuno di Windows, Mac e Linux) insieme ai normali file di dati e agli eventuali JAR extra, se necessario. Non sto cercando una soluzione "a un solo file", in realtà vorrei che i file di dati venissero non offuscati.

Come si può fare?

java distribution

— leokhorn
fonte

Risposte:

Il punto principale è che all'utente finale non dovrebbe essere richiesto di installare alcun Java JRE, né il programma di installazione dovrebbe contenere un JRE e installarlo per l'utente

È possibile utilizzare Java source / bytecode per compilare codici macchina. Esistono Excelsior JET per Windows e Linux (richiede licenza) e GNU Compiler per Java che è vecchio.

Se è ok contenere Java con il tuo gioco senza installarlo, allora probabilmente puoi impacchettare Java Runtime con il tuo gioco e usare uno script di avvio per impostare la JAVA_HOMEtua posizione JRT prima di lanciare il gioco.

EDIT: (risposta ai commenti) Usando la seconda opzione, avrai comunque bisogno di build diverse per piattaforme diverse usando il runtime Java appropriato per quella piattaforma.

EDIT2: Anche vedere il recente commento di Dmitry.

— Eren Güven
fonte

Se il tuo gioco non è commerciale, puoi ottenere una licenza Excelsior JET gratuita .

— Dmitry Leskov,

La seconda opzione suona bene, ma se impacchettino il mio Windows JRE, è multipiattaforma? Analogamente a Excelsior, avrei bisogno di eseguire tali compilatori su tre diversi sistemi operativi?

— leokhorn,

Dovresti raggruppare le piattaforme JRE con ogni versione, ma essenzialmente rimarrà su più piattaforme.

— Derek,

@leokhorn Ad un certo punto, ci deve essere un codice nativo. O è necessario compilare il codice nativo oppure eseguire su una macchina virtuale nativa. Non esiste un piano C.

— Adrian,

GCJ è ora ufficialmente morto , mentre l'Excelsior JET Standard Edition è diventata gratuita anche per uso commerciale , anche se la tua unica preoccupazione è la facilità di distribuzione, ci sono molte alternative

— Dmitry Leskov

Per Mac, consultare la documentazione Oracle per il confezionamento di un'app Java per Mac . Hanno impostato Java 7 in modo da poter raggruppare il runtime in un bundle di applicazioni contenente i file jar (.app è una cartella trattata come eseguibile realmente), necessaria per la distribuzione sul Mac App Store. Fondamentalmente, il pacchetto .app fa quasi lo stesso di quello che suggerisce la risposta JAVA_HOME di Eren, ma è confezionato come un'app Mac "nativa".

Per la distribuzione senza Mac App Store, puoi evitare di non firmare l'app, dicendo ai tuoi utenti Mountain Lion che possono aggirare Gatekeeper facendo clic con il pulsante destro del mouse (o ctrl + clic) sulla tua app e facendo clic su "Apri" quando prima apri l'app. Ciò li avvertirà comunque che l'app non è firmata, ma consentirà comunque loro di aprirla e quindi consentirà loro di fare doppio clic sull'app per le successive aperture.

(nota a margine: si potrebbe anche cavarsela con la marcatura in stile Linux degli script di shell come eseguibile e quindi costruire un pacchetto .app attorno a quello. NetBeans lo fa su Mac e Linux, anche se senza un JRE / JDK in bundle)

— Il granchio
fonte