giannino1995 ha scritto:
Il comportamento che ti ho descritto è dovuto al fatto che la JVM crea delle istanze immutabili che vengono riutilizzate (per motivi di performance) ma per me resta comunque un grosso bug, se invece è una cosa voluta allora una pessima scelta, solo a mio avviso ovviamente.
NO. Allora vuol dire che non l'hai proprio capito .... ok, te lo spiego, ho un attimo di tempo.
Il codice che hai riportato esercita il meccanismo di "autoboxing" che è stato introdotto in Java 5 ("auto-boxing/unboxing"). In pratica da Java 5 i tipi primitivi e le corrispettive classi "wrapper" (java.lang.Integer, ecc...) sono molto più facilmente interscambiabili e in maniera più implicita rispetto al passato.
Ora, se vivessimo in un mondo IDEALE e TEORICO, il autoboxing
dovrebbe mantenere la "identità" dei valori. Cioè per una esecuzione della JVM, se in un punto del programma ho un int 12345678 e faccio il autoboxing, ottengo un oggetto X java.lang.Integer e se in un altro punto diverso del programma ho di nuovo un int 12345678 e faccio il autoboxing,
in teoria, dovrei RI-ottenere di nuovo quello STESSO oggetto X java.lang.Integer.
Insomma, per ciascun int ci dovrebbe essere il "suo" oggetto java.lang.Integer riottenibile ad ogni autoboxing in tutta una esecuzione di una applicazione. Questo purtroppo non si può realizzare, NON È fattibile a livello pratico! Vorrebbe dire realizzare un meccanismo di
caching che mantiene in memoria 4 miliardi di oggetti java.lang.Integer (non contiamo i long ..). NON è praticabile.
Un piccolo meccanismo di "caching" però l'hanno realizzato. Hanno deciso che il autoboxing di boolean, byte, i char da 0 a 127 e gli short/int da -128 a 127 godono di questa caratteristica.
Quando fai:
Integer a = 100;
questo viene tradotto in:
Integer a = Integer.valueOf(100);
Ed è questo valueOf che applica il "boxing" automatico. Innanzitutto verifica se il valore int è tra -128 e 127. Se sì prende il java.lang.Integer da un array che contiene dei Integer pre-generati. Altrimenti ne genera uno nuovo e lo restituisce (senza tenerselo da alcuna parte).
Il pezzo di codice che hai riportato serve solo per 2 scopi:
- per dimostrare la questione
- nei quiz/esami Java per cercare di "fregare" il candidato se non conosce la questione
Per il resto, non serve. Gli oggetti NON si confrontano con ==, salvo situazioni ultra-super-particolari. Ma si usa equals().
Quindi lo ripeto ancora: a) NON è un "baco", b) è una implementazione frutto di scelte ben precise di carattere "pratico". Insomma è un "compromesso" tra lo scenario ideale e .... il non fare nulla in quel senso.
giannino1995 ha scritto:
subtyping, bounds, wildcard non mi dicono nulla ma i generic servono per scrivere codice che sia riutilizzabile per classi differenti.
Quindi non sai dirmi perché List<String> NON è il sottotipo di List<Object> (mentre invece String[] è un sottotipo di Object[] ).
Vabbé .. non è proprio fondamentale ma è rilevante .... avrai (spero) tempo per approfondire.
giannino1995 ha scritto:
Comunque non mi hai spiegato quel HttpStatus.NOT_FOUND a che diavolo serve.
L'avevo detto nell'altra tua discussione.
giannino1995 ha scritto:
Quindi alla fine cosa mi consigli di fare?
Appena ho tempo verifico dei libri e ti dico.
giannino1995 ha scritto:
Tu per fare siti dinamici in ambito lavorativo quali strumenti usi? Boot Strap 2 + JPA + Ajax?
Dipende dal contesto e lavoro. Dove sono ora mi occupo molto di web service/microservizi fatti con Spring Boot 2 dove però c'è poco/nulla di DB e invece molte chiamate a servizi verso "fuori". E a questo livello di interfacce grafiche/web non vedo ovviamente nulla.