[JAVA] Problema compatibilità MultiOS

[franksisca]

ricopio un sunto derivato dalla discussione su di un altro forum


- Software scritto in java e perfettamente funzionante
- Il software risiede su un hard disk esterno
- L'hard Disk è collegato ad un computer che ha come SO W7
- L'hd è condiviso con tutta la rete lan interna
- Il software è utilizzabile da tutte le postazioni lan
- Una postazione ha come SO Ubuntu 12.04
- La postazione ubuntu, se avvia il software da terminale, funziona correttamente, se lo avvio da "interfaccia", non fà il loading dei dati


ora volevo creare il file .sh per automatizzare la chiamata alla shell e l'avvio del software, ma mi sta dando questi problemi del chmod, che credo derivino dalla condivisione con windows.
Inoltre mi è stato "consigliato" di creare sempre uno starter, e di non usare il "doppio click" per l'avvio delle applicazioni java.

[PGI-Bis]

Al 99.9% è un problema di percorsi. Avviando da console la cartella di lavoro ha un certo valore, avviandolo da jar ne ha un'altra.

La cartella di lavoro è usata per risolvere i percorsi relativi (tipo new File("pippo/pappo.txt")), che non si dovrebbero mai usare.

Il consiglio sull'uso di uno starter è un'emerita stupidaggine.

[franksisca]

Originariamente inviato da PGI-Bis

Al 99.9% è un problema di percorsi. Avviando da console la cartella di lavoro ha un certo valore, avviandolo da jar ne ha un'altra.

La cartella di lavoro è usata per risolvere i percorsi relativi (tipo new File("pippo/pappo.txt")), che non si dovrebbero mai usare.

Il consiglio sull'uso di uno starter è un'emerita stupidaggine.

anche io la penso così...cioè fare uno starter che si colleghi a linea di comando perchè, se ho il jar che con il doppio click mi funziona?

comunque, io carico i file in questo modo

        FileInputStream file;
        try {
            file = new FileInputStream("archive/Scadenze.fjs");
            ObjectInputStream input = new ObjectInputStream(file);
            this.listaScadenze = (HashMap<String, Scadenza>) input.readObject();
            file.close();

a questo punto, se il problema è di path, credo che debba caricarli con il getClass().getResource(); oppure getClass().getResourceAsStream(); giusto???

[PGI-Bis]

Il problema è certamente lì.

La soluzione sta nel trovare un modo per risolvere quel "archive" in senso assoluto.

Per usare il classloader e getResource devi garantire che la cartella in cui si trova "archive" sia inserita nel classpath: getResource infatti tenta di risolvere il nome parziale che gli passi rispetto a tutte le directory-archivi indicati nel classpath. Di solito si usa per accedere a file inclusi nel jar del programma e quel jar è certamente nel classpath, altrimenti il programma non partirebbe. Per cartelle che stiano fuori dal jar non è detto che funzioni (dipende dall'impostazione della variabile classpath).

Dovresti trovare un altro appoggio per essere sempre sicuro di beccare la cartella. Quello che faccio io di solito, nel presupposto che archive sia una cartella che si trova in un percorso determinabile a partire dalla directory in cui si trova il file jar del programma, è usare getResource per determinare la posizione del file jar nel filesystem e poi calcolare "a meno" la posizione della risorsa esterna.

[franksisca]

la classe archive è allo stesso livello del jar.

siccome sto montando un rack (è la mia prima volta) non ho il tempo di provare...se hai un pezzettino di codce mi eviteresti di scervellarci sopra e te ne sarei immensamente grato (una delle tante). Se non hai codice sottomano no problem, mi hai ampiamente indirizzato.

[PGI-Bis]

Et voilà:

    /**
     * Returns the root folder of the given class (file)
     * @param aClass the target class
     * @return the path of the folder that contains the root of the package of the given class or
     * the folder that contains the jar file if the class is contained in a jar file
     */
    public static File getJarFolder(Class<?> aClass) {
        String name = aClass.getName();
        name = "/" + name.replace(".", "/") + ".class";
        URL url = File.class.getResource(name);
        String path = url.toString();
        path = path.replace("%20", " ");
        if(path.startsWith("jar:file:/")) {
            path = path.substring("jar:file:/".length());
            int i = path.indexOf("!");
            path = path.substring(0, i);
            File file = new File(path);
            return file;
        } else if(path.startsWith("file:/")) {
            path = path.substring("file:/".length(), path.length() - name.length());
            File file = new File(path);
            return file;
        }
        return null;
    }

Gli passi una classe che sta nel tuo jar e ti da la cartella in cui si trova il jar. Forse, in verità questo l'ho pescato dal cest... erm, dall'archivio ma sono quasi sicuro di avere un'applicazione che lo usa ancora adesso.

[franksisca]

Originariamente inviato da PGI-Bis

Et voilà:

    /**
     * Returns the root folder of the given class (file)
     * @param aClass the target class
     * @return the path of the folder that contains the root of the package of the given class or
     * the folder that contains the jar file if the class is contained in a jar file
     */
    public static File getJarFolder(Class<?> aClass) {
        String name = aClass.getName();
        name = "/" + name.replace(".", "/") + ".class";
        URL url = File.class.getResource(name);
        String path = url.toString();
        path = path.replace("%20", " ");
        if(path.startsWith("jar:file:/")) {
            path = path.substring("jar:file:/".length());
            int i = path.indexOf("!");
            path = path.substring(0, i);
            File file = new File(path);
            return file;
        } else if(path.startsWith("file:/")) {
            path = path.substring("file:/".length(), path.length() - name.length());
            File file = new File(path);
            return file;
        }
        return null;
    }

Gli passi una classe che sta nel tuo jar e ti da la cartella in cui si trova il jar. Forse, in verità questo l'ho pescato dal cest... erm, dall'archivio ma sono quasi sicuro di avere un'applicazione che lo usa ancora adesso.

statua.

a questo punto, io gli posso passare il mio main.class e lui mi restituisce il path "corretto, io posso navigarlo alla cartella superiore e arrivare ad archive.

anche se il jar e archive stanno allo stesso livello funziona?

[PGI-Bis]

Se Main.class sta nel jar "Programma.jar" il metodo ti da la cartella in cui si trova "Programma.jar".

In ipotesi:

/a/b/c/Programma.jar
/a/b/c/archive/

E Main sta in Programma.jar allora dicendo:

File base = getJarFolder(Main.class)

ottieni il file che rappresenta la cartella /a/b/c e dunque per archive dirai:

File archiveFolder = new File(base, "archive");

[franksisca]

Originariamente inviato da PGI-Bis

Se Main.class sta nel jar "Programma.jar" il metodo ti da la cartella in cui si trova "Programma.jar".

In ipotesi:

/a/b/c/Programma.jar
/a/b/c/archive/

E Main sta in Programma.jar allora dicendo:

File base = getJarFolder(Main.class)

ottieni il file che rappresenta la cartella /a/b/c e dunque per archive dirai:

File archiveFolder = new File(base, "archive");

perfetto. quindi per sicurezza apro il jar e vedo il primo .class dove si trova e poi faccio come mi hai suggerito.

Montare un Rack è davvero stancante...e ora devo installare 3 server O_O

[franksisca]

dopo una settimana riprendo in mano il progetto e mi ritrovo un problema.
se uso il tuo metodo, mi restituisce il path del .class che gli restituisco, ma me lo restituisce diverso se lo avvio da netbeans o da jar. il chè èp normale guardando la struttura del metodo, che appunto mi ridà il path del .class che io gli passo.

a questo punto mi (ti) domando e dico:"devo parserizzare il path per risalire a quello che mi serve?"

[PGI-Bis]

Fai prima a usare una costante in fase di test - cioè quando lanci da netbeans - e a passare al percorso relativo in produzione - cioè quandi esegui il jar anche perchè in tanto puoi determinare il percorso di ricerca in quanto esso sia costantemente determinabile (a partire dalla posizione del jar).

[franksisca]

Originariamente inviato da PGI-Bis

Fai prima a usare una costante in fase di test - cioè quando lanci da netbeans - e a passare al percorso relativo in produzione - cioè quandi esegui il jar anche perchè in tanto puoi determinare il percorso di ricerca in quanto esso sia costantemente determinabile (a partire dalla posizione del jar).

ok, anche se non mi piace come cosa, la vedo poco portabile/fruibile