Java SE 8u9[1|2] Update

Alles News unter http://www.oracle.com/technetwork/java/javase/8all-relnotes-2226344.html.

Interessanbt finde ich unter anderem:

New JVM Options added: ExitOnOutOfMemoryError and CrashOnOutOfMemoryError
Two new JVM flags have been added:

  • ExitOnOutOfMemoryError – When you enable this option, the JVM exits on the first occurrence of an out-of-memory error. It can be used if you prefer restarting an instance of the JVM rather than handling out of memory errors.
  • CrashOnOutOfMemoryError – If this option is enabled, when an out-of-memory error occurs, the JVM crashes and produces text and binary crash files (if core files are enabled).

See JDK-8138745.

Und:

Disable MD5withRSA signature algorithm in the JSSE provider
The MD5withRSA signature algorithm is now considered insecure and should no longer be used. Accordingly, MD5withRSA has been deactivated by default in the Oracle JSSE implementation by adding „MD5withRSA“ to the „jdk.tls.disabledAlgorithms“ security property. Now, both TLS handshake messages and X.509 certificates signed with MD5withRSA algorithm are no longer acceptable by default. This change extends the previous MD5-based certificate restriction („jdk.certpath.disabledAlgorithms“) to also include handshake messages in TLS version 1.2. If required, this algorithm can be reactivated by removing „MD5withRSA“ from the „jdk.tls.disabledAlgorithms“ security property.

JDK-8144773 (not public)

 

Bouncing ball in a Swing window

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class BouncingBall {

  private static class BallPanel extends JPanel {

    // http://www.iconfinder.com/icondetails/8839/64/beach_ball_tourism_toys_icon
    private final Icon ball = new ImageIcon( BouncingBall.class.getResource( "ball.png" ) );
    private int ballX, ballY, dx = 2, dy = 2;

    public BallPanel() {
      new Timer( 10, new ActionListener() {
        @Override
        public void actionPerformed( ActionEvent evt ) {
          ballX += dx;
          ballY += dy;

          if ( ballX <= 0 || ballX + ball.getIconWidth() >= getWidth() )
            dx = -dx;
          if ( ballY <= 0 || ballY + ball.getIconHeight() >= getHeight() )
            dy = -dy;

          repaint();
        }
      } ).start();
    }

    @Override
    public void paint( Graphics g ) {
      Graphics2D g2d = (Graphics2D) g;
      g2d.setRenderingHint( RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON );
      g2d.setRenderingHint( RenderingHints.KEY_RENDERING, RenderingHints.VALUE_RENDER_QUALITY );

      g2d.setColor( Color.WHITE );
      g2d.fill( getBounds() );

      ball.paintIcon( null, g2d, ballX, ballY );
    }
  }

  public static void main( String[] args ) {
    JFrame f = new JFrame();
    f.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
    f.setIgnoreRepaint( true );
    f.add( new BallPanel() );
    f.setBounds( 200, 100, 400, 200 );
    f.setVisible( true );
  }
}

Retrieve Windows netstat data and observe new network connections

import java.io.IOException;
import java.util.*;
import java.util.concurrent.TimeUnit;
import java.util.regex.Pattern;

public class Netstat {

  public static class Protocol {

    public final String protocol;
    public final String localAddress;
    public final String remoteAddress;
    public final String status;

    public Protocol( String protocol, String localAddress, String remoteAddress, String status ) {
      this.protocol = protocol;
      this.localAddress = localAddress;
      this.remoteAddress = remoteAddress;
      this.status = status;
    }

    @Override
    public int hashCode() {
      return Objects.hash( localAddress, protocol, remoteAddress, status );
    }

    @Override
    public boolean equals( Object obj ) {
      if ( this == obj )
        return true;
      if ( obj == null )
        return false;
      if ( getClass() != obj.getClass() )
        return false;
      Protocol other = (Protocol) obj;
      if ( localAddress == null && other.localAddress != null )
        return false;
      else if ( !localAddress.equals( other.localAddress ) )
        return false;
      if ( protocol == null && other.protocol != null )
        return false;
      else if ( !protocol.equals( other.protocol ) )
        return false;
      if ( remoteAddress == null && other.remoteAddress != null )
        return false;
      else if ( !remoteAddress.equals( other.remoteAddress ) )
        return false;
      if ( status == null && other.status != null )
        return false;
      else if ( !status.equals( other.status ) )
        return false;
      return true;
    }

    @Override
    public String toString() {
      return String.format( "%-6s %-22s %-22s %s", protocol, localAddress, remoteAddress, status );
    }
  }

  private final static Pattern pattern = Pattern.compile( "(TCP|UDP)\\s+(\\S+)\\s+(\\S+)\\s+(\\S+)" );

  public static Collection<Protocol> netStat() throws IOException {
    Collection<Protocol> result = new ArrayList<>();
    Process p = new ProcessBuilder( "netstat", "-n" ).start();
    try ( Scanner scanner = new Scanner( p.getInputStream() ) ) {
      while ( scanner.findWithinHorizon( pattern, 0 ) != null )
        result.add( new Protocol( scanner.match().group( 1 ), scanner.match().group( 2 ),
                                   scanner.match().group( 3 ), scanner.match().group( 4 ) ) );
    }
    return result;
  }

  public static void main( String[] args ) throws IOException, InterruptedException {
    Set<Protocol> oldStat = new HashSet<>( netStat() );

    while ( true ) {
      TimeUnit.SECONDS.sleep( 10 );

      HashSet<Protocol> newStat = new HashSet<>( netStat() );

      Set<Protocol> differenceSet = new HashSet<>( newStat );
      differenceSet.removeAll( oldStat );

      for ( Protocol p : differenceSet )
        System.out.println( p );

      oldStat = newStat;
    }
  }
}

Offene Stelle Junior Software-Entwickler in Frankfurt

Zur Unterstützung unseres Teams suchen wir eine(n)

Junior Software – Entwickler / Developer Java (m/w)

 

Ihre Aufgaben:
  • Mitarbeit an der Weiterentwicklung unserer Java Software-Produkte für statistische Fragestellungen
  • Mitarbeit an der Neuentwicklung eines Frameworks zur Automatisierung unserer Arbeitsabläufe und zur Integration in bestehende Auswertungssysteme unseres Kunden
  • Mitarbeit an der Weiterentwicklung unserer bestehenden Java-Software zum Einsatz in Big Data Umfeldern

 

Ihr Profil:
  • abgeschlossenes Studium mit IT-Bezug bzw. eine entsprechende Ausbildung zum (Fach)-Informatiker
  • gute Kenntnisse in Core Java, Java EE, Java SE (relevante Uni-, Ausbildungs- oder Praxiserfahrung)
  • gute Kenntnisse in Eclipse, Git, Linux Shell
  • Praxiserfahrung als Softwareentwickler wünschenswert
  • Selbständiges Arbeiten
  • Teamfähigkeit, Engagement und Kreativität
  • sehr gute Deutschkenntnisse in Wort und Schrift

 

Wir bieten:
  • unbefristete Festanstellung
  • interessante Aufgaben und überdurchschnittliche finanzielle Entwicklungsmöglichkeiten
  • kleines, motiviertes Team mit flachen Hierarchien
  • freundliches und dynamisches Arbeitsumfeld in der Frankfurter Innenstadt (S/U-Bahn-Station Konstablerwache)
  • eine solide berufliche Zukunft
  • flexible Arbeitszeiten
  • Reisetätigkeit nur in Ausnahmefällen
  • Beginn ab sofort, bzw. nach Absprache

 

Interesse:
  • Dann freuen wir uns unter dem Betreff „Stellenangebot Junior Software-Entwickler / Developer Java” auf Ihre aussagekräftige Bewerbung (ausschließlich via E-Mail) mit Angabe der Gehaltsvorstellung und des möglichen Eintrittstermins.

 

Ankordata
Ankordata GmbH & Co. KG
Jens Grüntjes
Zeil 57
60313 Frankfurt
Tel.: 069 / 92 88 79-18
E-Mail: jens.gruentjes@ankordata.de
Anzeige online unter http://www.ankordata.de/homepage/Jobs.action.

Apache POI 3.14-beta1 ist erschienen

Was es für Änderungen gibt? https://poi.apache.org/changes.html

The Apache POI team is pleased to announce the release of 3.14-beta1. Featured are a handful of new areas of functionality – including basic support for the XML Visio format – and numerous bug fixes.

A summary of changes is available in the Release Notes. A full list of changes is available in the change log. People interested should also follow the dev list to track progress.

The POI source release as well as the pre-built binary deployment packages are listed below. Pre-built versions of all POI components are available in the central Maven repository under Group ID „org.apache.poi“ and Version „3.14-beta1“

Alles Gute …

… zum Weihnachtsfest und einen guten Rutsch ins neue Jahr.

          *             ,
                       _/^\_
                      <     >
     *                 /.-.\         *
              *        `/&\`                   *
                      ,@.*;@,
                     /_o.I %_\    *
        *           (`'--:o(_@;
                   /`;--.,__ `')             *
                  ;@`o % O,*`'`&\ 
            *    (`'--)_@ ;o %'()\      *
                 /`;--._`''--._O'@;
                /&*,()~o`;-.,_ `""`)
     *          /`,@ ;+& () o*`;-';\
               (`""--.,_0 +% @' &()\
               /-.,_    ``''--....-'`)  *
          *    /@%;o`:;'--,.__   __.'\
              ;*,&(); @ % &^;~`"`o;@();         *
              /(); o^~; & ().o@*&`;&%O\
        jgs   `"="==""==,,,.,="=="==="`
           __.----.(\-''#####---...___...-----._
         '`         \)_`"""""`
                 .--' ')
               o(  )_-\
                 `"""` `

Setzen des Java Klassenpfades

Wo die JVM die Klassen findet muss ihr mitgeteilt werden, und das ist in der Praxis elementar für die Auslieferung, auch englisch Deloyment genannt. Java wartet mit dem Laden der Klassen so lange, bis sie benötigt werden. Es gibt zum Beispiel Programmabläufe nur zu besonderen Bedingungen und wenn dann erst spät ein neuer Typ referenziert wird, der nicht vorhanden ist, fällt dieser Fehler erst sehr spät auf. Der JVM müssen folglich nicht nur die Quellen für Klassen und Ressourcen der eigenen Applikation mitgeteilt werden, sondern alle vom Programm referenzierten Typen aus zum Beispiel quelloffenen und kommerziellen Bibliotheken.

Sollen in einem Java-Projekt Dateien aus einem Verzeichnis oder einem externen Java-Archiv geholt werden, so ist der übliche Weg, diese Verzeichnisse oder Archive in einem Klassenpfad anzugeben. Diese Angabe ist für alle SDK-Werkzeuge notwendig – am Häufigsten ist sie beim Compiler und bei der Laufzeitumgebung zu sehen.

Schalter -classpath

Die Suchorte lassen sich flexibel angeben, wobei die erste Variante einem SDK-Werkzeug über den Schalter -classpath (kurz -cp) die Klassendateien bzw. Archive liefert:

$ java -classpath classpath1;classpath2 MainClass

Der Klassenpfad enthält Wurzelverzeichnisse der Pakete und JAR-Dateien, also Archive von Klassendateien und Ressourcen.

Beispiel: Nimm ein Java-Archiv library.jar im aktuellen Verzeichnis, die Ressourcen unter dem bin-Verzeichnis und alle JAR-Dateien im Verzeichnis lib in den Klassenpfad mit auf:

$ java -cp "library.jar;bin/.;lib/*" com.tutego.MainClass

Unter Windows ist der Trenner ein Semikolon, unter Unix ein Doppelpunkt! Das Sternchen steht für alle JAR-Dateien, es ist kein üblicher Wildcard, wie z.B. parser*.jar.[1] Sehen Kommandozeilen der Betriebssysteme ein *, beginnen sie in der Regel eine eigenen Verarbeitung; daher muss die gesamte Pfadangabe in doppelten Anführungszeichen stehen.

Umgebungsvariable CLASSPATH

Eine Alternative zum Schalter -cp ist das Setzen der Umgebungsvariablen CLASSPATH mit einer Zeichenfolge, die Pfadangaben spezifiziert:

$ SET CLASSPATH=classpath1;classpath2
$ java MainClass

Problematisch ist der globale Charakter der Variablen, sodass lokale -cp-Angaben besser sind. Außerdem „überschreiben“ die -cp-Optionen die Einträge in CLASSPATH. Zu guter Letzt: ist weder CLASSPATH noch eine -cp-Option gesetzt, besteht der Klassenpfad für die JVM nur aus dem aktuellen Verzeichnis, also „.“.

[1]      Weitere Details unter https://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html.

Klassenlader (Class Loader) und Klassenpfad

Ein Klassenlader ist dafür verantwortlich, eine Klasse zu laden. Aus der Datenquelle (im Allgemeinen einer Datei) liefert der Klassenlader ein Byte-Array mit den Informationen, die im zweiten Schritt dazu verwendet werden, die Klasse ins Laufzeitsystem einzubringen; das ist Linking. Es gibt vordefinierte Klassenlader und die Möglichkeit, eigene Klassenlader zu schreiben, um etwa verschlüsselte und komprimierte .class-Dateien aus Datenbanken zu laden.

Klassenladen auf Abruf

Nehmen wir zu Beginn ein einfaches Programm mit zwei Klassen:

class Person {
   static String NOW = java.time.LocalDateTime.now().toString();
   public static void main( String[] args ) {
     Dog wuffi = new Dog();
   }
 }
 
 class Dog {
   Person master;
 }

Wenn die Laufzeitumgebung das Programm Person startet, muss sie eine Reihe von Klassen laden. Das tut sie dynamisch zur Laufzeit. Sofort wird klar, dass es zumindest Person sein muss. Wenn aber die statische main(String[])-Methode aufgerufen wird, muss auch Dog geladen sein. Und da beim Laden einer Klasse auch die statischen Variablen initialisiert werden, wird auch die Klasse LocalDateTime geladen.

Zwei weitere Dinge werden nach einiger Überlegung deutlich:

  • Wenn Dog geladen wird, bezieht es sich auf Person. Da Person aber schon geladen ist, muss es nicht noch einmal geladen werden.
  • Unsichtbar stecken noch andere referenzierte Klassen dahinter, die nicht direkt sichtbar sind. So wird zum Beispiel Object geladen, da implizit in der Klassendeklaration von Person steht: class Person extends Object. Auch String muss geladen werden, weil String einmal in der Signatur von main(String[]) vorkommt und es der Typ von now Intern ziehen die Typen viele weitere Typen nach sich. String implementiert Serializable, CharSequence und Comparable, also müssen diese drei Schnittstellen auch geladen werden. Und so geht das weiter, je nach dem, welche Programmpfade abgelaufen werden. Wichtig ist aber zu verstehen, dass diese Klassendateien so spät wie möglich geladen werden.

Im Beispiel mit den Klassen Person und Dog lädt die Laufzeitumgebung selbstständig die Klassen (implizites Klassenladen). Klassen lassen sich auch mit Class.forName(String) über ihren Namen laden (explizites Klassenladen).

Hinweis. Um zu sehen, welche Klassen überhaupt geladen werden, lässt sich der virtuellen Maschine beim Start der Laufzeitumgebung ein Schalter mitgeben -verbose:class. Dann gibt die Maschine beim Lauf alle Klassen aus, die sie lädt.

JAR-Dateien

Große Sammlungen von Java-Klassendatein und Ressourcen werden in sogenannten Java-Archiven, kurz JAR-Dateien, zusammengefasst. Diese Dateien sind im Grunde ganz normale ZIP-Archive mit einem besonderen Verzeichnis META-INF für Meta-Dateien. Das JDK bringt im bin-Verzeichnis das Werkzeug jar zum Aufbau und Extrahieren von JAR-Dateien mit.

JAR-Dateien behandelt die Laufzeitumgebung wie Verzeichnisse von Klassendateien und Ressourcen. Wenn Java-Software ausgeliefert wird, dann bieten sich JAR-Dateien an, denn es ist einfacher, nur ein komprimiertes Archiv weiterzugehen als einen großen Dateibaum. Zudem haben Java-Archive den Vorteil, dass sie signiert werden können und illegale Änderungen auffallen.

Woher die kleinen Klassen kommen: Die Suchorte und spezielle Klassenlader

Die Laufzeitumgebung nutzt zum Laden nicht nur einen Klassenlader, sondern mehrere. Die Java-Laufzeitumgebung nutzt diese verschiedenen Klassenlader um unterschiedliche Orte festzulegen. Ein festes Schema bestimmt die Suche nach den Klassen:

  1. Klassen Typen wie String, Object oder Point stehen in einem ganz speziellen Archiv. Wenn ein eigenes Java-Programm gestartet wird, so sucht die virtuelle Maschine die angeforderten Klassen zuerst in diesem Archiv. Da es elementare Klassen sind, die zum Hochfahren eines Systems gehören, werden sie Bootstrap-Klassen Das Archiv mit diesen Klassen heißt oft rt.jar (für Runtime). Andere Archive können hinzukommen – wie i18n.jar, das Internationalisierungsdaten beinhaltet. Die Implementierung dieses Bootstrap-Klassenlader ist nicht öffentlich und wird von System zu System unterschiedlich sein. Ab Java 9 wird sich das grundlegend ändern.
  2. Ist eine Klasse keine Bootstrap-Klasse, beginnt der System-Klassenlader Applikations-Klassenlader die Suche im Klassenpfad (Classpath). Diese Pfadangabe besteht aus einer Aufzählung einzelner Klassendateien, Verzeichnisse, Klassen oder JAR-Archive, in denen die Laufzeitumgebung nach den Klassendateien sucht. Standardmäßig ist dieser Klassenpfad auf das aktuelle Verzeichnis gesetzt („.“), er lässt sich aber beliebig setzen.

Kompakte Strings nun in Java 9 (JEP 254)

Wenn ein String nur aus Latin-1 Buchstaben besteht, dann kann die Zeichenfolge aus einem byte- statt einem char-Feld bestehen. Diese Änderung wurde in Java 9 nun umgesetzt: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4f6e52f9dc79. Gerade bei IDs lässt sich so 1/2 vom Speicher sparen. Und da Strings immutable sind, muss man nicht konvertieren.

Teurer wird es beim „Mischen“ wie:

String /*intern char[]*/ s  =  "λφα";
String /*intern char[]*/ t  =  " " /*intern byte[]*/
                                +
                                s  /*intern char[]*/;

Intern wird hier eine inflate()-Methoden aufgerufen:

If the coder is "isLatin1", this inflates the internal 8-bit storage to 16-bit <hi=0, low> pair storage.

Inselraus: Swings JLayeredPane

Die JLayeredPane nimmt JComponent-Objekte auf und stellt sie in einer geschichteten Reihenfolge (auch Z-Order genannt) dar. Die Layered Pane besteht selbst wieder aus zwei Objekten, einer Menüzeile und der Inhaltsfläche Content-Pane. Container vom Typ JLayeredPane platzieren ihre Kinder in Ebenen (engl. layers). Jedem Kind wird eine Ebene zugewiesen, und beim Zeichnen werden die Kinder von unten nach oben gezeichnet. Damit werden die Komponenten, die unter anderen Komponenten liegen, unter Umständen verdeckt. Standardmäßig hat die JLayeredPane keinen zugewiesenen Layoutmanager, und Objekte müssen mit setBounds(…) positioniert werden.

Wird ein JLayeredPane-Container verwendet, ist die add(…)-Methode so implementiert, dass sie die Komponenten auf einer Standardebene (JLayeredPane.DEFAULT_LAYER) platziert. Um Komponenten auf eine eigene Ebene zu setzen, sodass sie vor oder hinter anderen Komponenten liegen, wird ihnen eine eigene Ebene zugewiesen, und zwar mit einem Wert relativ zu DEFAULT_LAYER. Kleinere Werte bedeuten, dass die Komponenten unten liegen, und hohe bedeuten, dass sie oben liegen. Ein Beispiel:

layeredPane.add( component, new Integer(5000) );

Für einige Ebenen sind Werte als Konstanten deklariert. Dazu zählen zum Beispiel JLayered-Pane.DEFAULT_LAYER (0), PALETTE_LAYER (100), MODAL_LAYER (200), POPUP_LAYER (300) und DRAG_LAYER (400).

Neben der Möglichkeit, die Ebenen festzulegen, lässt sich die Reihenfolge innerhalb der Ebene später durch die Methode moveToFront() oder moveToBack() verändern.

Inselraus: Swings JRootPane und JDesktopPane

Unter den JComponent-Objekten gibt es einige ausgezeichnete, die als Container für andere Kinder fungieren.

Wurzelkomponente der Top-Level-Komponenten (JRootPane)

Die Komponenten JFrame, JDialog, JWindow, JApplet und JInternalFrame enthalten als einziges Kind den leichtgewichtigen Container JRootPane. Die Methode getRootPane() liefert dieses JRootPane-Objekt. Die JRootPane verwaltet eine Layered Pane, die wiederum Content-Pane und Menü aufnimmt, und eine Glass-Pane, die wie eine Glasscheibe über allen anderen Komponenten liegt. Sie kann Ereignisse abfangen oder in einer paint(…)-Methode etwas über alle Komponenten zeichnen.

Beispiel: Weise der Glass-Pane einen wartenden Cursor zu:

Component c = getRootPane().getGlassPane();
 if( c != null )
   c.setCursor( Cursor.getPredefinedCursor( Cursor.WAIT_CURSOR ) );

 JDesktopPane und die Kinder von JInternalFrame

Die JDesktopPane ist eine Unterklasse von JLayeredPane und als Container für interne Fenster – also Objekte vom Typ JInternalFrame – gedacht. Mit internen Fenstern (engl. internal frames) lassen sich MDI-Applikationen implementieren, also GUI-Anwendungen, bei denen nicht das grafische Betriebssystem die Fenster verwaltet, sondern die eigene Anwendung.

Bevor ein JInternalFrame sichtbar wird, muss der Container erzeugt und sichtbar gemacht werden:

JDesktopPane desktop = new JDesktopPane();
 container.add( desktop );

Jetzt können beliebig viele JInternalFrame-Objekte erzeugt und auf der JDesktopPane platziert werden. Der einfachste Konstruktor ist der Standard-Konstruktor, der einen nicht vergrößerbaren, nicht schließbaren, nicht maximierbaren und nicht zum Icon verkleinerbaren JInternal-Frame ohne Titel erzeugt. Der ausführlichste Konstruktor erlaubt eine genaue Parametrisierung:

JInternalFrame iframe = new JInternalFrame( title, resizable, closeable,
   maximizable, iconifiable );

Zwar gibt es nun ein Exemplar, doch wäre es nach dem Aufsetzen auf den Container noch nicht sichtbar:

iframe.setVisible( true );

Bis zur Vollständigkeit fehlen aber noch die Maße:

iframe.setSize( /* width = */ 200, /* height = */ 100 );

Nun kann der iframe dem Container hinzugefügt werden:

desktop.add( iframe );

In einem kompletten Programm kann das so aussehen:

package com.tutego.insel.ui.swing;
 
 import javax.swing.*;
 import static java.lang.Math.random;
 
 public class JInternalFrameDemo {
 
   static void addInternalToDesktop( JDesktopPane desktop )
   {
     JInternalFrame iframe;
     iframe = new JInternalFrame( "Ein internes Fenster",  // title
                                  true,                    // resizable
                                  true,                    // closeable
                                  true,                    // maximizable
                                  true );                  // iconifiable
 
     iframe.setBounds( (int)(random() * 100), (int)(random() * 100),
                       100 + (int)(random() * 400), 100 + (int)(random() * 300) );
     iframe.add( new JScrollPane(new JTextArea()) );
     iframe.setVisible( true );
 
     desktop.add( iframe );
   }
 
   public static void main( String[] args ) {
     JFrame f = new JFrame();
     f.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
     JDesktopPane desktop = new JDesktopPane();
     f.add( desktop );
     f.setSize( 500, 400 );
     addInternalToDesktop( desktop );
     addInternalToDesktop( desktop );
     addInternalToDesktop( desktop );
     f.setVisible( true );
   }
 }

Hinweis: Die Schnittstelle von JInternalFrame erinnert an JFrame, doch ist die Ereignisbehandlung anders. So besitzt JInternalFrame eine Methode addInternalFrameListener(…) an Stelle von addWindowListener(…). Ein JInternalFrame empfängt keine WindowEvents, daher darf es addWindowListener(…) – wie es JFrame von java.awt.Window erbt – auch nicht besitzen.