[JAVA] un dubbio o mistero da sfatare

[PGI]

I linguaggi a cui ho fatto riferimento sono quelli indicati da Gosling in "Java Language Specifications 1st ed.".

Ho letto sia lo schema del progetto1 che del 2. La questione, ed a parer mio è segno di grande competenza, e che il modo in cui il vostro professore vi presenta i progetti non è una "costrizione" per programmare come piace a lui ma è essa stessa parte dell'insegnamento che vi fornisce.

Quegli schemi di progetto sono delle rappresentazioni del risultato di una fase di progettazione OOD (object oriented design, 'sti oggetti sono dappertutto ) e corrispodono ad un modulo da assegnare ad una parte del team di sviluppo del software.

Nel caso concreto poi si tratta di una distribuzione relativamente semplice, un modulo presumibilmente l'ha già sviluppato il professore (ed è quello che userà per testare il programma) e non credo che abbia scritto una scheda per sè stesso, quello che affida a voi è tutto il resto del programma. La presenza di uno schema da seguire non è aria fritta, serve proprio a rendere possibile la separazione della realizzazione di un software tra più programmatori.

Non che non sia possibile "fare software" senza OOD, ma il procedimento "all'ammucchiata" è decisamente più caotico (o può diventarlo).

Così parlò Zaratustra.

Ciao.

[misterx]

va che la mia non era una critica al docente ognuno fa il proprio lavoro, anche se il loro modo di esprimersi mi è di ostacolo esempio:

modella un ogetto..... modella...mah...

io non insegno il suo a lui nè tantomeno lui insegna il mio a mè



cmq, da fuori si ragiona in maniera molto più rilassata

[PGI]

Originariamente inviato da misterx
cmq, da fuori si ragiona in maniera molto più rilassata

Se non devi fare qualcosa allora ti viene benissimo.

Verità assoluta, vale anche per la programmazione .

[misterx]

Originariamente inviato da PGI
Se non devi fare qualcosa allora ti viene benissimo.

Verità assoluta, vale anche per la programmazione .

inizi a parlare cifrato come a2000

non ho capito la tua risposta: mi stai dando ragione?


hai PVT

[dnarod]

ma.....scusatemi all inizio di sto topic si sindaca sul come mai venga piu grosso un file di un altro compilato se si assegna un int a una variabile piuttosto che un double.......non riesco a capire la spiegazione che avete dato per il mistero......potreste rispiegarmela (sono al 2 anno di informatica e sto programmando java......l unica cosa che mi viene in mente e che un double è piu grosso di un int in bytes ma non so che c entri col resto)......mi piacerebbe partecipare al 3d se ne avessi le competenze.....

[PGI]

misterx -> ti stavo dando ragione sul fatto che a mente fredda si ragionasse meglio.

Il thread è degenerato a pagina 2, punto a partire dal quale si parla del più e del meno riguardo a Java, OOP, pezzi dell'API standard e chi più ne ha più ne metta. Ma bene o male si è sempre in-topic (un dubbio o un mistero, chi ce l'ha lo posti).

Il mistero del double, Replica delle puntate precedenti

A

    int x = 0;
    double y = 0;    
    x = x;

B

    int x = 0;
    double y = 0;    
    y = x;

Premessa: il file class contiene una serie di istruzioni per la macchina virtuale Java, create a partire dal codice sorgente.

Perchè il file class creato dal sorgente B è più grande del A?

Perche il sorgente B richiede che la jvm esegua un'istruzione in più rispetto ad A. La faccenda si comprende "compilando a mano":

a sinistra il sorgente, a destra le operazioni jvm

A:

int x=0;        iconst
                    istore

double y=0; dconst
                    dstore

x = x;           iload
                    istore

6 istruzioni

B:

int x=0;        iconst
                    istore

double y=0; dconst
                    dstore

y = x;           iload
                    i2d          <<<!
                    dstore

Perchè i2d? Perchè y è una variabile double, x contiene un valore int. Gli int non sono double (ovvio). Nel sorgente la conversione larga è "trasparente" perchè un double (64bit) ha sempre abbastanza spazio per contenere i 32bit di un int e gli ideatori di Java hanno preferito non ricordare al programmatore che stà sprecando spazio perchè in genere la scelta è consapevole, se usi un double per un int hai i tuoi motivi.
Ma il processore virtuale ha bisogno di convertire il valore in modo che si adatti al tipo di contenuto della variabile.

Allora se il file class di B contiene un'istruzione in più è chiaro che sarà più grande del file A, più grande di quel tanto che basta per contenere un'istruzione in più per la jvm.

Comunque è solo una curiosità, non è che sia un pilastro del buon programmatore Java.

Se cerchi un po' nel thread dovrebbe esserci un link alle specifiche della jvm, pubblicate da Sun, in cui di aneddoti del genere ne trovi a bizzeffe.

&Ciao.

[misterx]

cmq, PGI, beato te!

ho letto qualcosa QUA a proposito delle interfacce; non mi pare brilli di chiarezza

[misterx]

Originariamente inviato da cn73
ok ti posto anche l'altra...dammi un secondo

ciao cn73. mi stavo chiedendo con cosa avevi disassemblato il codice java; mi interessava capire se si vedeva la fase di creazione/distruzione del record di attivazione di questo codice

public class Mio{

    public static void main(String[] args){
        
        int cip = ft(3);
        
        System.out.println(cip);            
   
    }

    public static int ft( int n){
        int k=1;
        if(n == 0)
            return 1;
        else
            return n * ft(n-1);            
        
    }
}

[misterx]

up

[PGI]

Originariamente inviato da misterx
cmq, PGI, beato te!

ho letto qualcosa QUA a proposito delle interfacce; non mi pare brilli di chiarezza

Beato me lo dico anch'io, ma perchè sono di carattere piuttosto allegro. Esattamente a cosa ti riferivi?

La descrizione contenuta nelle specifiche della jvm è tratta dal più voluminoso libro sulle specifiche del linguaggio Java (disponibile per il download da qualche parte sul sito di SUN) che è scritto in un americano terribilmente tecnico. Personalmente quando lo prendo per leggere qualcosa devo riguardare le stesse frasi sei o sette volte prima di capire bene cosa dica.

Per "disassemblare" un file class (diverso da decompilare) puoi usare il tool "javap" incluso nel JDK che produce un output su consolle con il bytecode "leggibile".

javap NomeFileClass(senza il .class) [invio]

&Ciao.

[misterx]

Originariamente inviato da PGI

Per "disassemblare" un file class (diverso da decompilare) puoi usare il tool "javap" incluso nel JDK che produce un output su consolle con il bytecode "leggibile".

javap NomeFileClass(senza il .class) [invio]

&Ciao.

ok, quello lo avevo trovato ma il record di attivazione ?

[PGI]

Mi era sfuggita la parte del record.

In sincerità, io il record di attivazione non so manco cosa sia .

&Ciao.

[recoil]

il record di attivazione è l'insieme di variabili che finiscono nello stack durante l'esecuzione e che contengono parametri, indirizzo di ritorno e variabili locali

non sono esperto di bytecode java (dopotutto che me ne faccio?) però la definizione di record di attivazione è pressapoco quella che ho dato sopra

[PGI]

del bytecode io ho già detto tutto quel che so e quindi sono tutto fuorchè un esperto. Ma siamo poi sicuri che non serva approfondire la cosa (lo chiedo per discuterne)?

In fondo è il bytecode ad essere eseguito e non il codice, è possibile che uno stesso algoritmo implementato in modi diversi e dato in pasto al compilatore generi un byte-code "più efficente" (a parità di condizioni generali, vale a dire usando gli stessi tipi di dato ecc.)?

[recoil]

io credo che la filosofia Java sia quella di fregarsene totalmente di quanto sta sotto.

se ho bisogno di scrivere del codice veloce e ottimizzato allora Java non è il top, è meglio c ad esempio.
studiare la VM può essere interessante, non lo nego, ma direi che èuna delle ultime cose da studiare di Java.

credo che venga fatta nei corsi di programmazione (come quello che sta seguendo misterx) perché si vuole far capire qualcosa sul funzionamento più a basso livello e questo mi sta bene. sarebbe però sbagliato iniziare a guardare il bytecode prima di aver imparato per bene a programmare in Java, si perderebbe del tempo secondo me.

[PGI]

Forse il grosso del problema "prestazioni" in Java stà proprio in quella filosofia (che io adoro). Poichè si ottengono risultati molto in fretta si tralascia quel grado di "finezza" a cui si è quasi costretti usando altri linguaggi e ad un certo punto si arriva a dire "Java è bello ma lento".

Eppure in due recenti libri che ho letto (Java2 SDK 1.4 e tal "Brecken", Developing Game in Java) si dice che la versione 1.4.2 è ormai un linguaggio ad elevate prestazioni, anche per merito delle ottimizzazioni della jvm HotSpot (che è poi quella ufficiale di Sun)... e perchè io non mi sono accorto della differenza?

Misteri dell'informatica.

[misterx]

Originariamente inviato da recoil

credo che venga fatta nei corsi di programmazione (come quello che sta seguendo misterx) perché si vuole far capire qualcosa sul funzionamento più a basso livello e questo mi sta bene. sarebbe però sbagliato iniziare a guardare il bytecode prima di aver imparato per bene a programmare in Java, si perderebbe del tempo secondo me.

infatti, e se si osserva una simulazione nel caso di una ricorsione diviene un argomento abbastanza lungo e laborioso da illustrare

io devo conoscere l'argomento in quanto te lo chiedono all'esame

a proposito
mi hanno detto che jbuilder ti fa vedere durante l'esecuzione di un programma, questi benedetti record di attivazione, e se nel programma è prevista una ricorsione vedi il motivo del celeberrimo "stack overflow"

[recoil]

Originariamente inviato da misterx
mi hanno detto che jbuilder ti fa vedere durante l'esecuzione di un programma, questi benedetti record di attivazione, e se nel programma è prevista una ricorsione vedi il motivo del celeberrimo "stack overflow"

non uso jbuilder quindi non so se è vero ma è molto probabile. del resto gli ambienti di sviluppo "avanzati" per Java hanno le funzionalità tipiche dei tool per c/c++ inclusa la possibilità di fare esecuzione passo passo e vedere lo stack.


PGI: nonostante quello che dicono i libri che citi io credo che Java abbia ancora qualche problema velocistico. me ne accorgo sia usando netbeans che è pesantuccio e me ne sono reso conto soprattutto facendo la mia tesi, sviluppata in Java.

del resto la portabilità e lasciatemelo dire anche la comodità si paga. però lo ripeto: w Java

[PGI]

Sicuramente gli autori degli ultimi libri che ho letto sono tutto fuorchè "internazionalmente autorevoli", hanno il pregio di essere recenti, comunque ti do ragione sul fatto che si debbano prendere con le molle.

D'altronde gli stessi membri del team di sviluppo Swing sul punto delle prestazioni hanno parlato chiaro dicendo:

"dopo aver introdotto Swing ricevemmo commenti entusiastici e una valanga di lamentele sulle prestazioni: così decidemmo di analizzare il codice alla ricerca di possibili ottimizzazioni e scoprimmo che le librerie erano piene di colli di bottiglia".

Dopo aver letto questa frase in genere sono abbastanza sospettoso quando sento dire "se il programma è lento è colpa di come lo hai scritto"... di solito mi attesto su un più probabile "al 75% è per come lo hai scritto, il 25% è nelle mani del signore (che ha scritto le librerie per Sun...)".

E comunque NetBeans è niente in confronto al mitico SunOneStudio, ricordo tempi di caricamento da era geologica su un XP1700+ con 512DDR

[recoil]

Originariamente inviato da PGI
E comunque NetBeans è niente in confronto al mitico SunOneStudio, ricordo tempi di caricamento da era geologica su un XP1700+ con 512DDR

infatti non ci penso minimamente a procurarmi SunOne

cmq non sono lente solo le Swing perché le basse prestazioni si notano anche sviluppando applicazioni senza interfaccia grafica.
diciamo che la lentezza di Swing si vede a occhio durante l'utilizzo di una applicazione, quella generale delle applicazioni Java la noto durante il caricamento iniziale che è piuttosto pesante...