modificare .jar con classe personalizzata

[agmama]

Ciao a tutti,

premetto che sono a digiuno con Java. Conosco altri linguaggi di programmazione ma questo per me � il primo approccio con java.

Per necessit� devo implementare via web (quindi tramite applet java) un sistema automatico di scansione di documenti attraverso lo scanner, e, in seguoto upload sul server. Per fare questo sto utilizzando Morena 7 (http://www.gnome.sk/Morena/morena.html) che con qualche piccola modifica fa esattamente quel che mi serve.

Ora passiamo ai problemi. Ho un file .jar contenente i .class e funziona tutto correttamente. Ho un file .java (MorenaStudio.java) con una classe di esempio. Come faccio ad aggiungere questo file nel file jar e sostituire quindi la classe esistente con la mia modificata? io ho fatto delle prove ma probabilmente sbaglio qualcosa.

Se pu� servire io ho fatto cos�:

- modificato il file .java
- compilato il file con il comando: javac -classpath c:\test\scan\lib\morena7.jar MorenaStudio.java
- a seguito della compilazione mi si creano correttamente i vari file .class
- inserisco i file nel jar: jar uf morena7.jar *.class
- eseguo il file .jar che prima funzionava, e ora non succede nulla di nulla.

Ora... dopo il passaggio 3 (quindi dopo la compilazione del file .java) se io apro con winzip il file .jar e ci sovrascrivo i file .class con i file appena generati, funziona tutto ma non credo sia la procedura corretta. Altra anomalia: se eseguo direttamente da windows morena7.jar con la procedura "non corretta" se lo eseguo su windows funziona (e mi prende correttamente le modifiche) se lo eseguo da browser come applet java non funziona e mi da errore (ovviamente il file originale invece funziona correttamente)

Suggerimenti?

Grazie in anticipo

 

[ottofonsuppost]

Cosa è una applet
http://www.iet.unipi.it/a.bechini/master.it/docs/02_Applets.pdf


Il tag utilizzato per inserire un applet in una pagina HTML è il seguente.

<applet code=”MioApplet.class” width = x height = y ></applet>


MioApplet.class rappresenta il BYTECODE (programma compilato) dell’Applet “MioApplet.java” che la Java Virtual Machine dovrà interpretare ed eseguire all’interno del browser. width è la larghezza; height è l’altezza che occuperà l’Applet nel browser.

Un Applet è una applicazione Java eseguita all’interno di un browser; e non contiene il metodo main. Un Applet è come un oggetto multimediale(immagini, video, ecc.).

PRIMA IPOTESI:
Java non è abilitato nel browser Web. Se Java è già installato ma le applet non funzionano, è necessario abilitare Java tramite il browser Web.
ATTENZIONE ATTENZIONE : A partire dalla versione 42 (rilasciata ad aprile 2015), Chrome ha disabilitato il metodo standard in cui i browser supportano i plugin.
Quindi utilizzare il browser INTERNET EXPLORER dando le relative abilitazioni

https://www.java.com/it/download/faq/chrome.xml


SECONDA IPOTESI
Strategia per risolvere il problema.




Ti salvi in un blocco note le istruzioni di codice buono, poi apri il FILE JAVA CHE DEVI BUTTARE;
ti segni tutti i nomi delle variabili, dei metodi e le confronti con il file nuovo. Ma in teoria dovresti vedere anche tutti gli altri file che compongono il pacchetto per vedere se alcuni di questi chiamavano le variabili, i metodi, o se derivavano dalla classe sostituita.

CANCELLI TUTTE LE ISTRUZIONI VECCHIE, e ci incolli le nuove istruzioni, e poi lo compili di nuovo.
Di solito in queste manovre, rimangono in vita pezzi di istruzioni del vecchio file, a cui aggiungiamo pezzi di istruzioni del nuovo file.

il vecchio file faceva: dormire, mangiare, costruire, lavare
il nuovo file fa: dormire, passeggiare, correre.

quindi dovremo nel nuovo file, copiare il: mangiare, costruire, lavare.
Per riutilizzare pezzi di istruzioni già scritte che non vanno in conflitto.

La soluzione migliore in manovre di questo tipo, è creare una NUOVA CLASSE, che deriva o estende, la classe che vogliamo togliere, e tenere nel pacchetto la classe che vogliamo togliere.

Anche fare l'ESTENSIONE del vecchio file, facendo derivare la nuova classe dalla vecchia, non ci assicura la presenza di conflitti che minano la stabilità del codice.

 

[agmama]

Ciao Ottofonsuppost,

grazie della risposta. Però, non ho capito

Io in pratica ho il file jar con i .class, e un .java con la classe "MorenaStudio" presente nel jar. Ho modificato il .java come mi serve, poi ho seguito i passaggi elencati sopra ma sbaglio sicuramente qualcoaa. Sono confuso perchè non ho capito cosa mi hai detto di fare

 

[ottofonsuppost]

Dimmi quale sistema operativo usi e se utilizzi un IDE? Scusami ma stavo guardando la finale di CHAMPIONS LEAGUE.

Facciamo un'ipotesi.
Abbiamo due file JAVA.
JAVAcattivo e JAVAbuono: togliamo JAVAcattivo e lo sostituiamo con JAVAbuono;
ma se dentro JAVAcattivo esiste una variabile ZETA, e tutti gli altri JAVA del pacchetto JAR chiamano la variabile ZETA, (mentre dentro JAVAbuono non esiste la variabile ZETA); allora ecco che il PROGRAMMA GENERALE avrà un buco di funzionamento.

Ancora per farti capire a cosa si va incontro.
Mettiamo che in JAVAcattivo esistono istruzioni particolari ad esempio i METODI LAVA e i METODI STIRA e, questi due metodi non esistono in JAVAbuono; ecco che quando gli altri JAVA chiamano i metodi LAVA e STIRA, non potranno eseguirli perchè con la sostituzione TU LI HAI FATTI SPARIRE.

Quindi per risolvere il buco di funzionamento, se esiste il buco, occorre accertarsi che cosa faceva JAVAcattivo, quali variabili utilizzava, quali metodi, quali istruzioni eseguiva, quali funzionalità aveva, e occorre scoprire cosa manca in JAVAbuono di tutte queste cose.

Può capitare che in JAVAbuono ci siano delle variabili A e B che sono già esistenti in altri JAVA del pacchetto JAR; o che vi siano dei metodi già esistenti negli altri JAVA del pacchetto; ad esempio sicuramente un errore che è facile compiere in questa manovra è mettere un JAVAbuono che ha il METODO MAIN, che sicuramente esiste già in un altro dei tanti JAVA del pacchetto.
In poche parole si corre il rischio di DUPLICARE istruzioni importanti, vitali, già esistenti. Ma tramite un IDE è facile accorgersi di ciò.

FACCIAMO FINTA CHE NON MANCHI NULLA. CHE TUTTO DOVREBBE FUNZIONARE.
Allora bisogna aprire il PROGETTO. che contiene il PACKAGE JAR, e ricompilarlo con un IDE.
Ecco che si creerà un nuovo JAR, un nuovo pacchetto, che funzionerà.

 

[ottofonsuppost]

Far funzionare uno JAR tramite riga di comando.

1. Rendi eseguibile il file .jar. Un file .jar si può rendere eseguibile riunendo i file class dell'applicazione Java che si vuole eseguire; i compilatori o le JVM (Java Virtual Machine, macchine virtuali in Java) sono in grado di utilizzare questi formati. I file .jar vengono eseguiti da Javaw (o Java Web Start). È necessario stabilire i punti di ingresso dell'applicazione all'interno del file .jar (un punto di ingresso è un file class che contiene la funzione principale della tua applicazione). Puoi impostare il punto di ingresso con il file manifest. Ecco come fare:
   • Il tool per gli archivi .jar imposta meta-inf/manifest.mf automaticamente come percorso del file .jar. Quando apri un file manifest standard, dovrebbe venire visualizzata la descrizione "Manifest-Version: 1.0, Created-By: 1.6.0 (Sun Microsystems Inc)"
     
     
   • Crea un file manifest addition (un file che aggiunge informazioni al file manifest) in Blocco Note (.txt). Digita Main Class: [Nome del pacchetto].[Nome della classe], sostituendo le parti fra parentesi quadre con le informazioni specifiche del tuo archivio (da immettere sotto forma di coppia attributo-valore).
     
     
   • Immetti questo comando nel prompt per modificare il file manifest in modo che includa il punto di ingresso dell'applicazione, sostituendo le parti tra parentesi quadre con i nomi dei file specifici: jar cfm [Nome del file .jar] [manifest-addition] [file di input].
     
     
   • Ricontrolla il file manifest. Dopo avere impostato il punto di ingresso, nella descrizione dovrebbe essere scritto "Manifest-Version: 1.0, Created-By: 1.6.0 (Sun Microsystems Inc), Main Class: [Nome del pacchetto].[Nome della classe]".
     
     
   • In alternativa, puoi impostare il punto di ingresso usando il tool per i .jar. Questo sovrascrive l'attributo Main-class nel file manifest. Immetti il seguente comando nel prompt: jar cfe [Nome del file .jar] [Nome del pacchetto] [Nome della classe con la funzione principale]
   
   
2. 
   3
   Esegui il tuo file .jar. Esegui il file .jar usando il seguente comando (il metodo principale per eseguire le applicazioni in Java): java -jar [Nome del file .jar]
   
   
3. 
   4
   Rendi il file .jar eseguibile tramite doppio click (opzionale). Per eseguire il file .jar tramite doppio click, imposta il percorso che porta a Javaw (o Java Web Start) come directory. Immetti il seguente comando nel prompt:C:\Program Files\Java\j2rex.y.z\bin\javaw.exe" -jar "%1" %*.
   
   

 

[ottofonsuppost]

L'utente ci dice che ha trasferito un file .java, MA FORSE SI E' DIMENTICATO di trasferire il file .class

Sostituire uno JAVA di un pacchetto JAR, ci porta incontro ad un programma GENERALE che non funziona, perchè il COMPILATORE DI JAVA crea un BYTECODE, che la VIRTUAL MACHINE eseguirà. Ma il BYTECODE prevedeva sequenze di istruzioni basate su JAVAcattivo, e noi sostituendolo abbiamo alterato il BYTECODE. Quindi è indispensabile buttare al secchio il BYTECODE e ricrearlo tramite la COMPILAZIONE DELL'INTERO PROGETTO. E per fare questo è meglio utilizzare un tool di sviluppo, un IDE.

Tutto questo discorso ci dice, che l'intero progetto va RICOMPILATO, altrimenti non funziona nulla.
Durante la RICOMPILAZIONE, un IDE ci segnalerà gli errori presenti, e noi potremo completare la manovra di sostituzione; che non consiste solo nel cambiare un file al PACCHETTO JAR.

p.s. IL BYTECODE magari ha creato usando il suo LINGUAGGIO MACCHINA dei riferimenti ad alcune variabili STATICHE o metodi STATICI, o metodi privati, proprio alla classe JAVAcattivo DICHIARATA PRIVATE, quindi non visibile a tutto il resto del programma.
Sostituendo JAVAcattivo, saltano tutti questi riferimenti. Quindi la VIRTUAL MACHINE si trova ad interpretare un BYTECODE errato, E TUTTO SI BLOCCA.
Appena la MACCHINA VIRTUALE va ad eseguire un'istruzione basata sulla classe JAVA SOSTITUITA, si vedrà utilizzare dei riferimenti, dei collegamenti, dei binari che non portano a nulla; a binari scomparsi; a binari morti.

Non si può pensare che sia sufficiente mettere lo stesso nome ad una classe per far funzionare la manovra di sostituzione.

JAVAcattivo: variabili Roma, Milano, Parigi + metodi JUVE-MILAN-INTER

JAVAbuono: variabili Frosinone, Anagni, Maratea + metodi CAGLIARI-CROTONE-PESCARA

Ecco che avere dentro JAVAbuono presenta problemi di questo tipo: tutte le variabili e i metodi di JAVAcattivo sono scomparsi, ma il BYTECODE li ha dentro; tutte le variabili e i metodi di JAVAbuono non sono presenti nel BYTECODE, perchè il programma generale BYTECODE non è stato ricompilato.
Ricompilare tutti i pezzetti JAVA uno alla volta, PEZZETTI CHE FUNZIONANO, non significa che il programma generale funzionerà.

Per farti capire ancora meglio cosa succede.
Abbiamo un programma fatto di tanti file JAVA; quindi abbiamo un pacchetto. il pacchetto è stato compilato e ha generato un BYTECODE GENERALE interpretabile dalla MACCHINA VIRTUALE.
IL BYTECODE fa i gelati.

Ora noi sostituiamo un pezzo del pacchetto: togliamo il cattivo e mettiamo il buono. Tutto il nuovo programma dovrebbe fare TAPPETI.
Ed invece ci fa i gelati. Perchè il BYTECODE GENERALE è quello precedente.

La forza di JAVA consiste che una volta creato il BYTECODE, lo possiamo portare questo BYTECODE, in qualsiasi altro PC, che ha sistemi operativi diversi dal nostro, E IL PROGRAMMA sotto forma di BYTECODE funzionerà perfettamente, SENZA caricare dentro i nuovi pc con sistemi operativi diversi dal nostro, tutti i file con estensione JAVA.

Quindi ti invito a riflettere sulla differenza tra PROGRAMMA.JAVA e PROGRAMMA.class.

Tutte le classi del pacchetto JAR sono state compilate, funzionano, ma sostituendo JAVAcattivo, abbiamo fatto sparire variabili, metodi che magari ora non esistono più, oppure abbiamo fatto sparire proprio la classe da cui altri FILE JAVA sono derivati o sono stati estesi.

Quindi, per PORTARE un programma da un computer sistema WINDOWS ad un computer sistema UNIX, o su due pc con sistema WINDOWS diversi WINDOWS XP e WINDOWS 7, dobbiamo trasferire il PACKAGE .jar, CHE CONTIENE TUTTI I FILE .class

 

[ottofonsuppost]

Nello JAR ci sono 5 classi: CLASSE 1 - CLASSE 2- CLASSE 3 - CLASSE 4 - CLASSE 5(cattiva)
La CLASSE 5(cattiva usa variabili di riferimento e metodi chiamandoli alla CLASSE 1.

Noi, sostituendo CLASSE5(cattiva), con una CLASSE5(buona) potremo andare incontro ad una cosa del genere:

la Classe5(buona) non ha all'interno la chiamata alle variabili di riferimento e ai metodi della CLASSE 1

Quindi è inutile dire che la CLASSE 5(buona) l'abbiamo testata e funziona; perchè messe insieme tutte le classi, il programma ha un buco di funzionamento.

Quindi occorre sapere tutto su cosa conteneva e faceva la CLASSE 5(cattiva), per poi provvedere a modificare le istruzioni della CLASSE 5(buona) e ripristinare le variabili cancellate, i metodi cancellati, e le funzionalità assenti nel programma generale.

Ma tutto si può fare; basta sapere cosa stiamo facendo, quali errori abbiamo commesso e come si fa a ripararli.
Baci e abbracci, OTTOFONSUPPOST.

 

[ottofonsuppost]

https://msdn.microsoft.com/it-it/library/ms228387(v=vs.90).aspx

Esistono programmi fatti da altri che hanno delle funzionalità particolari; questi programmi possiamo chiamarli INTERFACCE.
Sapendo i comandi per utilizzare quelle INTERFACCIE, noi non abbiamo bisogno di creare nulla, quindi non esiste la necessità di portarle dentro il nostro programma. Basta solo dare le istruzioni per utilizzare questo PEZZO DI PROGRAMMA ESTERNO, questa interfaccia. Dovremo quindi modificare il programma.

E' possibile far derivare una CLASSE da un'altra, usando la parola chiave EXTEND.
Quindi JAVAbuono EXTEND JAVAcattivo.

Per sostituire senza problemi una classe esistente in un PACCHETTO JAR, occorre conoscere tutto quello che faceva la classe; quali variabili, metodi, attributi aveva; e quali funzionalità eseguiva.
Qui abbiamo un "furbone" che pensa che sostituire una classe con un'altra che ha lo stesso nome sia sufficiente.
Ma se la classe CATTIVA faceva i gelati, possiamo ritrovarci con una classe BUONA che non fa i gelati, ma TIRA LA CATENA.

 

[ottofonsuppost]

Ciao Ottofonsuppost,

grazie della risposta. Però, non ho capito

Per chi non sa nulla di JAVA e non conosce come si ESTENDE, come si fa ad ereditare una classe da un'altra, possiamo sperare che la classeCATTIVA non sia stata scritta in modo da ostacolare il "riciclo" da parte di un utente; e quindi, possiamo tentare una manovra simile:

io in pratica ho il file jar con i .class, e un .java con la classe "MorenaStudio" presente nel jar. Ho modificato il .java come mi serve, poi ho seguito i passaggi elencati sopra ma sbaglio sicuramente qualcoaa. Sono confuso perchè non ho capito cosa mi hai detto di fare

Si potrebbe, giusto per avere una soluzione momentanea ma immediata del problema, prendere i sorgenti JAVA dello JAR MORENA DI ESEMPIO e modificare i nomi delle CLASSI aggiungendo una ERRE. Poi ricompilare queste classi che hanno il nome cambiato, e metterle nel nostro pacchetto JAR. Avremo del codice duplicato, ma almeno funziona tutto subito. Durante la modifica delle classi, occorre vedere se all'interno di ogni classe, esiste un richiamo ai nomi delle vecchie classi SENZA LA ERRE.

E' presumibile che nel FILE JAVA di esempio fornito da MORENA 7 esistano istruzioni di codice che richiamano ad un server particolare, facciamo finta il SERVER DELLA CASA, e questa istruzione non è invece presente nel file java modificato dall'Utente.

E' strano che l'utente ci parli di FILE JAVA e non di FILE CLASS, perchè il vero programma che fa il lavoro è quello con l'estensione .CLASS
Quindi ci troviamo in presenza di uno JAR dell'utente, che ha provato il FILE JAVA a parte, in un altro progetto. Lo ha testato compilandolo. La compilazione ha creato il FILE CLASS. Poi l'utente trasferisce solo il file con estensione .java MA SI DIMENTICA di trasferire il file con estensione .class

VEDI UN ESEMPIO DI ERRORI COMUNI
http://www.toonz.com/personal/todesco/sis/examples/example.html

 

[ottofonsuppost]

Un minimo di basi nel maneggiare JAVA occorre averli. IN questo caso abbiamo un utente che non conosce il concetto di EREDITARIETA', non usa un IDE potente per facilitarsi il compito di modifica di una classe; non ha studiato tutta la classe da sostituire, che magari ha dentro di se CODICE RIDONDANTE e lungo, per impedire proprio di capire il codice e rendere difficile la modifica ed il riciclo. Un programma può essere scritto in soli 100 byte, ma con le istruzioni fasulle messe ad arte dalla casa che ha prodotto il software, può essere trasformato in 20 megabyte, con il solo scopo di rendere difficile il DEBUGGING. La modifica di un codice RIDONDANTE richiede perdita di tempo enorme, ed è sfiancante per chiunque: trovare le sole 5 righe di codice che fanno veramente il lavoro su 20.000 è un impresa titanica. i proprietari del SOFWARE si proteggono in questo modo dagli utenti comuni. E' ovvio che chiunque, con pazienza arriva a decifrare tutta la matassa creata. Quanto appena detto nasconde però un aspetto inquietante: molte apparecchiature elettroniche vendute hanno software, programmi, con all'interno nascoste istruzioni tipo: superata questa data, il prodotto cessa di funzionare. Non è scritto in questo modo, ma le istruzioni fanno proprio questo. il problema è trovare la pazienza di trovarle quelle istruzioni, per poi denunciare chi ha truffato il cliente. Quando portate a riparare un elettrodomestico non ve lo fanno in vostra presenza e se impiegano 5 minuti per fare il lavoro, vi dicono che ci sono volute 4 ore...
Esistono clienti che in casa hanno elettrodomestici affiancati l'uno all'altro, e quando credono di aver inserito la spina di un frullatore, in realtà hanno inserito la spina di una centrifuga. Poi portano il frullatore a riparare...
Baci e abbracci, OTTOFONSUPPOST.