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.

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.

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.

http://www.heise.de/newsticker/meldung/Umfrage-Java-ist-verbreitetste-Programmiersprache-bei-IT-Dienstleistern-1198249.html. C# machst sich auch gut

Nach dem Eintrag im Blog (http://www.tutego.de/blog/javainsel/2011/02/forrester-untersuchung-sagt-java-taugt-nix-fr-enterprise/) über die Forrster Studie fragte ein Kommentator nach meiner Einschätzung. Also, taucht Java ab oder taugt es?

Es ist schwer einen Anfang zu finden, denn verschiedene Sachen laufen immer durcheinander. Zunächst ist Java eine Vereinigung:

Java = JVM + Java als Programmiersprache + Java SE Lib + Java EE Lib (wenn man Enterprise hinzunehmen möchte)

Man könnte noch “Great Communitiy” oder große Anzahl Open-Source Libs dazu nehmen, aber darauf kommt es jetzt nicht an.

An den Gliedern kann man anfangen unter verschiedenen Bewertungskriterien rumzunörgeln. Es steht außer Frage das die JVM unglaublich leistungsfähig ist. Bei der Programmiersprache Java fängt aber die Kritik schon an – bei der Java SE geht es weiter. Java EE kann man auch kritisieren, jedoch für einen anderen Grund.

• Die Sprache Java hat sich die letzten Jahre nicht gewandelt, aber Skriptsprachen zeigen zum Beispiel deutlich den Trend auf, Collection-Unterstützung in den Sprachkern aufzunehmen und Closures sowie funktionale Aspekte zu unterstützen desweiteren Nebenläufig besser anzugehen.
• Die Bibliotheken haben deutliches Potenzial. Einmal horizontal (unterschiedlichen Technologien) wie vertikal (in der Tiefe). Wenn Java SE schon fertig wäre, wäre Apache Commons * oder Google Collections/Guava gar nicht nötig. Wenn Java EE auch den Web-Technologie-Teil abdecken soll, OOOHA, da ist noch viel zu tun.

Der Autor der Studie ist nicht gegen Java: die Folien zeigen, das Java in vielen Bereichen perfekt passt. Er macht aber klar, dass Java eben nicht für jedes Problem die Antwort ist. Da hat der Mann natürlich Recht! Mit der Banane einen Nagel in die Wand zu schlagen wird auch kompliziert. Java ist explizit als General Purpose Sprache entworfen worden. Das heißt: Für alles und nichts! Während man außer Frage stellt, Java im Bereich Treiberprogrammierung einzusetzen, versuchen viele Java (also die Sprache + Java SE + Java EE) dort einzubringen, wo es bessere Lösungen gibt. Java ist im Gui-Bereich einfach schwach. Punkt. Gui ohne Databinding? Nicht gut. (Es geht immer noch darum, dass es kein Teil der Standard-Bibliotheken ist. Natürlich gibt es Databinding am Open-Source-Himmel … sogar gaaaanz viele Lösungen.) Es steht außer Frage, dass man mit Swing und JSF absolut geile Lösungen bauen kann. Doch Softwareentwicklung besteht nicht daraus, mit ein paar Experten ein System zu bauen; gibt Experten FORTRAN oder COBOL und auch dann wird das Design super sein.

Die zentralen Schwachpunkte im Gui-Bereich sind:

• Zu kompliziert mit den STANDARD-Frameworks für den Durchschnitts-Joe. In einer Tabelle eine Fließkommazahl mit zwei Nachkommastellen zu formatieren muss einfacher gehen als extra einen Cell-Renderer zu programmieren.
• Für echte Oberflächen muss man zukaufen, OS-Libs nehmen, oder stark in Eigenentwicklung investieren. Databinding gibt es, klar, aber eben nicht im Java SE. Man schaue nur auf Eclipse RCP und dann sieht man, was in Swing alles fehlt.
• Agil mal eben schnell eine Änderungen umzusetzen geht nicht.

WENN man also Gui-Entwicklung zur Enterprise-Entwicklung zählt – und das tut der Autor der Studie, das ist aber auch Diskussionssache – hat er mit seiner Kritik recht. Mich wundert, was es an dem Punkt zu diskutieren gibt. Die Diskussion gleitet schnell in die Richtung das man sagt: Ja, aber in Ruby, mit Eclipse RCP, mit Vaadin, mit bla, … geht das alles! Stimmt, es geht aber hier um pures Java und um das, was in Java SE/Java EE von Oracle kommt. Hier hat eben Java nichts zu bieten. Ich finde Swing toll und mag es, aber für heutige Richclient-Anwendungen ist das nichts. Auch JSF ist nichts für moderne RIA-Anwendungen. Viel zu HTML-lasting.

Java EE ist im Kern ausgereift und für Geschäftslogik und Persistierung nahezu perfekt. Container wie GlassFish machen es rund. Hier liegt nicht das Problem. Entwickler großer Anwendungen müssen lernen das richtige Tool für den Job zu finden. Im Enterprise Bereich ist Java EE 6 ein guter Anfang für das Backend. Den Gui-Bereich können wir aufgeben. Klar, das es mit Swing und JSF “irgendwie geht”, aber wie gesagt: es darf keine Technologie für Experten sein. Es wird natürlich immer Softwareentwickler geben die sich wünschen, das eine Technologie für Experten ist, aber es geht um Wirtschaftlichkeit, ob wir das wollen oder nicht. Und wenn eben ein Swing-Entwickler für einen neuen Button 20 Minuten im Quellcode braucht, der Silverlight-Entwickler aber nur 5 Minuten, ist klar, wie die Rechnung aussieht. Und selbst das ist noch viel zu low-level gedacht.

Selbst wenn man Java aufbohrt und pimpt bis zum Abwinken mit Business-Rules-Engine, alles in dynamischen Programmiersprachen auf der JVM entwickelt, usw. usw., es wird immer noch zu viel selbst gebaut. Entwickler müssen lernen, sich in komplexe existierende Systeme einzuarbeiten, und auf deren Basis eigene Lösungen entwickeln. Im Web-Bereich sei einmal der JBoss-Stack oder Alfresco in den Raum geworfen, aber auch richtig fette Sachen wie SAP, auch wenn vielen das nicht gefallen dürfte. Oder Talend zur Konvertierung. Der Autor der Studie lässt Alternativen vielleicht bewusst offen (RoR wird genannt im Web-Bereich) und ich vermute einfach deswegen weil es keine Alternativen gibt! Oracle bietet eine wunderbare Basis aber es liegt an uns, mächtigere Framworks, und dann auch DSL für spezifische Probleme zu nutzen. Java hat seinen Platz und ist eben nicht für alles zu gebrauchen. Ich erinnere mich gut an dBASE, das zeigt schon vor über 10 Jahren die Richtung auf: Eine Entwicklungsumgebung mit Programmiersprache. Das ist Rapid Application Development von datatenbankgetriebenen Anwendungen. Eigenentwicklung wird es immer geben, aber für gewisse Probleme funktionieren wunderbar 4GL-Lösungen.

http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/. Und ich habe schon gedacht es ist der 1. April …

Das musste ich gerade bei http://www.heise.de/newsticker/meldung/Ueber-zwei-Jahre-und-kein-Fix-fuer-Java-1185537.html lesen. Peinlich, denn Oracle ist strikter als Sun mit den Fixes. Vielleicht aber ein klares Signal, dass Java sowieso nur auf der Serverseite was zu suchen hat und so bekommt man es von der Clientseite weg 🙂