vignetta
Leggi tutto “Ecco perché non dovresti interrompere un programmatore”
Pro e contro se ritornare uno Stream o un Collection
Molte Java API hanno metodi che ritornano un Collection (eviterò di scrivere una Collection). Dalla versione 8 di Java è possibile restituire anche uno Stream. Dato che uno Stream è più flessibile ed efficiente in moti casi, le API che andremo a sviluppare dovrebbero restituire uno Stream o un Collection?
Un esempio significativo
Per restituire un Collection, gli elementi della collezione devono essere prima di tutto creati e poi caricati in memoria. Così ci sono due costi: computazionale e allocazione di memoria.
Leggi tutto “Pro e contro se ritornare uno Stream o un Collection”
Passaggio di parametri in JAVA
Una domanda che mi fanno molti o che mi capita di leggere spesso riguardo JAVA e’: “come faccio a passare dei parametri per riferimento?”. La mia risposta e’: “NON SI PUO’!!”.
Ecco un mito da sfatare:
“Gli oggetti sono passati per riferimento, i primitivi per valore” FALSO
In JAVA ogni cosa è passata per valore. Gli oggetti, non vengono passati affatto.
I valori delle variabili sono sempre o primitive o riferimenti, mai oggetti!
Prima di tutto, definiamo cosa significa “passaggio per riferimento”. Una delle definizioni che preferisco e’ quella di Dale King scritta nel ng comp.lang.java.help: “The lvalue of the formal parameter is set to the lvalue of the actual parameter”. Quindi se ad esempio scriviamo questo codice:
Java Native Access (Parte 2) – Primi passi
Per comprendere l’utilizzo di una tecnologia non c’è nulla di meglio che provarla. Quale migliore esempio se non il classico “Hello, World!”?
Il codice che analizzeremo tra breve è preso direttamente dagli esempi presenti nella guida ufficiale.
HelloWorld.java
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
package it.spicydev.blog.jna; import com.sun.jna.Library; import com.sun.jna.Native; import com.sun.jna.Platform; /** * Date: 1/21/12 7:06 PM * * @author Mircha Emanuel `ryuujin` D'Angelo * @version 1.0 */ public class HelloWorld { /** * Java interface to hold the native library methods extending the Library interface */ public interface CLibrary extends Library { CLibrary INSTANCE = (CLibrary) Native.loadLibrary( (Platform.isWindows() ? "msvcrt" : "c"), CLibrary.class); void printf(String format, Object... args); } public static void main(String[] args) { CLibrary.INSTANCE.printf("Hello, World\n"); CLibrary.INSTANCE.printf("%d %f\n",1,3.14); } } |
Java Native Access (parte 1) – Introduzione
Se è necessario accedere a delle funzionalità offerte da librerie native compilate per il sitema su cui girerà il nostro programma (host), si utlizzano le JNI. Attraverso di esse è possibile scrivere una nostra libreria in codice nativo (C, C++) che fa da ponte tra la nostra class Java e i metodi della libreria nativa che intendiamo utilizzare.
Con la libreria Java Native Access (JNA) non è più necessario. Essa ci consente di accedere alle risorse di una libreria dinamica (ovvero shared) scrivendo solo codice Java.
Per chi conosce Python, avrà sentito parlare di CTypes che realizza qualcosa di molto simile. Vi consiglio anche di dare un’occhiata a SWIG, ma adesso concentriamoci su JNA.
JNA permette di accedere solo alle risorse di librerie shared o dinamiche (.so in Linux, .dll in windows). Il perché non è possibile utilizzare librerie statiche (.a o .lib) è chiaro se si tiene conto del fatto che sono una sorta di archivio che deve essere staticamente linkato nell’eseguibile. Dato che non è possibile caricare una libreria statica a runtime, è chiaro che non è possibile utilizzare le JNA per servirsene.
Le risorse di una libreria nativa vanno mappate all’interno della classe Java tenendo conto di una relazione di equivalenza tra i tipi. Attraverso Leggi tutto “Java Native Access (parte 1) – Introduzione”
Class Adapter – Design Pattern Strutturale
Lo scopo del pattern Adapter è convertire l’interfaccia di una classe in un’altra interfaccia che i client si aspettano.
E’ definito anche Wrapper e rientra nella categoria dei pattern strutturali.
Penso non sia raro ritrovarsi con tante belle classi di libreria e non poterle usare perche’ incompatibili con l’interfaccia richiesta. Ecco che interviene l’adapter.
L’adapter va usato quando subentrano queste motivazioni:
- una classe di una libreria non puo’ essere usata perche’ incompatibile con l’interfaccia richiesta dalla nostra applicazione
- non e’ possibile (o non conveniente) cambiare l’interfaccia della libreria
- non e’ possibile (o non conveniente) cambiare l’applicazione.
I partecipanti in questo Design Pattern sono:
Singleton – Design Pattern Creazionale
Lo scopo del pattern Singleton è quello di assicurare che una classe ha una sola istanza e provvedere un unico punto di accesso ad essa.
E’ un pattern molto semplice da implementare, ma e’ bene comprendere che non va abusato! Una cosa che cerco di spiegare sempre e’ che un refactoring del codice non introduce benefici solo perche’ e’ stato utilizzato un pattern.
Il Singleton va usato solo quando si verificano queste condizioni: