Newsgroup: it.comp.java
Titolo: eseguibile in java

Ciao a tutti
ammetto di essere abbastanza newbie della proggramazione Java e vorrei una 
mano su una cosa che non ho capito.
Una volta che abbiamo compilato i file *.java da javac e abbiamo proceduto a 
lanciare l'applicazione con java  nomeProgramma la versione del programma in 
questione gira sul nostro computer.
Ora se ho realizzato, diciamo una apllicazione che vorrei eseguire su n 
numero di computer diverso dal mio, dovrei creare un file tip .exe per 
distrubuire l'applicazione stessa.
Come posso fare questo?
Ho visto, seguendo i vari tutorial, che se sul computer č installata la JVM 
potrň, far eseguire il mio programma....ma come?
Non penso che debba copiare in toto tuti i file creati da Netbeans o 
similia, ma creare una specie di istanza di quello che ho creato.
Grazie a chi vorrŕ rispondermi e scusate se la mia domanda potŕ sembare 
banale, mi sto appassionando a questo linguaggio e sono alle prime armi :-) 

 JVM potrò, far eseguire il mio programma....ma come?
Con il classico comando: java nomeClassePrincipale
In alternativa potresti realizzare un file JAR che racchiude tutta la tua 
applicazione; in questo modo distribuisci un unico file.
Se Windows ha associato i file JAR alla JVM, allora facendo doppio click il 
programma parte "da solo".
Ciao
Marco 

 il programma parte "da solo".
Ciao e grazie per aver risposto
Creando un jar, mi chiedo, chi ha il programma sulla macchina non può andare 
a modificare il programma stesso??
Come posso fare ad escludere questa possibilità? 

 Come posso fare ad escludere questa possibilità?
Tieni presente che un file JAR non è altro che uno ZIP rinominato.
Quindi lo si può scompattare ed accedere ai singoli file .class.
Tali file sono però compilati quindi non c'è modo di accedere ai sorgenti.
Tuttavia, mediante la riflessione, è possibile ricavare tutti i prototipi 
dei metodi delle classi.
Inoltre, con un buon disassemblatore sarebbe possibile ricavare in qualche 
modo i tuoi sorgenti.
Tuttavia non ne ho mai provato, quindi non so fino a che punto siano 
efficaci.
Ciao
Marco 


Lo sono. Mettere in rete un jar (o i files class che lo compongono) č quasi 
come mettere in rete i sorgenti. 

 quasi come mettere in rete i sorgenti.
Aò, ma d'altronde il programma non si può mica dettare per telefono! :-)
Ciao
Marco 

>>>> "n" == napo  <na...@NOPRIVATEMESSAGE.com> writes:
n> Tieni presente che un file JAR non è altro che uno ZIP rinominato.
n> Quindi lo si può scompattare ed accedere ai singoli file .class.
n> Tali file sono però compilati quindi non c'è modo di accedere ai
n> sorgenti.
Purtroppo (o per fortuna) non è linguaggio nativo ed il bytecode della
JVM è stato  pensato per essere compatto <=>  avere una corrispondenza
praticamente biunivoca col sogente.
n> Inoltre, con un buon disassemblatore sarebbe possibile ricavare in
n> qualche modo i tuoi sorgenti.
Senza qualche modo.  Ci sono degli offuscatori che  cercano di mandare
in bomba i  decompilatori. Ma in ogni caso, non  si riesce a resistere
ad un programmatore determinato a riottenere il sorgente.
A questo punto, a parer  mio, conviene pubblicare i sorgenti sotto una
licenza libera, vendere il proprio lavoro e non il prodotto e giovarsi
dei contributi altrui.
-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico  
\/		    e allevatore di bug da competizione

scusate...ma tutte le belle cose che ho letto circa incapsulamento del 
codice, possibilità e quasi cura maniacale per non far sì che l'utente 
finale possa manipolare i sorgenti che leggo nei vari manuali / tutorials 
dove sta?
Concordo con la politica Open Source ma che utilità avrebbe rendere pubblici 
i sorgenti di un programmino che stampa fatture? 

Mi sa che confondi il "public" di Java con il codice pubblico.

 ad un programmatore determinato a riottenere il sorgente.
Gli offuscatori non impediscono al decompilatore di generare il codice
sorgente. Il loro compito è quello di rendere il codice
incomprensibile fondamentalmente rinominando nel bytecode package,
classi, metodi, fields, etc...
Il programmatore non avrebbe quindi difficoltà ad ottenere il sorgente
ma semmai a capirci qualcosa.
Il problema principale è che in molti casi il codice non si può
offuscare, o comunque non si può offuscare abbastanza da renderlo
davvero incomprensibile (e nel contempo funzionante). Pensa ad esempio
ai tipi istanziati dinamicamente, ai bean e alle loro proprietà.

 dove sta?
Mai sentita una cosa del genere. A che ti riferisci?

 writes:
ML> l'utente finale possa manipolare i sorgenti che leggo nei vari
ML> manuali / tutorials dove sta?
Non la  hai capita  allora.  Quella è  una questione  di manipolazione
degli oggetti nel  flusso del programma, affinché avvenga  nei modi in
cui   è  ragionevolmente   sicuro  che   non  si   creino   errori  di
programmazione. Non ha nulla a che vedere con l'accesso ai sorgenti da
parte di umani.
ML>  Concordo con la politica Open
ML> Source ma che utilità avrebbe rendere pubblici i sorgenti di un
ML> programmino che stampa fatture?
Qui c'è un errore di fondo.
Open  Source non  è altro  che un  "marchio commerciale"  per Software
Libero, ai fini  delle licenze ammesse sotto i  due termini non cambia
praticamente nulla.
E il  Software Libero non  è libero perché  è pubblicato al  mondo, ma
perché agli  utenti sono date quattro precise  libertà (uso, modifica,
di  redistribuzione e  di  redistribuzione delle  modifiche). La  cosa
importante non è che l'utente le usi, ma che non gli vengano negate.
Poi parte di un programma che stampa fatture potrebbe benissimo essere
usata per risolvere un'altro problema, magari completamente diverso...


> resistere ad un programmatore determinato a riottenere il sorgente.
VV> Gli offuscatori non impediscono al decompilatore di generare il
VV> codice sorgente.
Non prenderla come  una volontà di polemizzare con  te, ma mi parrebbe
di  aver  letto che  alcuni  offuscatori  riescano  ad inserire  delle
"polpette avvelenate" in grado di far malfunzionare il decompilatore.
Mi pare di aver letto la cosa relativamente a mocha e creme, ma potrei
aver letto male.


 "polpette avvelenate" in grado di far malfunzionare il decompilatore.
AFAIK un decompilatore è sempre in grado di risalire al sorgente dal
bytecode, perchè il bytecode è così.
L'offuscatore in primis fa in modo che il sorgente ottenuto non sia
quello originale, in secondis che sia un sorgente umanamente
incomprensibile. Per un periodo ne provai diversi su richiesta di una
azienda e al di là di constatare che è una enorme rottura di scatole
(quanto il gioco vale la candela?) sono sempre riuscito a passare da
.class a .java e di nuovo .class.

> decompilatore.
VV> AFAIK un decompilatore è sempre in grado di risalire al sorgente
VV> dal bytecode, perchè il bytecode è così.
Bingo, ritrovata!
Mocha  can't  generate  code  from  any Java  class  file  which  been
processed  by Crema, another  well known  products written  by Mocha's
writer, because of the "bomb" Crema set, but SourceTec Java Decompiler
can.
http://www.sothink.com/product/javadecompiler/
A naso  Crema inserisce  un metodo nuovo  (che nessuno  invoca, magari
pure privato) che, una volta entrato  "in pancia" a Mocha lo fa andare
in errore. Non ho provato, non so dire.
In ogni caso anche la bomba è stata aggirata...
vv>  L'offuscatore in primis
VV> fa in modo che il sorgente ottenuto non sia quello originale, in
VV> secondis che sia un sorgente umanamente incomprensibile. 
Lo so. Ne ho sconfitto uno in passato :). Un programmatore determinato
lo può fare,  e se poi il codice  è di un'applet la cosa  è ancora più
facile.
Io rimango dell'idea che il codice deve essre libero :)


E mo esistono anche gli offuscatori? Wow :-) 

 writes:
ML> E mo esistono anche gli offuscatori? Wow :-)
Si, li hanno creati per l'intinseca decompilabilità di Java.
