Amazon Corretto 8 Generally Available

https://aws.amazon.com/it/blogs/opensource/amazon-corretto-8-generally-available/

Java e la lotta delle JVM

Oracle ha da poco fatto sapere che le nuove JVM targate Oracle saranno a pagamento: chi voglia usare Java gratuitamente dovrà usare un'implementazione della JDK di terze parti.
La più affermata implementazione della JDK è ovviamente OpenJDK, che è la versione di riferimento tra le VM Java. Ovviamente questa versione, anche se è la base per la JVM Oracle, è molto meno testata, e non ha rilasci LTS, tantoché implementa già la versione 11 delle API.
AWS ha però da poco presentato Corretto, la sua implementazione della JDK versione 8.
Quello che a me è balzato subito all'occhio è la frase usata per presentare il prodotto

"Amazon Corretto is a no-cost, multiplatform, production-ready distribution of the Open Java Development Kit (OpenJDK). Corretto comes with long-term support that will include performance enhancements and security fixes. Amazon runs Corretto internally on thousands of production services and Corretto is certified as compatible with the Java SE standard.[...]"

in 3 righe troviamo: "no cost", "production ready", "long-term support", "certified and compatible with SE standard"

A mettere la ciliegina sulla torta "Amazon runs Corretto internally on thousands of production services"

Se consideriamo che James Gosling, padre di Java, da Maggio 2017 lavora proprio per AWS, (vedi qui) direi che la guerra è appena cominciata.

History and future of OpenJdk

https://www.redhat.com/it/blog/history-and-future-openjdk#

Heroku

Mi sono divertito a vedere alcune soluzioni "Cloud", e cercare di capire punti di forza e debolezza.
Fra tutte quella che per ora preferisco è Heroku, una soluzione che è focalizzata sullo sviluppatore, cercando il più possibile di nascondere la parte infrastrutturale.
Diciamo che è molto semplice mettere su un'applicazione con un db e una WebApp (Tomcat ad esempio). Tutto gira in containers attraverso una runtime. Tutto (configurazione, load balancing, logging, sicurezza) è gestito dall'infrastruttura e completamente trasparente all'utente.
Tutto quello che il team di sviluppo deve fare è sviluppare l'applicazione: alla messa in produzione ci pensa Heroku.
I linguaggi supportati sono molteplici: Java in primis, Php, Node.js, Ruby, Python per citare i più conosciuti. Al momento non è ufficialmente supportato C# ed il Framework .Net, anche se sembra che sia possibile deploiare applicazioni di questo linguaggio (con .Net Core)
Il modo più semplice per deploiare le app è attraverso Git con un semplice comando, anche se è possibile deploiare direttamente un war.
Questi due approcci sono totalmente antitetici: io personalmente preferisco il secondo, perchè posso creare il war, magari pubblicarlo su un repository Maven, ed essere sicuro di poterlo pubblicare "as is" su un ambiente di produzione alla fine di un ciclo di test e Q.A. approval.

Mettiamo insieme Maven e Yeoman

Ho da poco scoperto Yeoman (si, lo so, sono in ritardo) e mi sono subito chiesto: come faccio a mettere insieme il ciclo di sviluppo Maven con il ciclo di sviluppo Yeoman?

La migliore (per ora) risposta che ho trovato è questo Plugin, yeoman-maven-plugin, che fa proprio al caso mio.

Le indagini continuano, per trovare qualcosa di simile in ambiente .Net (bisogna pur mangiare)

Dovessero servire i csv...

Dice che è un formato antico, io intanto ho trovato la libreria giusta.
http://super-csv.github.io/super-csv/index.html

Se poi devi fare questo, è perfetta

Migrating a Spring Web MVC application from JSP to AngularJS

https://spring.io/blog/2015/08/19/migrating-a-spring-web-mvc-application-from-jsp-to-angularjs

Java Maven & AngularJs

L'ho letto un po' velocemente, ma forse c'è la possibilità di integrare un po' più strettamente il ciclo di sviluppo di applicazioni AngularJs con JavaEE.
Qui i dettagli

Serializzare da e verso Xml

"Se i ragazzi di Spring lo hanno scelto, deve avere delle potenzialità"
Questo mi sono detto, quando ho provato ad usare XStream, una libreria per serializzare e deserializzare gli oggetti da XML.
E in effetti, le potenzialità ci sono. Innanzitutto perché xStream permette di serializzare e deserializzare senza uso di annotations, e questo fa davvero TANTO comodo. E poi perché permette, qualora il semplice mapping non bastasse, di scrivere dei converter in modo molto semplice (anzi se magari un po' lungo, visto che si può solo navigare l'albero dei nodi.

Java ed SSH

Recentemente mi son trovato a dover lanciare da Java una serie di comandi su un server linux, ed ho scoperto JSch, un'implementazione di SSH2 tutta in Java.
Pur non essendo intuitivissimo da usare, è però un modo perfetto per lanciare comandi remoti, e scaricare files.

IKVM

Recentemente ho dovuto usare IKVM, una Virtual Machine Java implementata in .Net.
Devo dire che sono partito un po' prevenuto, perché la commistione tra i due mondi mi sembrava strana, ma devo dire che alla fine l'idea mi ha conquistato.
In pratica IKVM permette di creare assembly o eseguibili a partire da jar, e gli rende quindi fruibili da applicazioni .Net.
Dopo aver realizzato il jar basta chiamare ikvmc.exe, con gli appositi parametri, per avere un assembly (parametro -target:library) oppure un eseguibile (parametro -target:exe).
Ciò a cui si deve prestare particolare attenzione è il Class Loading, perché le due V.M. lo gestiscono in modo diverso e ci possono essere incompatibilità.
Nel mio caso, ad esempio, non venivano caricate in maniera corretta alcune risorse contenute nella library: ho dovuto forzare il caricamento della library, pur usandola alla riga successiva. L'ho fatto attraverso il comando

ikvm.runtime.Startup.addBootClassPathAssemby(Assembly.Load(""));

Altra cosa che mi è successa, e a cui non sono stato capace di porre rimedio, è l'impossibilità di chiamare le classi da un oggetto Com fatto in .Net. Questo perchè Com che chiama .Net che istanzia Java genera una StackOverflowException, eccezione generata a livello di Framework, e quindi non trappabile... chiunque abbia notizie sulla fattibilità della cosa mi faccia sapere.

REST client con Spring: un lavoro di tutto riposo.

Ho recentemente avuto la necessità di fare un client REST con Spring.

Niente di più facile!

La classe RestTemplate ha tutto quello che serve all'impresa! Basta implementare qualche metodo e il gioco è fatto!

Ricordate, RestTemplate, e non sarà più come prima.

Activiti o la BPM semplice

Era già un po' che guardavo Activiti, in cerca di un piccolo progetto su cui poterlo testare, e alla fine se ne è presentata la possibilità, quindi ho cominciato a mettere le mani in pasta.
Mi ci ero avvicinato perché jBPM di jBoss mi sembrava un po' troppo pesante, e stavo cercando qualcosa di più snello ma sempre aderente ai concetto del Business Process Management. Inoltre, recentemente Activiti è stato acquisito da Alfresco, per rimpiazzare il loro workflow manager.
Il primo impatto è stato ottimo: esiste un ottimo designer, integrato in Eclipse, che permette di creare in modo semplice i flussi. E' ben fatto, anche se ancora qualcosa non funziona perfettamente, e permette facilmente di creare i flussi e soprattutto di testarli con poco sforzo.
Ma quello che più mi ha ben impressionato è la facilità con cui il tutto si configura. Sia che si opti per distribuire il motore come applicazione web (activiti-explorer.war contiene sia il motore sia un front-end di gestione e "primo utilizzo") che lo si embeddi nel proprio stack (se si usa Spring per i propri progetti tutto va su in un istante) in un attimo l'ambiente è up-and-running. Configurare la base dati è una bazzecola, 4 linee nell'apposito file (tipo database, url, user e password) et voilà, il gioco è fatto.
Insieme ad activiti-explorer si trova activiti-rest, l'applicazione per esporre via Rest tutte le funzionalità, permettendo a qualsiasi applicazione esterna di interagire con la workflow engine. Per far lavorare in sinergia i 2 applicativi è sufficiente farli puntare alla stessa base dati, e il gioco è fatto.
Nel mio caso Rest è stato manna dal cielo, perché mi ha permesso l'interoperatività con altri applicativi.
Partendo praticamente a digiuno in materia, in 4 giorni sono riuscito a installare, configurare, creare un piccolo flusso per le mie esigenze, un client in .Net per alimentare i flussi ed uno in Java per il reporting. Niente male davvero!

EclipseCon Europe - Java 7 in the Enterprise

https://plus.google.com/u/0/103382324948491753575/posts/P9uHMXoQEyF

Benefici della Dependency Injection

http://www.captaindebug.com/2011/10/benefits-of-dependency-injection.html

Java SE 7, 8, 9 - Moving Java Forward

http://blog.eisele.net/2011/10/java-se-7-8-9-moving-java-forward.html

Run Jetty Run

"running a web application in Eclipse should be as simple as 'clicking run' "
Anch'io l'ho sempre pensata così, e la gestione dei server in Eclipse mi era sempre sembrata tanto pesante. E' vero, strutturata in quel modo puoi incastrarci dentro qualsiasi server anche molto complesso, tipo JBoss o WebSphere, ma manca molto di immediatezza.
Se si vogliono fare cose semplici, o si decide di usare piattaforme di base, non c'è un modo "veloce" in Eclipse per configurare il tutto.
Con Run Jetty Run, invece, con un semplice click si può far partire una applicazione web in maniera semplice e leggera.
L'ho trovato veramente molto comodo, e usando maven per creare l'archetipo di progetto mi permette di fare veramente in un batter d'occhio.

Google Datastore e l'annotation @Unique

E' ormai ufficiale che mi sto gingillando da un bel po' con La Google App Engine. Qundo avrò qualcosa di minimamente presentabile vi dirò anche perché.
Devo dire che trovo un bel po' di problemi a lavorare con il Datastore. Sarà che non sono capace, oppure sarà che il prodotto è ancora giovane, ma ogni tanto ci scappa fuori il bug.

L'ultimo è stato l'uso della annotation @Unique nelle entità. Secondo le specifiche JDO questa annotation serve a creare una chiave univoca sulla proprietà a cui si applica. Ad esempio se ho la classe Author fatta così

@PersistenceCapable
public class Author {

 @PrimaryKey
 @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
 private Key id;
 
 @Persistent
 @Unique
 private String name;

   ... omessi getters e setters
}

il Datastore dovrebbe creare una chiave univoca sulla proprietà Name. Facendo qualche test mi sono accorto che questo non succede. Ho cercato un po' per vedere se qualcuno ha avuto i miei stessi problemi ed ho trovato questo. Il comportamento riscontrato è quindi un bug riconosciuto.
Come fare quindi? Per fortuna la Key può anche essere generata, non solo calcolata automaticamente: si può quindi seguire questo metodo. Se si segue il pattern Dao si avrà sempre una classe per gestire le entità. Nel mio caso la classe si chiama, con molta fantasia, AuthorDao e, prima di salvare l'entità sarà sufficiente calcolare la chiave nel seguente modo

In questo modo la chiave sarà la stessa a parità di nome, e quindi sarà garantita l'univocità.

Google App Engine e le relazioni

Visto che voglio capire di più su come sono fatte le api Google App Engine per il DataStore mi sono chiesto: "come si gestiscono le relazioni?"
La pagina che spiega tutto è questa. In pratica la limitazione più forte che ho riscontrato è che, per creare una relazione tra due entità queste devono avere come chiave primaria un oggetto di tipo Key: questo perché l'oggetto Key supporta le informazioni sulla parent key. Leggendo la documentazione su Key si legge che "If the class is used as a "child" class in a relationship, the key field must be of a type capable of representing an entity group parent: either a Key instance, or a Key value encoded as a string." Evidentemente il meccanismo di storage delle informazioni ha bisogno di creare legami tra le classi, e questo è l'unico modo che ha per farlo.
Speriamo in futuri miglioramenti.

Google AppEngine e le Query in Java

Ho giocato un po' con Google App Engine.
In particolare ho cercato di capire come funziona la gestione del database da un'applicazione Java.
Google App Engine store i suoi dati su quello che viene chiamato Datastore. Il Datastore azzera totalmente per l'utente la gestione di replica, bilanciamento di carico e backup, che è tutta a carico dell'infrastruttura.
L'accesso ai dati viene quindi fatto attraverso un set di API, rese disponibili da Google. Sopra queste API è stato creato un meccanismo che permette di accedere ai dati in due modi standard: o via JPA, le Java Persistence API delle specifiche J2EE, o via JDO, i Java Data Objects di Apache.
Queste due tipologie di accesso vengono rese disponibili attraverso il framework DataNucleus, che si occupa di tradurre (fra l'altro in fase di compilazione) la gestione degli oggetti di persistenza.
La documentazione di Google focalizza i suoi esempi sull'uso di JDO, che non conoscevo, e che quindi mi ha stuzzicato l'appetito.
Per fare un test ho provato a creare una classe Author, con le sole proprietà id e name, fatta così

Le annotations contenute in questa classe consentono a DataNucleus di mappare la classe su una tabella.
Le chiavi primarie per il DataStore sono di tre tipi: Long, Key (un tipo dati custom del DataStore) o String: questo tipo di dati in particolare deve essere gestito dall'applicativo, non viene mai calcolato automaticamente.
Il DataStore richiede che un oggetto abbia una chiave primaria.
Nel mio esempio non volevo usare una String come chiave primaria, ma volevo però che il nome fosse univoco, ed ho quindi taggato con l'annotation @Unique la proprietà name.
Per salvare un oggetto è sufficiente, ottenuto quello che si chiama un PersistenceManager, invocare il metodo makePersistent(Object o).
Ora, supponiamo di aver salvato una serie di autori che iniziano con la A, ad esempio Asimov, Aristotele, Alighieri e di volergli ritrovare.
Se stessi usando Hibernate recupererei una Session, aggiungerei Criteria e Restrictions oppure farei una Query in HSQL.
Con JDO, guardando la documentazione, si ottiene un oggetto Query e su quello si può usare il metodo setFilter o il linguaggio JDOQL, simile a HSQL.
Vediamo quindi come scrivere una query che trovi tutti gli autori che cominciano per A

Dall'esempio si vede che, recuperato il PersistenceManager attraverso una classe si utilità, si crea una Query e su quella, dichiarato che si stanno facendo query sulla classe Author, si applica un filtro.
La clausola SQL LIKE si esprime in JDOQL con .startsWith() e poi si dichiarano i parametri  con la sintassi ; 
Il metodo execute() della query recupera gli oggetti precedentemente salvati. Google App Engine ha un bug in questa operazione: quando gli oggetti vengono sganciati ("detached") dal DataStore, se si tenta di scorrere la List, viene lanciata un'eccezione. Bisogna quindi chiamare il metodo .size() prima di chiudere il PersistenceManager, per permettere il corretto caricamento di tutto l'array.

Tutto qua, per ora, il prossimo step sarà capire come gestire le relazioni 1-n e soprattutto come recuperare entità partendo dalla relazione figlia.
See You Next Time!!!