Autor: Christian Ullenboom

Verwandtschaft von Methode und Konstruktor

~ Christian Ullenboom ~ 1 Kommentar

Methoden und Konstruktoren besitzen beide Programmcode, haben eine Parameterliste, Modifizierer, können auf Objektvariablen zugreifen und this verwenden – das sind ihre Gemeinsamkeiten. Ein schon erwähnter Unterschied ist, dass Methoden einen Rückgabetyp besitzen (auch wenn er nur void ist), Konstruktoren aber nicht. Zwei weitere Unterschiede betreffen die Syntax und Semantik.

Konstruktoren tragen immer den Namen ihrer Klasse, und da Klassennamen per Konvention großgeschrieben werden, sind auch Konstruktoren immer großgeschrieben – Methoden werden in der Regel immer kleingeschrieben. Und Methoden sind in der Regel Verben, die das Objekt anweisen etwas zu tun, Klassennamen sind Nomen und keine Verben.

Der Programmcode eines Konstruktors wird automatisch nach dem Erzeugen eines Objekts von der JVM genau einmal aufgerufen, und zwar als erstes vor allen anderen Methoden. Methoden lassen sich beliebig oft aufrufen und unterliegen der Kontrolle des Benutzers. Konstruktoren lassen sich später nicht noch einmal auf einem schon existierenden Objekt erneut aufrufen und so ein Objekt reinitialisieren. Der Konstruktor-Aufruf ist implizit und automatisch mit new verbunden und kann nicht getrennt vom new gesehen werden.

Zusammenfassend können wir sagen, dass ein Konstruktor eine Art spezielle Methode zur Initialisierung eines Objektes ist.

JVM-Interna: „Ein Java-Compiler setzt Konstruktoren als void-Methoden um, die „<init>“ heißen“.

Apache Commons Logging Version 1.2

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

Kaum zu glauben, aber von Apache Commons Logging gibt es noch einmal ein Update. Version 1.2 bietet als “maintenance release containing bug fixes” nichts neues, fixed aber laut https://www.apache.org/dist/commons/logging/RELEASE-NOTES.txt:

o LOGGING-37:   Improve performance of LogFactory#getFactory() by calling
                Thread#currentThread()#getContextClassLoader() directly instead
                of using reflection. As a consequence support for JDK 1.1 has
                been dropped. Thanks to Matthias Ernst, Archie Cobbs.
o LOGGING-156:  Fix SecurityAllowedTestCase when executed with OpenJDK 1.7 due
                to an additional required RuntimePermission. Thanks to Mikolaj Izdebski.
o LOGGING-157:  Fix javadoc to comply with javadoc tool from jdk 1.8. Thanks to Ville Skyttä.

Gradle 2.0 freigegeben

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

Das auf Groovy basierende Build-Tool Gradle erklimmt eine neue Version: Gradle 2.0.  http://www.gradle.org/docs/current/release-notes zählen auf:

Gradle 2.0 is an important milestone in the evolution of Gradle. As explained in the Gradle 2.0 announcement, the change in major version number signals a new backwards compatibility baseline. Many deprecated features and API have been removed in this release, allowing the development team to simplify the codebase and implement new functionality. The “Potential Breaking Changes” section of these release notes list all of the breaking changes that have been made and all Gradle users are strongly encouraged to read the list.

FindBugs 3.0

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

Ein neues großes Release mit Java 8 Unterstützung, siehe Ankündigung unter https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2014-July/004029.html.

The primary changes are:
FindBugs supports Java 8 now (both as runtime and target platform). We don't recognize all of the new Java 8 features, or detect many Java 8 specific bug patterns, but we can analyze Java 8 code without getting runtime exceptions.
FindBugs requires minimum Java 7 as runtime environment!
FindBugs uses ASM 5 now which means that some 3rd party detectors based on FindBugs 2.x/ASM 3 has to be upgraded. See details in ASM documentation.

For people who need to run FindBugs using a Java 5 or 6 runtime, you should stick with the FindBugs 2.0 branch.

Weiter unter http://findbugs.sourceforge.net/.

asciidoctorj: asciidoc mit Java transformieren

~ Christian Ullenboom ~ 2 Kommentare

http://asciidoctor.org/ ist laut Webseite “an open source Ruby processor for converting AsciiDoc markup into HTML 5, DocBook 4.5 and other formats”. Die Software ist in Ruby implementiert und so plattformunabhängig programmiert, dass auch eine Ausführung mit JRuby möglich ist. https://github.com/asciidoctor/asciidoctorj kapselt das in einem netten Projekt, sodass eine Konvertierung direkt mit einer Java-API möglich ist:

import static org.asciidoctor.Asciidoctor.Factory.create;
import org.asciidoctor.Asciidoctor;
...
Asciidoctor asciidoctor = create();

...
String rendered = asciidoctor.render("*This* is it.", Collections.EMPTY_MAP);
System.out.println(rendered);
...
String rendered = asciidoctor.renderFile(new File("target/test-classes/rendersample.asciidoc"), Collections.EMPTY_MAP);
System.out.println(rendered);
...

Mit Optionen:

Map<String, Object> attributes = new HashMap<>();
attributes.put("backend", "docbook");

Map<String, Object> options = new HashMap<>();
options.put("in_place", true);
options.put("attributes", attributes);

String render = asciidoctor.renderFile("target/test-classes/rendersample.asciidoc", options);