Google Guava: EvictingQueue in Version 15

Google Guava hat Folgendes ursprünglich geteilt:

EvictingQueue: a non-blocking, bounded queue
In Guava 15, we are introducing EvictingQueue [1], which is a non-blocking, bounded queue that automatically evicts (removes) elements from the head of the queue when attempting to add elements to a full queue. This is different from conventional bounded queues, which either block or reject new elements when full.
Java provides several Queue implementations, depending on what features you need. For example:
Unbounded, non-blocking: ArrayDeque, LinkedList, PriorityQueue
Unbounded, blocking: LinkedBlockingDeque, LinkedBlockingQueue, SynchronousQueue
Bounded, blocking: ArrayBlockingQueue, LinkedBlockingDeque, LinkedBlockingQueue
However, a bounded, non-blocking implementation is noticeably missing from the JDK. Like many of the JDK implementations, EvictingQueue is not thread-safe and does not permit null elements. If you need thread safety, you must wrap it in a synchronized wrapper (Queues#synchronizedQueue). If you need null elements, please give this wiki page [2] a read.
An EvictingQueue can be used to keep track of recent items in a bounded buffer, or even as a simple FIFO cache. Hopefully you’ll find it useful!
Cheers,
-+Kurt Alfred Kluever, Guavian
[1] http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/EvictingQueue.html
[2] https://code.google.com/p/guava-libraries/wiki/LivingWithNullHostileCollections

Neues Release von JFreeChart 1.0.15

http://www.jroller.com/dgilbert/entry/jfreechart_1_0_151. Zu den Updates:

This release contains support for non-visible series in XYBarRenderer, minor gridlines in PolarPlot, new legend item ordering options, chart editor enhancements, updates to StandardDialScale, localisation files for Japanese, refactored parameter checks and a fix for a minor security flaw in the DisplayChart class, detected and reported by OSI Security: http://www.osisecurity.com.au/advisories/jfreechart-path-disclosure.

 

Transformation von Java nach C# (Java2Cs Translator)

ILOG ist ein Teil von IBM und hat für ein Projekt einen Übersetzer von Java nach C# entwickelt und bei SourceForge gehostet. Eingebunden ist es über Eclipse und dann macht man einfach nur ein File > Export > Other > ILOG Java to CSharp Translator. Es unterstützt alle Java 5 Features wie Generics, Enums, foreach, aber nicht Java 7. Ein paar Dinge können natürlich nicht übertragen werden und auch natürlich wird nicht alles von den Java-Bibliotheken übertragen. Seit einiger Zeit gab es kein Update mehr beim Projekt.

JOpenDocument API

Zum Zugriff auf Dokumente und Spreadsheets von OpenOffice (for OASIS Open Document ) ist JOpenDocument (http://www.jopendocument.org/) eine GPL-Bibliothek, die das mit einer einfachen API unterstützt.

Etwa das Laden und Verändern von Spreadsheets:

File file = new File( "c:/in.ods" );
SpreadSheet createFromFile = SpreadSheet.createFromFile( file );
Sheet sheet = createFromFile.getSheet( 0 );
sheet.setValueAt( "Filling test", 1, 1 );
sheet.getCellAt( "A1" ).setValue( "On site support" );
sheet.getCellAt( "I10" ).setValue( new Date() );
sheet.getCellAt( "F24" ).setValue( 3 );
File outputFile = new File( "c:/out.ods" );
sheet.getSpreadSheet().saveAs( outputFile );

Weitere Beispiele gibt http://www.jopendocument.org/documentation.html.

Interessant ein ein purer Java-Viewer, und damit die Möglichkeit in PDF zu exportieren, ohne dass man OO dazu fernsteuern muss.

Beim Testen der SpreadSheet-API sind mir leider einige Nachteile aufgefallen:

  • Es gibt keine Named References
  • Die API ist sehr Datei-orientiert. Nur im Speicher Dokumente anzulesen und zu verarbeiten ist nicht möglich. Ich sehe erst einmal keine Methode, wie ein Servlet z.B. sich den InputStream auf ein OO-Dokuments holen und als OutputStream an den Client verschicken kann, ohne dass man vorher das OO-Dokument in eine Datei schreibt.
  • Soll der eingebauter Viewer verwendet werden, können TIFF-Bilder nicht angezeigt werden.
  • GPL könnte für einige Bereiche ein Problem sein. Es werden aber kommerzielle Lizenzen verkauft.
  • Nur das Anzeigen von einfachen Dokumenten ist möglich.

Bean-Bean Mapping mit Dozer

Dozer ist eine kleine Open-Source Bibliothek (Apache-Lizenz) zum Mappen von JavaBeans auf JavaBeans. Motivationen gibt es genug — die Webseite zählt gleich einige Argumente auf:

  • A mapping framework is useful in a layered architecture where you are creating layers of abstraction by encapsulating changes to particular data objects vs. propagating these objects to other layers (i.e. external service data objects, domain objects, data transfer objects, internal service data objects). A mapping framework is ideal for using within Assembler type classes that are responsible for mapping from one data object to another.
  • For SOA/ESB systems, a side effect is the passing of domain objects between different systems. Typically, you won’t want internal domain objects exposed externally and won’t allow for external domain objects to bleed into your system.
  • Mapping between data objects has been traditionally addressed by hand coding value object assemblers (or converters) that copy data between the objects. Most programmers will develop some sort of custom mapping framework and spend countless hours and thousands of lines of code mapping to and from their many transfer objects.
  • A generic mapping framework solves these problems. Dozer is an open source mapping framework that is robust, generic, flexible, reusable, and configurable.
  • Data object mapping is an important part of layered service oriented architectures. Pick and choose the layers you use mapping carefully. Do not go overboard as there is maintenance and performance costs associated with mapping data objects between layers.

Basis des Mappings sind XML-Dokumente; im einfachsten Fall:

<?xml version="1.0" encoding="UTF-8"?>
<mappings xmlns="http://dozer.sourceforge.net" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://dozer.sourceforge.net http://dozer.sourceforge.net/schema/beanmapping.xsd">
  <mapping>
<class-a>d.e.i.n.p.a.k.e.t.TestObject</class-a>
<class-b>d.e.i.n.p.a.k.e.t.TestObjectPrime</class-b>
<field> <A>yourSourceFieldName</A> <B>yourDestinationFieldName</B> </field>
</mapping>
</mappings>

Angestoßen wird er über ein Mapping-Objekt, welches auch leicht von Spring injiziert werden kann:

Mapper mapper = new DozerBeanMapper();

DestinationObject destObject = mapper.map(sourceObject, DestinationObject.class);

oder

DestinationObject destObject = new DestinationObject();
mapper.map(sourceObject, destObject);

Interessant finde ich die JMX-Integration. Der Mapper gibt Statistik-Informationen etwa über die Anzahl gemappter Objekte.

PDFs in/mit/aus Java erstellen, ein leidiges Thema

  • Selbst die PDF erstellen, mit allen Linien, Grafiken, Texten. Das geht etwa mit iText. Nachteil: Sehr aufwändig, insbesondere wenn der Kunde einmal sagt: Die Box bitte noch ein wenig nach links oben.
  • Mit Report-Programmen wie BIRT oder Japser arbeiten, die dann über iText die PDF rausspucken. Vorteil: Netter Report-Designer. Nachteil: Die Designer sind im Sekretariat, die nur Word oder vielleicht OO (OpenOffice, Libre Office) kennen, ungewohnt.
  • PDF mit XForms erstellen. Siehe OpenOffice Draw + XForms Export + iText = PDF. Das mache ich bei unseren Rechnungen so. Läuft gut. Die Vorlagen erstelle ich mit OO. Weiterer Vorteil: Sekretariat kann selbst das aussehen verändern.
  • Word/Excel/OO/RTF-Templates nutzen, dann in PDF konvertieren. Zum Füllen der Vorlagen gibt es einige (auch open-source) Lösungen, siehe Apache POI, JExelApi, xdocreport, jRTF. Doch dann kommt das Problem: Das in PDF zu konvertieren. Mann kann nun die eigentlichen Programme nutzen und einen PDF-Export mit einem Druckertreiber verwenden, oder das automatisieren. Entweder über Java oder nicht-Java-Programme (etwa der Shell). Im Java-open-source Bereich gibt es hier nach meinem Kenntnisstand nichts wirklich Funktionierendes. Mit OO kann man die UNO-Brücke nutzen, das kappt mit ODT usw. sehr gut, aber man braucht eine Installation und das ist relativ langsam für Massenexports. jOpenDocument Homepage. Open Document library macht das in purem Java, ist aber noch nicht so weit. xdocreport sollte das für Word können, das Resultat ist bei meiner Vorlage aber unbrauchbar. xdocreport kann auch mit FOP -> iText -> PDD arbeiten, das habe ich noch nicht getestet.

Was ist aus Apache Click geworden?

Anfang 2009 schrieb ich im Blog:

Darauf hat die Welt gewartet: Wieder ein neues/altes Web-Framework

Apache Click http://incubator.apache.org/click/ heißt es und läuft ab Java 1.4. Super. Kommt damit 5 Jahre zu spät. Also nix mit Annotationen. Schön XML und so. (Click 0.3 gab es auch schon im März 2005, also ist das Projekt nicht wirklich jung.) Das Wort Ajax taucht auf den ganzen Webseiten nicht auf. Immerhin gibt es eine http://incubator.apache.org/click/docs/click-ide.html auf Eclipse 3.4 Basis. Toll die Antwort auf die Frage "Why develop a new Web Application Framework?" Antwort: "Because the existing frameworks did not meet my needs. Struts doesn’t really do much, while Tapestry is too complicated. For a more comprehensive answer please see Why Click." Klar, als ob es nur Struts und Tapestry gibt. Vor 10 Jahren vielleicht. Bei Struts 1.x ist die Zeit schon lange abgelaufen und bei Tapestry 5 hält man sich noch ein wenig mit DI/IoC über Wasser.

Heute, im Jahr 2012, hat es Click zu einem vollständigen Web-Framework geschafft, die Demos (http://click.avoka.com/click-examples/home.htm) sehen von der Funktionalität OK aus, nur etwas altbacken, etwa so wie Windows 3.1 im Vergleich zu Windows 7.

Das letzte Update von Click ist von März 2011, also 1 1/2 Jahr alt. Das war’s dann wohl.

Welche Jars braucht man mindestens für ein JPA-Hibernate-Beispiel?

  • javax.persistence-2.0.0.jar
  • hibernate-commons-annotations-4.0.1.Final.jar
  • hibernate-core-4.1.4.Final.jar
  • hibernate-entitymanager-4.1.4.Final.jar
  • hibernate-validator-4.3.0.Final.jar
  • javassist-3.7.ga.jar
  • jboss-logging-3.1.1.GA.jar
  • jta-1.1.jar
  • antlr-2.7.5H3.jar
  • dom4j-1.6.1.jar

Zu beziehen in einem Maven-Repository des Vertrauens oder gleich über Maven auflösen lassen.