faretesto > comp.lang.* > comp.java

CarMas (05.04.2017, 11:44)
Salve a tutti, spero ci sia (ancora) qualcuno che frequenta il ng e magari
usa pure Eclipse.
Purtroppo mi sta facendo impazzire da due giorni... su un progetto che fino
alla scorsa settimana funzionava. Oltretutto si tratta di roba vecchia che
nessuno sta piu' aggiornando, quindi escludo modifiche a configurazioni
(almeno esplicite).
In sostanza, esiste una "configuration" chiamata Test che non fa altro che
avviare il progetto dalla main class. Ha sempre funzionato, da ieri invece
quando la seleziono, dalla console di Eclipse leggo:
Test [Java Application] ...
come se si stesse avviando e praticamente dopo un secondo (in cui non so
cosa succede), Eclipse mi dice:
<terminated> Test [Java Application] ...
Dal momento che mi aspettavo che apparisse una gui, direi che terminated non
e' un buon segno. Nessun errore, crash, stacktrace anomalo. Niente.

Preso dalla sconforto e da cose lette frettolosamente in rete, ho rimosso
dal build path tutte le dipendenze da altri jar (tipo log4j, hsqldb, ecc),
ho fatto clean/rebuild per vedere se Eclipse si lamentava (come in effetti
e' stato) e le ho nuovamente aggiunte una alla volta, sempre intermezzando
con clean/rebuild, fino a quando non sono arrivato a 0 errori.
Stranamente in questo modo si e' messo a funzionare (?).
L'ho lasciato li' mentre mi leggevo della documentazione su un altro monitor
e un paio di ore dopo, al primo tentativo di lancio, ha ricominciato
nuovamente con questo comportamento.
Ho ripetuto la stessa procedura e ora mi trovo in una sorta di limbo
intermedio, questa stessa configurazione funziona come "Run configuration"
ma non come "Debug configuration".

Non ci sto piu' capendo niente e non so come uscirne, qualcuno ha esperienza
o suggerimenti in merito?
Sto usando Eclipse Kepler su Win10 e jdk6 (!)

Grazie
CarMas
Patrick (17.04.2017, 23:40)
Il 05/04/2017 11:44, CarMas ha scritto:
[cut]
> Non ci sto piu' capendo niente e non so come uscirne, qualcuno ha
> esperienza o suggerimenti in merito?
> Sto usando Eclipse Kepler su Win10 e jdk6 (!)
> Grazie
> CarMas


Domanda banale, hai provato ad aggiornare il jdk?
La versione 6 potrebbe avere problemi di compatibilità con Win 10, l'ho
buttata lì.

Altra domanda puoi eseguire, le classi compilate al di fuori di eclipse?

Saluti Patrick
CarMas (18.04.2017, 09:48)
"Patrick" ha scritto nel messaggio news:7ah1

> Domanda banale, hai provato ad aggiornare il jdk?
> La versione 6 potrebbe avere problemi di compatibilità con Win 10, l'ho
> buttata lì.
> Altra domanda puoi eseguire, le classi compilate al di fuori di eclipse?


Aggiungo queste informazioni per dei test che ho fatto successivamente e che
rispondono anche alle tue domande:
- su un altro pc con win10, con lo stesso eclipse kepler (intendo proprio lo
stesso zip scompattato) e lo stesso jdk, la configurazione si avvia sia in
run che in debug senza alcun problema... anche se non mi stupisce perche'
fino a non molto tempo fa funzionava perfettamente anche su questo pc
incriminato.
- ho modificato eclipse.ini per fargli usare il jre1.8.0_121 (ma nelle
proprieta' del progetto il target e' java 1.6 per motivi storici) ma
analogamente non parte niente.
- le classe compilate (da eclipse) si avviano tranquillamente, per esempio
con un bat, sia col jre6 che jre8.
- debuggando step by step il progetto, eclipse esce SENZA errori o messaggi
particolari (solo scrivendo "terminated" nella console) quando cerco di
istanziare una classe che estende jframe...

Sempre piu' misterioso...

Saluti
CarMas
Enrico Bianchi (18.04.2017, 11:31)
On 2017-04-18, CarMas <carmas> wrote:

> - ho modificato eclipse.ini per fargli usare il jre1.8.0_121 (ma nelle
> proprieta' del progetto il target e' java 1.6 per motivi storici) ma
> analogamente non parte niente.


Domanda estemporanea che non c'entra niente con il tuo problema[1]: perché il
target rimane java6?

Enrico
[1] in teoria ti risponderei con "prova netbeans o idea", ma è una risposta
che non c'entra nulla con il tuo problema
CarMas (18.04.2017, 14:03)
> "Enrico Bianchi" ha scritto nel messaggio
> news:nh91


> Domanda estemporanea che non c'entra niente con il tuo problema[1]: perché
> il target rimane java6?


Di fatto perché per motivi di sicurezza era stato comprato un software che
compilava il mio jar finale in un eseguibile nativo win32 e all'epoca questo
sw funzionava con java6. In seguito non sono stati più comprati gli
aggiornamenti del prodotto e quindi si utilizza ancora uno strumento che
supporta bytecode java6.

Saluti
CarMas
Enrico Bianchi (18.04.2017, 14:14)
On 2017-04-18, CarMas <carmas> wrote:

> Di fatto perché per motivi di sicurezza era stato comprato un software che
> compilava il mio jar finale in un eseguibile nativo win32 e all'epoca questo
> sw funzionava con java6.


Posto che lo ritengo abbastanza inutile, prova a vedere JSMooth o Launch4j, che
sono FLOSS e quindi liberamente scaricabili/usabili

Enrico
CarMas (18.04.2017, 15:03)
"Enrico Bianchi" ha scritto nel messaggio
news:2h51

> Posto che lo ritengo abbastanza inutile, prova a vedere JSMooth o
> Launch4j, che
> sono FLOSS e quindi liberamente scaricabili/usabili


JSmooth e Launch4j sono stati già testati e scartati appunto per motivi di
sicurezza, come dicevo prima.
Per esempio: prendi questo "exe" che ti crea launch4j, lo rinomini in zip,
lo scompatti e ti trovi tutti i class. Scarichi un qualunque decompiler al
volo (tipo jd che ha una gui comoda) e ti ritrovi i sorgenti in chiaro
diciamo al 90% simili all'originale... se non ricordo male, almeno aveva
strippato via i commenti, ma tutto il resto era tale e quale.

Ma anche se fosse, questo non mi risolve il problema di eclipse :(

Saluti
CarMas
Patrick (18.04.2017, 15:51)
Il 18/04/2017 09:48, CarMas ha scritto:
[..]
> Sempre piu' misterioso...
> Saluti
> CarMas


Considerando quello che hai scritto il problema potrebbe risiedere nel
workspace che stai usando. Dato che su un'installazione, ex novo, tutto
funziona bene. Potresti creare un nuovo workspace, ed importare il progetto.
CarMas (19.04.2017, 10:23)
"Patrick" ha scritto nel messaggio news:r3c1

> Considerando quello che hai scritto il problema potrebbe risiedere nel
> workspace che stai usando. Dato che su un'installazione, ex novo, tutto
> funziona bene. Potresti creare un nuovo workspace, ed importare il
> progetto.


Sembrava una strada interessante, ho creato un nuovo workspace e ho fatto
importare ad Eclipse il progetto dall'altro workspace (ho spuntato anche
l'opzione per copiarlo). Poi mi sono ricreato la run configuration, l'ho
avviato ma nuovamente si e' ripresentato questo strano fenomeno, subito
<terminated> senza nessun apparente motivo.

Ho tentato anche con una manovra piu' drastica, ho cancellato la cartella
..metadata e ho riavviato Eclipse, ho reimportato i progetti (che non vedeva
anche se c'erano), ho ricreato tutte le configurazioni ma nessun risultato,
il progetto proprio non si avvia. O meglio, si avvia ma viene terminato
immediatamente.

Non riesco ancora a capire cosa potrebbe essersi corrotto...

Saluti
CarMas
ciccio_the_best (19.04.2017, 17:31)
CarMas <carmas> ha scritto:

> Di fatto perché per motivi di sicurezza era stato comprato un software che
> compilava il mio jar finale in un eseguibile nativo win32 e all'epoca questo
> sw funzionava con java6. In seguito non sono stati più comprati gli
> aggiornamenti del prodotto e quindi si utilizza ancora uno strumento che
> supporta bytecode java6.


Questa cmq ? una cosa che ha portato problemi, infatti tu adesso
te li ritrovi tutti. Tra l'altro compilare il jar finale in un eseguibile
nativo win32 non ? propriamente un metodo ortodosso per il deploy
di un'applicazione Java, ma un semplice ripiego.

(Nel caso integro con un'altra risposta nel post succ.)
ciccio_the_best (19.04.2017, 17:36)
CarMas <carmas> ha scritto:

> "Enrico Bianchi" ha scritto nel messaggio
> news:2h51
> JSmooth e Launch4j sono stati già testati e scartati appunto per motivi di
> sicurezza, come dicevo prima.
> Per esempio: prendi questo "exe" che ti crea launch4j, lo rinomini in zip,
> lo scompatti e ti trovi tutti i class. Scarichi un qualunque decompiler al
> volo (tipo jd che ha una gui comoda) e ti ritrovi i sorgenti in chiaro
> diciamo al 90% simili all'originale... se non ricordo male, almeno aveva
> strippato via i commenti, ma tutto il resto era tale e quale.


Ma questo potrebbe succedere con qualsiasi file ".class", non
soltanto con un jar impacchettato in un exe.

L'unica ?, prima di compilare tutta l'applicazione, offuscarla
con un offuscatore, togliendo anche tutti i commenti (che sono
la principale forma diretta di documentazione di un progetto SW).

A questo punto solo un programmatore Java potente potrebbe
riuscire a capire qualcosa dopo la decompilazione, ma se
si tratta un un programmatore Java potente cmq non gli converrebbe
perch? gli converrebbe riscriversi il codice/le classi di
interesse facendo pure prima ;-)

Per i lamer e i "copia-incollatori" invece quanto sopra sarebbe
uno sbarramento invalicabile.
CarMas (20.04.2017, 11:43)
"ciccio_the_best" ha scritto nel messaggio
news:1669

> L'unica è, prima di compilare tutta l'applicazione, offuscarla
> con un offuscatore, togliendo anche tutti i commenti (che sono
> la principale forma diretta di documentazione di un progetto SW).


Mi ricordo che all'epoca dell'avvio del progetto (un decennio fa ormai) se
ne era parlato e la soluzione era stata abbandonata perche' nel codice si fa
abbondante uso di serializzazione, jni, rmi e credo anche reflection (su
quest'ultima non sono sicuro ma al momento potremmo considerarlo abbastanza
irrilevante). Non escludo pero' che sia stata abbandonata per le troppe
difficolta' tecniche piu' che per l'impossibilita' della cosa.
La parte piu' sensibile del prodotto e' stata tutta portata in C con
librerie di elaborazione (da cui jni per invocare i vari metodi). Queste dll
a loro volta sono dei wrapper che includono anche l'interfacciamento con
librerie commerciali di terze parti. Tuttavia la parte java che le usava era
troppo esposta, un programmatore smaliziato poteva studiare e capire il modo
in cui i vari metodi venivano fatti interagire per ricavarne un flusso di
esecuzione, quindi e' stata fatta la scelta di trasformare il jar in un exe
nativo win32.

Scusa se ne approfitto: per rimuovere i commenti esiste qualcosa di
automatico? ho messo poco le mani su proguard ma mi sembra che si limitasse
ad offuscare, lasciando i commenti. Per toglierli intendo proprio tutti,
quelli in stile javadoc che quelli generici (con le // per intenderci), sia
all'interno che all'esterno di un metodo...

> A questo punto solo un programmatore Java potente potrebbe
> riuscire a capire qualcosa dopo la decompilazione


Il punto sta qui, l'offuscatore non e' un metodo per prevenire la
decompilazione ma per rendere difficile il lavoro dopo.
In sostanza si e' scelto il compilatore exe per "spostare il problema" dal
punto di vista tecnico (ovvero, il reverse engineering era e resta cmq
possibile) a quello commerciale (quanto tempo e risorse vuoi investire per
riuscire a venirne a capo). Deterrente per deterrente, si spera(va) che
fosse piu' "difficile" lavorare partendo dal nativo win32.

Naturalmente sono aperto a suggerimenti se l'ipotesi e' fondamentalmente
sbagliata ed esistono approcci migliori o piu' corretti/adeguati. Sempre se
intanto riesco a far funzionare Eclipse per poter continuare a lavorare a
questo progetto (cambiare ide mi pare drastico attualmente)...

Saluti
CarMas
Enrico Bianchi (20.04.2017, 12:10)
On 2017-04-20, CarMas <carmas> wrote:

> Naturalmente sono aperto a suggerimenti se l'ipotesi e' fondamentalmente
> sbagliata ed esistono approcci migliori o piu' corretti/adeguati.


Boh, per come la metti dal mio punto di vista riscriverei il tutto usando
un linguaggio compilato (C++ in primis) o che sfrutti la compilazione (.NET).
Il tutto senza offesa, eh, capisco che ci sono vincoli, ma tra l'usare una
tecnologia che non ti porta vantaggi e che sta diventando obsoleta ed il
passare ad una tecnologia che comunque si adatta più al modo di lavorare che
utilizzate personalmente penso che sia più vantaggioso passare a quest'ultima

> Sempre se
> intanto riesco a far funzionare Eclipse per poter continuare a lavorare a
> questo progetto (cambiare ide mi pare drastico attualmente)...


Guardala da un altro punto di vista: l'effort che hai con altri IDE con
Eclipse te lo sogni. Da me, gli sviluppatori sono passati da Eclipse a IDEA,
ed uno per poco non piangeva dalla gioia

Enrico
CarMas (20.04.2017, 14:57)
"Enrico Bianchi" ha scritto nel messaggio
news:16n1

> Boh, per come la metti dal mio punto di vista riscriverei il tutto usando
> un linguaggio compilato (C++ in primis) o che sfrutti la compilazione
> (.NET).


In sostanza, mi stai dicendo che dovrei essere licenziato (perche' sono
sviluppatore Java) e fare assumere al mio posto uno sviluppatore .net/c++ :(

> Il tutto senza offesa, eh, capisco che ci sono vincoli, ma tra l'usare una
> tecnologia che non ti porta vantaggi e che sta diventando obsoleta


Niente offese, sono io che ho chiesto e ascolto volentieri tutte le
opinioni.
Recap che mi sono perso: la tecnologia obsoleta che non mi porta vantaggi a
cui fai riferimento e' Java?

Saluti
CarMas
Enrico Bianchi (20.04.2017, 18:37)
On 2017-04-20, CarMas <carmas> wrote:

> In sostanza, mi stai dicendo che dovrei essere licenziato (perche' sono
> sviluppatore Java) e fare assumere al mio posto uno sviluppatore .net/c++ :(


Veramente il mio intento era dire "riscrivilo (te) in .net/c++", ovvero che tu
imparassi quelle tecnologie :)

> Recap che mi sono perso: la tecnologia obsoleta che non mi porta vantaggi a
> cui fai riferimento e' Java?


Mi riferisco a Java 6, non a Java in toto. Dalla 6 ad oggi ci sono state
migliorie (sia a livello di linguaggio, sia a livello di libreria) che, a
meno di vincoli più stringenti di quello che hai citato, vale la pena
considerare. In questo modo, non dico che si sta perdendo un treno, ma
comunque si è fermi

Enrico

Discussioni simili