Tag: java

  • Checkstyle and DetailAST

    If you are running Checkstyle (for checking Java style) and you are stuck with this error:

    checkstyle:
    [checkstyle] Running Checkstyle 6.11.2 on 2324 files
    [checkstyle] Can't find/access AST Node typecom.puppycrawl.tools.checkstyle.api.DetailAST
    

    which is a cryptic error with no whatsoever Google result on how to fix it, stand back: I have the solution!

    You probably have these packages installed in your system:

    % rpm -qa | grep -i antlr
    ant-antlr-1.9.4-9.2.noarch
    antlr-java-2.7.7-103.38.noarch
    antlr-2.7.7-103.38.x86_64
    

    To fix your problem, just remove ant-antlr package from your system.

  • ZeroTurnaround’s Java Tools and Technologies Landscape Report 2016

    As of every year, ZeroTurnaround released the yearly report of their survey about Java and Java-related technologies among professional developers. I find this report very interesting, and I usually compare (or discover) existing technology solutions.

    For example, right now I’m currently thinking about moving to Intellij IDEA.

    How do you measure up against the report?

  • Convert Java to EXE – Why, When, When Not and How

    Today I come across this great article on the various possibilities we have, as developers, to package a Java application in an executable format for all Windows users out there. I have always used JSmooth with success, but it is nice to discover there are more alternatives (and some of them are OSS too!).

  • OSX: Eclipse e Java 7 (senza Java 6)

    Ok, avete installato OSX Mavericks e avete notato che il vostro sistema operativo è sprovvisto di una JVM (finalmente OSX non shippa più con la JVM fornita da Apple).

    Nessuna paura, le istruzioni per installare la JVM/JDK di Oracle sono ancora valide. Ma adesso volete utilizzare Eclipse, che vuole che installiate la vecchia JDK 6 (quella fornita da Apple per intenderci).

    eclipse_java6_install_osx

    Non avrebbe senso installare la JDK 6, abbiamo già la JDK 7. Tutto quello che dobbiamo fare è adattare la JDK 7 in modo che sia “compatibile” con Eclipse.

    Modificate (da root) il file

    /Library/Java/JavaVirtualMachines/jdk.1.7.<…>/Contents/Info.plist

    Sostituite:

    <key>JVMCapabilities</key>
     <array>
      <string>CommandLine</string>
     </array>

    Con:

    <key>JVMCapabilities</key>
     <array>
      <string>JNI</string>
      <string>BundledApp</string>
      <string>WebStart</string>
      <string>Applets</string>
      <string>CommandLine</string>
     </array>

    Logout/Login ed Eclipse userà la nuova JDK 7.

  • Tutte le novità di Java 7

    A metà 2011 è stata rilasciata la versione 7 di Java [nickname Dolphin].
    Due sono le grandi novità di questo rilascio:

    • Java è ora marchiata Oracle (che ha acquisito Sun)
    • La reference implementation è ora OpenJDK (l’implementazione open-source di Java), mentre per le passate versioni rimane HotSpot, la versione di Sun Oracle.

    Le novità più interessanti, dal punto di vista delle API, sono:

    • Una (nuova) versione delle API NIO 2 per la gestione e la navigazione del file-system (come ad esempio: Path, Files)
    • Supporto al multiprocessing (ForkJoinTask / RecursiveTask)
    • La possibilità di usare instanze di String come argomento di switch:
      “`
      switch (s) {
      case "foo": break;
      case "bar": break;
      case "foobar": System.out.println("it's foobar!");
      }
      “`
    • Catturare diversi tipi di Exception con una sola catch [separando le Exception con un ‘|’]:
      “`
      try {
      FileInputStream fi = new FileInputStream("foo.txt");
      }
      catch(FileNotFoundException | IoException e) {
      log.error("error: not found or I/O Exception");
      }
      “`
    • try-with-resource [Automatic Resource Management]: dentro ai blocchi try/catch/finally si rimanda la chiusura degli stream/connessioni al finally. Grazie a try-with-resource è la stessa JVM che si occupa di fare ordine con le risorse utilizzate al termine del blocco.
      “`
      try (FileOutputStream fos = new FileOutputStream(f)) {
      fos.write(buf, 0, len);
      }
      catch (Exception e) {
      log.error(e);
      }
      “`
    • Diamond operator (solo sintassi, evitiamo la ripetizione della classe usando i Generics):
      “`
      List<String> foobar = new ArrayList<>();
      “`
    • Leggibilità dei valori numerici (specifichiamo un separatore ‘_’):
      “`
      long accountNumber = 1234_5678_9012L;
      “`
    • JDBC 4.1 (Annotazioni `@Select` e `@Update` per definire le query, `DataSet` sostituisce ResultSet)
  • FizzBuzz reloaded: le differenze tra Java e Ruby

    Tempo fa vi ho parlato di FizzBuzz, un quiz spesso posto ai programmatori alle prime armi.

    Una variante è la seguente:

    Sommare tutti i numeri da 1 a 200 che non sono multipli di 4 e di 7

    La parte divertente sta nella differenza di espressività tra Java e Ruby per ottenere lo stesso risultato. In Java, infatti:

    public class FizzBuzzReloaded {
        public static void main(String[] args) {
            int sum = 0;
    
            for (int i = 1; i <= 200; i++) {
                if (i % 4 != 0 && i % 7 != 0) {
                                 sum += i;
                }
            }
            System.out.println(sum);
        }
    }
    

    In Ruby, invece, grazie alla funzionalità del linguaggio, possiamo semplicemente scrivere:

    (1..200).select {|n| n % 4 != 0 and n % 7 != 0}.inject(:+)
    
  • jVisualVM: il profiler Java incluso nella JDK

    Mi sono recentemente trovato a dover fare del profiling di prestazioni di un software Java SE. Tra le varie opzioni che avevo a disposizione per il profiling in ambito Java, ho scelto jVisualVM inizialmente perché già incluso nella JVM (a partire dalla versione 1.6, tutte le Sun Java JDK includono il profiler).

    L’esperienza con jVisualVM è stata davvero ottima: il profiler è semplice, facile e completo. Partiamo dall’avvio, molto semplice: da linea di comando si lancia jvisualvm. Ma niente paura, apparirà subito la finestra di profiling, che vi permetterà di fare un attach ai processi Java attualmente attivi sul vostro sistema e che volete monitorare:

    Una volta selezionato il processo che vogliamo monitorare, passeremo al dettaglio e potremo visualizzare l’uso di CPU e heap, nonché il numero di thread allocati dal programma. Possiamo anche fare un sempling del processo, raccogliendo in tempo reale informazioni sull’utilizzo di CPU e heap:

    In generale, jVisualVM è un ottimo profiler per programmi Java: presenta le informazioni in modo semplice e completo; grazie a queste informazioni sono riuscito a diagnosticare (e risolvere) i problemi di performance del programma che stavo analizzando. Non è da sottovalutare, inoltre, che jVisualVM è praticamente disponibile per tutte le piattaforme su cui gira la JVM.

    Vi segnalo infine che è anche possibile integrare anche il profiler con Eclipse.

  • Installare Oracle JDK Java 7 su MacOSX

    Abbiamo già visto come installare la Oracle JDK 7 su Ubuntu (e Linux), ed oggi faremo la stessa cosa su MacOSX. Su OSX il processo è molto più semplice: basta infatti scaricare il dmg (l’unico disponibile per MacOSX, ovvero quello a 64bit) dall’indirizzo ufficiale di Oracle e procedere all’installazione (system-wide).

    Dopo l’installazione, aprite le Java Preferences.app (le trovate in /Applications) e trascinate Java SE 7 in cima alla lista.

    Chiudete, aprite un Terminal.app e digitate java -version. L’output che ne ottenete dovrebbe essere quello della nuova JVM come in figura.

    A titolo informativo, la JVM viene installata in

    /Library/Java/JavaVirtualMachines/1.7.0.jdk

    Tenetelo presente, vi servirà se dovrete impostare Eclipse (o qualche altro applicativo) per recuperare correttamente la JAVA_HOME della JVM appena installata [a breve arriverà un post a riguardo].

    Se volete invece affidarvi a OpenJDK (che è la reference implementation per Java 7), esistono dei pacchetti precompilati che potrete installare scaricandoli dal sito openjdk-osx-build.

  • Java: come scrivere un build.xml di ant per compilare e pacchettizzare (WAR/EAR)

    Come sapete, tutti i Java application server (come ad es. Tomcat) richiedono il deploy di un applicativo sottoforma di un pacchetto EAR. Ma come è composto un pacchetto EAR?

    Un pacchetto EAR non è altro che un file jar (che a sua volta è un file zip) che contiene al suo interno:

    • un descrittore di deploy, sotto la directory META-INF (application.xml) che contiene informazioni di gestione riguardo all’applicazione in corso di deploy, come il nome, il contextpath, etc.
    • generalmente, contiene un file WAR che contiene, al suo interno, il modulo web J2EE dell’applicazioni.

    A sua volta, un file WAR è un file JAR composto da:

    • il file web.xml sotto la directory WEB-INF che definisce la struttura dell’applicazione web.
    • i file compilati (.class) dell’applicazione posti sotto WEB-INF/classes

    Risalendo a ritroso, per creare un EAR è necessario:

    1. Compilare i files dell’applicazione;
    2. Spostarli sotto WEB-INF/classes insieme ai files della webapp (jsp, files statici, etc.)
    3. Creare un WAR (jar)
    4. Creare un EAR inglobando anche il meta-descrittore del deploy

    Per fare tutto questo è sufficiente usare ant (o meglio maven, ma questo ve lo spiegherò in un altro post!) con diversi target. Vediamo un esempio che ho realizzato:

    <?xml version="1.0" encoding="UTF-8"?>
    <project name="prjTest" default="main" basedir="./">
    
    <property name="component-name" value="prjTest" />
    <dirname property="workspace.path" file="${ant.file.prjTest}/.." />
    <dirname property="ear.dir" file="${ant.file.prjTest}" />
    <property name="target.dir" value="${ear.dir}/target" />
    <property name="deploy.dir" value="${ear.dir}/deploy" />
    <property name="deploy.file" value="prjTest.ear" />
    
    <target name="init">
    <mkdir dir="${target.dir}/classes" />
    <mkdir dir="${deploy.dir}" />
    </target>
    <target name="clean">
    <delete dir="${target.dir}" />
    <delete dir="${deploy.dir}" />
    <delete dir="${workspace.path}/prjTest/WebContent/WEB-INF/classes" />
    </target>
    
    <path id="myclasspath">
    <fileset dir="${workspace.path}/prjTest/WebContent/WEB-INF/lib">
    <include name="**/*.jar" />
    </fileset>
    </path>
    
    <target name="main" depends="clean,init">
    <javac srcdir="${workspace.path}/prjTest/JavaSource" destdir="${target.dir}/classes" includes="**/*.java"
    source="${source}" target="${target}"
    classpathref="myclasspath">
    </javac>
    
    <copy todir="${workspace.path}/prjTest/WebContent/WEB-INF">
    <fileset dir="${target.dir}">
    <include name="**/*" />
    <exclude name="**/.metadata/*" />
    </fileset>
    </copy>
    <copy todir="${workspace.path}/prjTest/WebContent/WEB-INF/classes">
    <fileset dir="${workspace.path}/prjTest/JavaSource">
    <include name="**/*.properties" />
    </fileset>
    </copy>
    
    <war destfile="${target.dir}/prjTest.war" webxml="${workspace.path}/prjTest/WebContent/WEB-INF/web.xml">
    <fileset dir="${workspace.path}/prjTest/WebContent" />
    </war>
    
    <ear destfile="${deploy.dir}/prjTest.ear" appxml="${workspace.path}/prjTest/META-INF/application.xml">
    <fileset dir="${target.dir}" includes="*.jar,*.war" excludes="**/.metadata/*" />
    </ear>
    </target>
    </project>
    

    Come potete vedere il target chiamato “main” si occupa di:

    • compilare tutte le classi del progetto (javac) usando il classpath di riferimento
    • copiare i files di configurazione (come il già menzionato web.xml) sotto /WEB-INF (copy)
    • copiare i compilati delle classi sotto /WEB-INF/classes (copy)
    • creare un archivio WAR (war) usando i files specificati in fileset e usando il web.xml specificato sotto webxml
    • creare un archivio EAR (ear) usando i files specificati in fileset usando il meta-application specificato in appxml e copiando i files da fileset.

    Questo è lo scheletro di build.xml che uso per pacchettizzare velocemente un’applicazione J2EE (infatti basta lanciare ant build.xml main) da linea di comando per compilare, copiare tutti i files necessari e creare WAR ed EAR!).

  • Eclipse: impostare un template per l’inserimento di un Logger log4j

    Mi capita spesso, in Eclipse, di inserire il codice per abilitare il logging di una classe tramite log4j:

    private static Logger logger = Logger.getLogger(Klass.class);
    

    Utilizzano i templates, una funzionalità di Eclipse, possiamo evitare di riscrivere tutte le volte questa semplice istruzione. Per impostare un template, in Eclipse, è sufficiente recarsi su: Window > Preferences > Java > Editor > Templates e creiamo un nuovo template.

    Nel campo pattern inseriamo:

    private static Logger logger = Logger.getLogger( ${enclosing_type}.class );
    ${:import(org.apache.log4j.Logger)}
    

    A questo punto, per inserire il logger, è sufficiente utilizzare lo shortcut CTRL+Space per visualizzare gli autocompletamenti, e selezionare “logger” dal menu.