Neue Methoden in Byte:

• static int toUnsignedInt(byte x)
• static long toUnsignedLong(byte x)

In Integer:

• static String toUnsignedString(int i, int radix)
• static String toUnsignedString(int i)
• static int parseUnsignedInt(String s, int radix)
• static int compareUnsigned(int x, int y)
• static long toUnsignedLong(int x)
• static int divideUnsigned(int dividend, int divisor)
• static int remainderUnsigned(int dividend, int divisor)

In Long:

• String toUnsignedString(long i, int radix)
• static String toUnsignedString(long i)
• static long parseUnsignedLong(String s, int radix)
• static int compareUnsigned(long x, long y)
• static long divideUnsigned(long dividend, long divisor)
• static long remainderUnsigned(long dividend, long divisor)

In Short:

• static int toUnsignedInt(short x)
• static long toUnsignedLong(short x)

A diagnostic command is an action that can be invoked dynamically mainly for troubleshooting and diagnosis.

Die Idee ist also, das man ein Kommandozeilentool jcmd hat, mit dem man Kommandos an die JVM schicken kann. Dabei sind unterschiedliche Kommandos vordefiniert. Mit dem Argument PerfCounter.perf werden Performance-Kenngrößen ausgegeben.

Ich habe das Tool auf den Beispielen meines Buches angewendet und die meisten Hinweise beziehen sich auf Diamond und natürlich im IO-Kapitel auf auf try-mit-Ressourcen. Damit habe ich heute den ganzen Tag verbracht und auch noch ein paar kleine Fehler gefunden. Eine Stelle ist interessant:

XMLOutputFactory factory = XMLOutputFactory.newInstance();
XMLStreamWriter writer = factory.createXMLStreamWriter( new FileOutputStream( "writenParty.xml" ) );

XMLStreamWriter hat close() aber kein AutoCloseable. Kann man als Fehler ansehen.

Das hier formt der Konverter nicht um, er beginnt erst bei “fett” mit dem switch, das liegt am zweiten if, was nicht als if else formuliert ist.

if ( "Ende".equals(e.getActionCommand()) )
  System.exit( 0 );
if ( "fett".equals(e.getActionCommand()) )
  t.setFont( font = font.deriveFont( font.getStyle() ^ Font.BOLD ) );
else if ( "kursiv".equals(e.getActionCommand()) )
  t.setFont( font = font.deriveFont( font.getStyle() ^ Font.ITALIC ) );

interface BaseColors

{

  int WHITE   = 0;

  int BLACK   = 1;

  int GREY    = 2;

}


interface CarColors extends BaseColors

{

  int WHITE   = 1;

  int BLACK   = 0;

}


interface PlaneColors extends BaseColors

{

  int WHITE   = 0;

  int GREY    = 2;

}


interface FlyingCarColors extends CarColors, PlaneColors

{

}


public class Colors

{

  public static void main( String[] args )

  {

    System.out.println( BaseColors.GREY );      // 2

    System.out.println( CarColors.GREY );       // 2

    System.out.println( BaseColors.BLACK );     // 1

    System.out.println( CarColors.BLACK );      // 0

    System.out.println( PlaneColors.BLACK );    // 1


    System.out.println( FlyingCarColors.WHITE );//  The field FlyingCarColors.WHITE is ambiguous

    System.out.println( FlyingCarColors.GREY ); //  The field FlyingCarColors.GREY is ambiguous

  }

}

Die erste wichtige Tatsache ist, dass unsere drei Schnittstellen ohne Fehler übersetzt werden können, aber nicht die Klasse Colors. Das Programm und der Compiler zeigen folgendes Verhalten:

• Schnittstellen vererben ihre Eigenschaften an die Unterschnittstellen. CarColors und auch PlaneColors erbten die Farbe WHITE, BLACK und GREY aus BaseColors.
• Konstanten dürfen überschattet werden. CarColors vertauscht die Farbdeklarationen von WHITE und BLACK und gibt ihnen neue Werte. Wird jetzt der Wert CarColors.BLACK verlangt, liefert die Umgebung den Wert 0, während CarColors.BLACK 1 ergibt. Auch PlaneColor überdeckt die Konstanten WHITE und GREY obwohl sie Farbe mit dem gleichen Wert belegt sind.
• Erbt eine Schnittstelle von mehreren Oberschnittstellen, so ist es zulässig, wenn die Oberschnittstellen jeweils ein gleichlautendes Attribut haben. So erbt etwa FlyingCarColors von CarColors und PlaneColors den Eintrag WHITE, BLACK und GREY.
• Unterschnittstellen können aus zwei Oberschnittstellen die Attribute gleichen Namens übernehmen, auch wenn sie einen unterschiedlichen Wert haben. Das testet der Compiler nicht. FlyingCarColors bekommt aus CarColors ein WHITE mit 1 aber aus PlaneColors das Weiß mit 0. Daher ist auch der Zugriff FlyingCarColors.WHITE in dem Beispiel Colors auch nicht möglich und führt zu einem Compilerfehler. Bei der Benutzung muss ein unmissverständlicher qualifizierter Name verwendet werden, der deutlich macht, welches Attribut gemeint ist, also zum Beispiel CarColors.WHITE oder PlaneColors.WHITE. Ähnliches gilt für die Farbe GREY. Obwohl Grau durch die ursprüngliche Deklaration bei BaseColor und auch bei der Überschattung in PlaneColors immer Zwei ist, ist die Nutzung durch FlyingCarColors.GREY nicht zulässig. Das ist ein guter Schutz gegen Fehler, denn wenn der Compiler dies durchließe, könnte sich im Nachhinein die Belegung von GREY in BaseColors oder PlaneColors ohne Neuübersetzung aller Klassen ändern, und zu Schwierigkeiten führen. Diesen Fehler – die Oberschnittstellen haben für eine Konstante unterschiedliche Werte – müsste die Laufzeitumgebung erkennen. Doch das ist nicht möglich und in der Regel setzt der Compiler die Werte auch direkt in die Aufrufstelle ein und ein Zugriff auf die Konstantenwerte der Schnittstelle findet nicht mehr statt.

• static void deleteDirectoryContents(File directory)
  Delete all the files within a directory but not the directory itself. If the contents of this or any subdirectory can’t be listed an IOException("Error listing files for " + directory) will be thrown.
• static void deleteRecursively(File file) throws IOException
  Delete a file or directory and all contents recursively. This methods calls deleteDirectoryContents() first and then file.delete(). If this directory can’t be deleted an IOException("Failed to delete " + file) will be thrown.

Because a file can be a symbolic link it is important to understand the semantics of these methods. If a containing file or directory is a symbolic link will the symbolic link itself be deleted or will the method follow the link and delete the target? None of the methods follow symbolic links because it’s simply not possible with the JDK. If these methods find a symbolic link then just the link will be deleted. But what if the methods are called on a directory which is itself a symbolic link?

If deleteDirectoryContents() is called on a File object which is a symbolic link to a directory nothing will happen at all because as already mentioned symbolic links are not followed; so deleteDirectoryContents() will not delete the directory the method was called on. If on the other site deleteRecursively() is called on a symbolic link then just the symbolic link to this directory is deleted but not the target directory itself. That’s just how symbolic links works in Java and has nothing to do with the actual deleteXXX()-methods.

Alternative: Use NIO.2 from Java 7 or copy the old source code to your project.

• http://docs.guava-libraries.googlecode.com/git-history/v11.0/javadoc/com/google/common/hash/package-summary.html und
• http://docs.guava-libraries.googlecode.com/git-history/v11.0/javadoc/com/google/common/math/package-summary.html

Mit der neuen MathInt Klasse beschäftigt sich ausführlicher der Blogpost http://marxsoftware.blogspot.com/2011/12/guava-release-11s-intmath.html.