http://download.java.net/jdk8/docs/api/java/util/concurrent/locks/StampedLock.html

Neue Klasse in Java 8. Implementiert jedoch nicht Lock, wie es ReentrantLock tut. Aus der API:

A capability-based lock with three modes for controlling read/write access. The state of a StampedLock consists of a version and mode. Lock acquisition methods return a stamp that represents and controls access with respect to a lock state; "try" versions of these methods may instead return the special value zero to represent failure to acquire access. Lock release and conversion methods require stamps as arguments, and fail if they do not match the state of the lock. The three modes are:

  • Writing. Method writeLock() possibly blocks waiting for exclusive access, returning a stamp that can be used in method unlockWrite(long) to release the lock. Untimed and timed versions of tryWriteLock are also provided. When the lock is held in write mode, no read locks may be obtained, and all optimistic read validations will fail.
  • Reading. Method readLock() possibly blocks waiting for non-exclusive access, returning a stamp that can be used in method unlockRead(long) to release the lock. Untimed and timed versions of tryReadLock are also provided.
  • Optimistic Reading. Method tryOptimisticRead() returns a non-zero stamp only if the lock is not currently held in write mode. Method validate(long) returns true if the lock has not been acquired in write mode since obtaining a given stamp. This mode can be thought of as an extremely weak version of a read-lock, that can be broken by a writer at any time. The use of optimistic mode for short read-only code segments often reduces contention and improves throughput. However, its use is inherently fragile. Optimistic read sections should only read fields and hold them in local variables for later use after validation. Fields read while in optimistic mode may be wildly inconsistent, so usage applies only when you are familiar enough with data representations to check consistency and/or repeatedly invoke method validate(). For example, such steps are typically required when first reading an object or array reference, and then accessing one of its fields, elements or methods.

This class also supports methods that conditionally provide conversions across the three modes. For example, method tryConvertToWriteLock(long) attempts to "upgrade" a mode, returning a valid write stamp if (1) already in writing mode (2) in reading mode and there are no other readers or (3) in optimistic mode and the lock is available. The forms of these methods are designed to help reduce some of the code bloat that otherwise occurs in retry-based designs.

StampedLocks are designed for use as internal utilities in the development of thread-safe components. Their use relies on knowledge of the internal properties of the data, objects, and methods they are protecting. They are not reentrant, so locked bodies should not call other unknown methods that may try to re-acquire locks (although you may pass a stamp to other methods that can use or convert it). The use of read lock modes relies on the associated code sections being side-effect-free. Unvalidated optimistic read sections cannot call methods that are not known to tolerate potential inconsistencies. Stamps use finite representations, and are not cryptographically secure (i.e., a valid stamp may be guessable). Stamp values may recycle after (no sooner than) one year of continuous operation. A stamp held without use or validation for longer than this period may fail to validate correctly. StampedLocks are serializable, but always deserialize into initial unlocked state, so they are not useful for remote locking.

The scheduling policy of StampedLock does not consistently prefer readers over writers or vice versa. All "try" methods are best-effort and do not necessarily conform to any scheduling or fairness policy. A zero return from any "try" method for acquiring or converting locks does not carry any information about the state of the lock; a subsequent invocation may succeed.

Because it supports coordinated usage across multiple lock modes, this class does not directly implement the Lock or ReadWriteLock interfaces. However, a StampedLock may be viewedasReadLock(), asWriteLock(), or asReadWriteLock() in applications requiring only the associated set of functionality.

java-forum.org ist wieder online

Das kam heute per E-Mail rein:

[…] das Java-Forum.org ist wieder online. Aufgrund einer heftigen DDoS-Attacke war das Forum für mehrere Tage offline. Der Angriff war so intensiv, dass die Netzwerkinfrastruktur von Profihost (alter Server von Vladimir) hierdurch massiv beeinträchtigt wurde. Aus diesem Grund wollte der Hoster Profihost die Seite nicht mehr online stellen. Entsprechende Daten auf der Festplatte von Profihost wurden leider auch nicht mehr gefunden. Alle Bemühungen schlugen fehl und uns waren leider die Hände gebunden.
Die zweite schlechte Nachricht ist, dass die Datenbank während der DDoS-Attacke gehackt wurde. Dabei wurde die Tabelle mit den Beiträgen des Forums geleert. Die Leute des Managed Servers von Vladimir haben leider keine tägliche Backups erstellt und Vladimir hatte selber nur ein Backup vom 11. Februar 2013, heißt also: Uns fehlen ca. 6000 erstellte Themen inklusive Beiträge die von Februar bis jetzt geschrieben wurden. 🙁
Mittlerweile befindet sich die Seite auf unserem Server. Absofort werden täglich jede Nacht automatisch Backups erstellt und extern gespeichert. Außerdem ist der neue Server um einiges leistungsfähiger als der alte und kann auch größere DDoS-Attacken standhalten.
Bei Störungen am Server wird umgehend ein Servicetechniker per SMS informiert.
Ich bitte die lange Ausfallzeit zu entschuldigen.

Ob man das Forum nutzen und erweitern möchte muss jeder für sich selbst entscheiden, eine Empfehlung ist stattdessen das http://forum.byte-welt.net/forums/6-Java-Forum.

An Oliver, Andreas und Torsten (c’t und Closures)

Die c’t, an sich ein starkes Magazin, kommt dieses Mal mit einem peinlichen Artikel über Closures (Lambda-Ausdrücke) in Java 8 daher: Closures in aktuellen Programmiersprachen – c’t-Archiv, 17-2013, Seite 168, c’t – Inhalt 17-2013 – Seite 168. Obwohl die Syntax sehr lange bekannt und festgeklopft ist, basiert der Artikel auf Aufsätzen und Publikationen, die vor Jahren veröffentlicht wurden, namentlich auf http://www.javac.info/closures-v05.html. Der Aufsatz stammt von 2007, ist also fast sieben Jahre alt. Wenn der c’t-Artikel 2007 erschienen wäre, super! Jetzt nur peinlich. Schon September 2011, immerhin fast 2 Jahre her, machte Brian Goetz die C#-Syntax bekannt, was ein Wechsel der Symbole (jetzt -> statt vor Jahren =>) bedeutete. Auch Implementierungsdetails sind völlig anders und inkorrekt sagt der Beitrag:

Intern erzeugt der Compiler draus eine Interface und eine anonyme Klasse mit einer einzigen Funktion […]

Nein, das macht der Compiler natürlich nicht. Erst einmal gibt es in Java keine “Funktionen”, sondern nur Methoden, und dann nutzt der Compiler das in Java 7 eingeführte Invoke-Dynamic.

Der nächste Fehler im Artikel betrifft try-mit- Ressourcen, was in Java 7 schon längst implementiert wurde.