Guice 3 mit @PostConstruct = Mycila

~ Christian Ullenboom ~ 3 Kommentare

Von Spring habe ich mich schon länger verabschiedet und bin für meine clientseitigen Programme auf Guice gewechselt. Bis auf die Tatsache das es keinen automatischen Autoscan gibt, hat mir nichts wirklich gefehlt. Guice unterstützt auch standardmäßig nicht die Common Annotions, aber bei Guice 2 hatte ich http://code.google.com/p/guiceyfruit/ im Einsatz, da das jedoch auf intern Datenstrukturen von Guice 2 zurückgriff, konnte ich nicht auf die neue Version Guice 3 migrieren. Also schmiss ich GuiceFruit raus und suchte eine Alternative. Die gibt es mit dem Projekt http://code.google.com/p/mycila/:

http://code.mycila.com/wiki/MycilaGuice

Google Guice contributions:

  • ServiceLoader plugin (enables injection into loaded services)
  • JSR250 supports improved from GuicyFruit
  • Custom Injector with more useful methods which consider the whole Injector hierarchy
  • CachedScope to cache your binding for a specific duration

Neben Mycila Guice gibt es auch noch andere tolle Dinge:

  • Mycila Event
  • Mycila JMX

Insubstantial 6.2

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

Nach dem Kirill Grouchnikov in sein Substantial keine Zeit mehr investiert, gibt es vom Nachfolgeprojekt ein erstes ernsthaftes Update: http://shemnon.com/speling/2011/04/insubstantial-62-release.html. Unter anderen gehört Maven dazu, Änderungen laut Webseite:

  • Gradle – the codebase has been adjusted to use Gradle as the build system. This has allowed for seampless deployment into the maven repositories. For Trident, laf-plugin, and substance-swingx this represents the entirity of the changes
  • Maven Distribution – this deserves it’s own bullet point. The jars are available from day one in the maven repositories.
  • NPE Bugs – most of the code changes are to deal with possible null pointer exceptions. No one in their right mind would use a JTable as a table cell renderer, but it does happen in the wild.
  • Flamingo API addition – a patch from Jonathan Gileswas applied to allow commands to be removed from the ribbon.
  • Java 7 fixes – there is a bug fix in Java’s Color Choosers that broke substance 6.1. This is fixed in Substance 6.2, so it should run on Java 7 now!

Twitter steigt auf Java um

~ Christian Ullenboom ~ 1 Kommentar

Das führt zu einer deutlichen Performance-Verbesserung und Hardware kann wieder abgebaut werden. Weiterhin werden Entwickler langsame Programme schreiben können (was ebenfalls in allen anderen Programmiersprachen gelingt), aber zumindest zeigt Twitter (neben so hoch skalierten Systemen wie eBay oder Facebook), dass Java grundsätzlich eine exzellente Performance bietet. Ein paar Details unter http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html. Die Kernbausteine der Lösung (Blender genannt) sind Apache Thrift, Apache Lucene und JBoss Netty.

Google App Engine 1.4.3 veröffentlicht

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

Siehe http://googleappengine.blogspot.com/2011/03/announcing-app-engine-143-release_30.html. Änderungen in Java:

Java

  • Concurrent Requests: Until now, Java applications relied on starting additional instances to dynamically scale up for higher traffic levels. Now with support for concurrent requests, each application instance may serve multiple user requests at the same time. To start, ensure your application’s code is threadsafe, then enable concurrent requests by adding the <threadsafe> flag to your appengine-web.xml.
  • Java Remote API and Deferred API support: The Remote API andDeferred API libraries have been supported in Python for awhile, and now they can be used with Java, too! The Remote API allows you to perform operations on your application’s datastore from your local machine. This is particularly useful for work that is not well-suited to App Engine’s request/response model. The Deferred API allows users to more easily write and execute ad hoc tasks. Our docs contain more information and examples on how to use the Remote API and Deferred API in Java App Engine.
New and changed APIs
  • Files API: The new Files API in Python and Java allow you to pragmatically read and write data using Blobstore. This API can be used to generate reports, export data, or do anything that your heart desires that requires large, binary objects.

 

File-IO finde ich spannend, noch toller wäre es gewesen, wenn sich Google an NIO2 halten würde.

Die JavaMail API (Teil 2)

~ Christian Ullenboom ~ 1 Kommentar

Steht die Verbindung zum Server, kann der Client eine Mailbox öffnen. Wir deklarieren dazu eine openPop3InboxReadOnly() und closeInbox() Methode.

com/tutego/insel/mail/MailUtils.java, Teil 2

public static Folder openPop3InboxReadOnly( Session session )

throws MessagingException

{

Store store = session.getStore( "pop3" );

store.connect();

Folder folder = store.getFolder( "INBOX" );

folder.open( Folder.READ_ONLY );

return folder;

}

public static void closeInbox( Folder folder ) throws MessagingException

{

folder.close( false );

folder.getStore().close();

}

Die Rückgabe von openPop3InboxRealOnly() ist ein Folder-Objekt und mit diesem lassen sich letztendlich die E-Mails abrufen:

com/tutego/insel/mail/MailUtils.java, Teil 3

public static void printAllTextPlainMessages( Folder folder )

throws MessagingException, IOException

{

for ( Message m : folder.getMessages() )

{

System.out.println( "\nNachricht:" );

System.out.println( "Von: " + Arrays.toString(m.getFrom()) );

System.out.println( "Betreff: " + m.getSubject() );

System.out.println( "Gesendet am: " + m.getSentDate() );

System.out.println( "Content-Type: " +

new ContentType( m.getContentType() ) );

if ( m.isMimeType( "text/plain" ) )

System.out.println( m.getContent() );

}

}

Die Implementierung holt sich mit getContent() den kompletten Inhalt, aber natürlich lässt sich der auch über einen Eingabestrom holen.

Ein kleines Demo dazu, was erst Verbindung mit dem Google Mail Server herstellt, dann sich den INPUT-Ordner öffnet und alle E-Mails abläuft. Die Nachrichten werden nicht vom Server gelöscht.

com/tutego/insel/mail/PrintAllMailsWithMailUtils.java, main()

Session session = MailUtils.getGMailSession(

JOptionPane.showInputDialog( "user" ),

JOptionPane.showInputDialog( "pass" ) );

Folder inbox = MailUtils.openPop3InboxReadOnly( session );

MailUtils.printAllTextPlainMessages( inbox );

MailUtils.closeInbox( inbox );

Das Programm öffnet zwei Dialoge, einen für den Benutzernamen und einen für das Passwort, es ist jedem selbst überlassen, hier feste Strings einzukodieren.

Hinweis

Um herauszufinden, ob überhaupt Nachrichten auf dem Server vorliegen, können wir auf dem aktuellen folder-Objekt die Methode getMessageCount() nutzen.

Nachricht löschen

Um eine Nachricht vom Server zu löschen, darf der Ordner nicht mit READ_ONLY geöffnet werden, sondern mit Folder.READ_WRITE. Anschließend lässt sich einer Nachricht, repräsentiert durch ein Message-Objekt, mit setFlag() ein Lösch-Hinweis geben:

message.setFlag( Flags.Flag.DELETED, true );

Die Daten werden jedoch nur dann vom Server gelöscht, wenn zum Schluss folder.close(true) aufgerufen wird. Ohne den Aufruf von close() mit dem Argument true bleiben die Nachrichten erhalten.

Guice 3.0 ist raus

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

Nach laaaanger Wartezeit ist DI-Framework Guice 3.0 veröffentlicht worden. Von http://code.google.com/p/google-guice/wiki/Guice30 die Neuerungen:

  • JSR 330 support
  • New Persist extension
  • ToConstructor Bindings
  • Better OSGi support (and generally improved support for multiple classloaders)
  • New methods in Binder: requireExplicitBindings & disableCircularProxies
  • Much simpler stack traces when AOP is involved
  • Exact duplicate bindings are ignored (instead of an exception being thrown)
  • Repackaged cglib, asm & guava classes are now hidden from IDE auto-imports
  • Source can be built with Maven
  • General extension & SPI improvements:
  • Scope improvements:
    • Scopes.isSingleton
    • toInstance bindings are considered eager singletons in the Scope SPI
    • Singleton providers that return null are now scoped properly.
    • Fail when circularly dependent singletons cannot be proxied (previously two instances may have been created)
  • Provider Method (@Provides) improvements:
    • Logger dependencies now use named instead of anonymous loggers
    • Exceptions produce a simpler stack
  • Private Modules improvements:
    • If a single PrivateModule is passed to Modules.override, private elements can be overridden.
    • If many modules are passed to Modules.override, exposed keys can be overridden.
  • Multibinder & MapBinder extension improvements:
    • permitDuplicates — allows MapBinder to inject a Map<K, Set<V>> and a Map<K, Set<Provider<V>> and Multibinder to silently ignore duplicate entries
    • Expose dependencies in Stage.TOOL, and return a dependency on Injector (instead of null) when working with Elements.
    • Co-exist nicely with Modules.override
    • Work properly with marker (parameterless) annotations
    • Expose details through the new extensions SPI
  • Servlet extension improvements:
    • Added with(instance) for servlet bindings.
    • Support multiple injectors using ServletModule in the same JVM.
    • Support thread-continuations (allow background threads to process an HttpRequest)
    • Support manually seeding a @RequestScope
    • Expose details through new extensions SPI
    • Fix request forwarding
    • Performance improvements for the filter & servlet pipelines
    • Expose the servlet context (ServletModule.getServletContext)
    • Fixed so a single ServletModule instance can be used twice (in, say Element.getElements & creating an Injector)
    • Fix to work with context paths
  • AssistedInject extension improvements
    • New FactoryModuleBuilder for building assisted factories
    • Injection is done through child injectors and can participate in AOP
    • Performance improvements
    • Multiple different implementations can be created from a single factory
    • Incorrect implementations or factories are detected in Stage.TOOL, and more error-checking with better error messages
    • Work better with parameterized types
    • Expose details through new extensions SPI
  • ThrowingProviders extension improvements
    • Added a new CheckedProviders interface that allows more than one exception to be thrown.
    • Added @CheckedProvides allowing @Provides-like syntax for CheckedProviders.
    • Dependencies are checked at Injector-creation time and during Stage.TOOL, so they can fail early
    • Bindings created by ThrowingProviderBinder now return proper dependencies instead of Injector.
  • Struts2
    • The Struts2 extension now works again! (It worked in Guice 1.0 and was somewhat broken in Guice 2.0)
  • Added to Injector: getAllBindings, getExistingBinding, getScopeBindings, getTypeConverterBindings.
  • Added to Key: hasAttributes, ofType, withoutAttributes
  • Various bug fixes / improvements:
    • Prevent child injectors from rebinding a parent just-in-time binding.
    • Non-intercepted methods in a class with other intercepted methods no longer go through cglib (reducing total stack frames).
    • Allow Guice to work on generated classes.
    • Fix calling Provider.get() of an unrelated Provider in a scoping method.
    • MoreTypes.getRawTypes returns the proper types for arrays (instead of Object.class)
    • JIT bindings left in a parent injector when child injectors fail creating a JIT binding are now removed
    • Overriding an @Inject method (if the subclass also annotates the method with @Inject) no longer injects the method twice
    • You can now bind byte constants (using ConstantBindingBuilder.to(byte))
    • Better exceptions when trying to intercept final classes, using keys already bound in child or private module, and many other cases.
    • ConvertedConstantBinding now exposes the TypeConverterBinding used to convert the constant.

Inselupdate: Primitive Elemente in Datenstrukturen verwalten

~ Christian Ullenboom ~ Hinterlasse einen Kommentar

Jede Datenstruktur der Collection-API akzeptiert, auch wenn sie generisch verwendet wird, nur Objekte. Primitive Datentypen nehmen die Sammlungen nicht auf, was zur Konsequenz hat, dass Wrapper-Objekte nötig sind (über das Boxing fügt Java 5 scheinbar primitive Elemente ein, doch in Wahrheit sind es Wrapper-Objekte). Auch wenn es also heißt:

List<Double> list = new ArrayList<Double>();

list.add( 1.1 );

list.add( 2.2 );

sind es zwei neue Double-Objekte, die aufgebaut werden, und in die Liste wandern. Anders und klarer geschrieben, was wirklich passiert:

List<Double> list = new ArrayList<Double>();

list.add( Double.valueOf(1.1) );

list.add( new Double(2.2) );

Dem Double.valueOf() ist der new-Operator nicht abzulesen, doch die Methode ist implementiert als: Double valueOf(double d){ return new Double(d); }.

Spezialbibliotheken

Für performante Anwendungen und großer Menge von primtiven Elemente ist es sinnvoll, eine Klasse für den speziellen Datentyp einzusetzen. Anstatt so etwas selbst zu programmieren, kann der Entwickler auf drei Implementierungen zurückgreifen:

  • fastutil (http://fastutil.dsi.unimi.it/). Erweiterung um Datenstrukturen für (sehr viele) primitive Elemente und hochperformante Ein-/Ausgabe-Klassen.
  • GNU Trove (http://trove.starlight-systems.com/). Stabil und Entwicklung ist aktiv. Neue Datenstrukturen aus Java 5 oder 6 wie Queues zählen jedoch nicht dazu.
  • Apache Commons Primitives (http://jakarta.apache.org/commons/primitives/). Stabil in der Version 1.0, aber seit Ende 2003 nicht mehr aktualisiert.

    • JSR 334 (Project Coin) ist im Public Review

    ~ Christian Ullenboom ~ Hinterlasse einen Kommentar

    Details unter http://blogs.sun.com/darcy/entry/project_coin_jsr_334_pr (Download des Drafts unter http://jcp.org/aboutJava/communityprocess/pr/jsr334/index.html).

    Allerdings gibt es Unmut, weil zwar alle so schön “Oracle-open” sein soll, aber nichts dokumentiert ist. Daher ist völlig offen, ob seit dem letzten Pre-Release Vorschläge von der Community angenommen wurden, und wenn ja, welche, und wenn nein, warum nicht.

    Inselupdate: Blockierende Warteschlangen

    ~ Christian Ullenboom ~ Hinterlasse einen Kommentar

    Die Schnittstelle BlockingQueue steht für besondere Queues, die blockieren können. Das kann aus zwei Gründen geschehen: entweder sind keine Daten zu entnehmen da die Queue leer ist, oder eine maximale Anzahl von zu haltenden Elementen ist erreicht. Besonders in Produzenten/Konsumenten-Szenarien sind blockierende Warteschlangen sehr nützlich.

    Eine performante thread-sichere Implementierung ist in der Praxis sehr wichtig und die Java SE Bibliothek hat zwei besondere Realisierungen auf Lager:

    • ArrayBlockingQueue: Queue immer mit einer maximalen Kapazität, realisiert intern mit einem Feld
    • LinkedBlockingQueue: Queue unbeschränkt oder mit maximaler Kapazität, intern realisiert durch eine verkettete Liste
    • PriorityBlockingQueue: Eine blockierende PriorityQueue

    Die anderen Realisierungen wie DelayQueue sind für uns jetzt nicht relevant.

    Das schöne an blockierenden Warteschlangen ist ihr Verhalten in Produzenten/Konsumenten-Verhältnissen; ein Thread (oder beliebig viele Threads) setzt (viele setzen) Daten in die Queue, ein Thread (oder beliebig viele Threads) holt (viele Threads holen) die Daten wieder raus. Bei einer Queue ist es ja so, dass sie nach dem FIFO-Verfahren arbeitet, das heißt, die Daten, die zuerst reingelegt wurden, werden auch zuerst verarbeitet. Bei einer Prioritätswarteschlage ist das etwas anders, aber dazu gleich mehr.