J and I and Me
2006-09-30
  Spring 2.0 Countdown....
Der Spring 2.0 Countdown läuft hier. Dienstag ist es dann soweit. Wer die Neuigkeiten in 2.0 noch nicht kennt, findet die Liste hier.
  11:14 0 comments
Bookmark and Share
2006-09-28
  JAOO
Nächste Woche bin ich auf der JAOO in Dänemark. Eine nette Konferenz mit einer Menge sehr interessanter Vorträge. Wir sind folgendermaßen vertreten:



Ich bin gespannt, was sonst noch an interessanten Vorträgen kommt - stay tuned!
  13:36 0 comments
Bookmark and Share
2006-09-24
  Die 90er sind vorbei
Wie hier lesen kann, hat SGI" IRIX auf MIPS abgekündigt. Damit enden endgültig die 90er: Damals waren die Maschinen ein Traum und haben uns Dinge wie Jurassic Park oder Terminator 2 beschert. Video on Demand gab es prototypisch auf großen Challenge Servern, mittlerweile funktioniert es tatsächlich da draußen im Internet. Einige Zeit sah es so aus, als würde SGI die Welt übernehmen: Man kauft Cray, MIPS und Alias, es gab die MIPS-basierte Plattform ACE für Windows NT. Tja, und nun baut man auf Linux und Itanium - so ändert sich die Welt.

Moral: Auch wenn man einen technologischen Vorteil hat, muss man daran arbeiten, dass man ihn erhält. Sonst werden irgendwann Supercomputer zu Kühlschränken.
  13:34 0 comments
Bookmark and Share
2006-09-22
  Donnerstag Lehmanns Hamburg
Und am Donnerstag gebe ich dann einen Vortrag über Spring und AspectJ bei Lehmanns:

Donnerstag, 28. September 2006, um 20 Uhr
Lehmanns Fachbuchhandlung / Kurze Muehren 6 / Naehe Hauptbahnhof

Eine Anmeldung ist nicht notwendig, aber hilfreich fuer die Planung.

Infos finden sich unter http://www.lob.de/hamburg.
  09:42 0 comments
Bookmark and Share
  Java Starter Days Montag
Am Montag bin ich in Frankfurt bei den Java Starter Days. Details meiner Session finden sich hier.
  09:40 0 comments
Bookmark and Share
2006-09-21
  Die Zukunft des WWW?
  16:26 0 comments
Bookmark and Share
  Strategy Pattern Revisited
Das Strategy-Pattern aus dem ursprünglichen GoF-Buch ist eigentlich nahezu trivial: Kapsel einen Alogorithmus in einer eigenen Klasse. Wenn man "Klasse" durch "Modul" ersetzt, ist man wieder bei der alten Modularisierung. Das an Strategy ist, dass man Modul bzw. Klasse leicht austauschen kann und so die Implementierungen leichter ändern kann.

Meiner Ansicht nach ist daher eine Dependency Lösung wie Spring der nächste Schritt: Dabei kann man das konkret zu nutzende Modul extern konnfigurieren. Mein Eindruck ist, dass dadurch Strategy nochmal aufgewertet wird und in Spring-Systemen auch recht häufig zu sehen ist.
  16:10 0 comments
Bookmark and Share
2006-09-18
  Java "Bloat"
Eine weitere interessante Geschicht für Java ist, dass Java SE 6 einige Features nicht mehr haben soll, wie hier nachzulesen. Allerdings geht es dabei um ganze Pakete, deprecated Methoden wird es wohl noch bis an's Ende der Tage im JDK geben. Ich bin nicht sicher, ob das eine gute Idee ist. Vorteil ist aus meiner Sicht vor allem, dass es einfacher wird ein JDK zu implementieren. Die paar MB, die das JDK durch solche Features größer wird, kann ich mir nicht wirklich als Problem vorstellen. Und bisher gibt es als Kandidaten auch nur das Midi-Kit (das nun tatsächlich nicht so wichtig ist). Interessant ist, dass man auch CORBA rausnehmen wollte, was nun wirklich nicht die beste Idee ist, weil immer noch viele darauf aufbauen.

Das wirkliche Problem ist allerdings, das die Bibliotheken umfangreicher werden und damit auch schwerer verständlich. Nur gerade dieses Problem löst man so nicht, da eben die Größe der Bibliotheken im wesentlichen gleich bleibt und Midi wahrscheinlich nicht die beste Sache ist. Deprecated-Methoden herauszuwerfen ist meiner Ansicht nach auch keine Lösung (und wird eben auch nicht passieren), weil das unnötig bestehenden Code bricht.

Aus meiner Sicht gibt es die Chance, eine Abstraktion über Java zu bauen. Spring geht hier schon recht weit, weil es Bibliotheken als Abstraktionsschichten enthält. Ein anderer interessanter Gedanke ist, auch andere Sprachen, die auf der JVM laufen, als eine solche Abstraktion zu sehen: Sie bieten auch einen anderen Zugriff auf die Java-Features und -Bibliotheken. Vor allem sind diese Ansätze sinnvoll, weil Java eben durch die vielen Bibliotheken auch viele Möglichkeiten bietet - eine EInschränkung der Bibliotheken erscheint da kaum sinnvoll.
  10:52 2 comments
Bookmark and Share
2006-09-09
  Closures für Java
Eine der Neuerungen, die sich in Java SE 7 ankündigen, sind Closures (siehe auch hier. Dabei geht es im wesentlichen darum, eine Erweiterung zu schaffen, mit der man Funktionen als Variablenwerte verwenden kann. Man kann also einer Variablen eine Funktion zuweisen oder ad hoc eine erstellen. Dies hat weitreichende Konsequenzen. In Java SE betrifft dies zum Beispiel die Collections: Man muss nicht mehr "per Hand" über eine Collection iterieren, sondern kann einfach die Funktion übergeben, die für jedes Element ausgeführt werden soll.

Bei Spring könnte man den Template-Ansatz vereinfachen. Bisher sieht die Verwendung des JmsTemplates zum Beispiel so aus:


jmsTemplate.send(new MessageCreator() {
public Message createMessage(Session session)
throws JMSException {
return session.
createTextMessage("Text Message");
}
});


(Es gibt in diesem Fall natürlich noch die Vereinfachung jmsTemplate.convertAndSend("A Text Message"); . Aber davon wollen wir mal absehen. Mit Closures könnte man das ganze nun so schreiben:


jmsTemplate.send( (Session session) {
session.createTextMessage("Text Message");
}
);


In diesem Fall nutzt man nicht die Möglichkeit, eine Funktion einer Variablen zuzuweisen, sondern sie direkt einer Methode zu übergeben. Dies weißt auch auf das Problem bei der Sache hin: Im Prinzip ist das ganze eine Möglichkeit, etwas ähnliches zu tun, wie man es mit Inner Classes und Anonymous Inner Classes macht. Damit befindet man sich in der Zwickmühle: Inner Classes sind aufwändiger und vielleicht auch schwerer zu verstehen als Closures. So gibt es Entwickler, die das Schreiben eines ActionListeners für einen JButton berechtigterweise als kompliziert empfinden. Aber man wird dieses Verfahren aus der Java Sprache nicht eliminieren können, weil man sonst vorhandene Software bricht und zwar viele vorhandene Software.

Somit schafft man einen zweiten Weg für dasselbe, was ich für ungeschickt halte, aber wohl nicht zu ändern ist und dem Fortschritt nicht im Wege stehen sollte...
  09:19 1 comments
Bookmark and Share
2006-09-08
  Sun "kauf" JRuby
Wie man hier lesen kann, stellt Sun gerade zwei Committer von JRuby ein. Eine FAQ dazu gibt es auch. Meiner Ansicht nach ein sehr guter Schritt: Ich bin ja schon länger der Meinung, dass sich Java vor allem auf seine Stärke, nämlich die JVM und die gute Infrastruktur wie Application Server besinnen sollte. Durch diesen Schritt wird jetzt eine der wichtigsten dynamischen Sprachen direkt bei Sun auf der JVM implementiert. Das wird sicher viele weitere interessante Chancen schaffen. Interface21 selber hat in Spring 2.0 ja auch Support für dynamische Sprachen, so dass wir auch in diesem Bereich schon aktiv sind.
  11:47 0 comments
Bookmark and Share
2006-09-01
  Java wird Open Source....
Wie bekannt, soll Java Open Source werden. Als Java Champion nehme ich natürlich an der Diskussion zu diesem Thema teil. Daher hier meine Meinung:

Die erste Frage ist natürlich, was sich durch Open Source überhaupt ändert, immerhin stehen die Sourcen ja zu einem großen Teil schon hier oder hier zum Download bereit. Dennoch ändert sich der juristische Status, was bedeutet, dass Java jetzt auch in Bereiche vorstoßen kann, die nie zuvor ein JDK betreten hat, also zum Beispiel einige Linux Distributionen oder auch Organisationen, die nur Open Source nutzen wollen. Gerade dies wird in Zukunft wichtiger werden, da zum Beispiel einige Länder signalisiert haben, dass sie in Zukunft nur Open Source nutzen wollen, um möglichst wenig von Technologie-Anbietern abzuhängen.

Ein mögliches Problem ist das Entstehen von Forks. Wenn man sich allerdings Open Source im Allgemeinen anschaut, so ist das generell kein so großes Problem. Das gilt z.B. für Linux, anders sieht es vielleicht bei BSD aus. Man muss eben einen Fork dauerhaft weiter pflegen, und diesen Aufwand dauerhaft zu betreiben, ist nicht so einfach. Außerdem ist man von den Bug-Fixes des eigentlichen Systems abgeschnitten. Und so ist trotz der sehr liberalen Apache Lizenz zum Beispiel bei Spring soetwas bisher nicht passiert und auch sehr unwahrscheinlich. Bei Java gibt es allerdings schon heute in gewisser Weise Forks, da es viele unterschiedliche JDK-Hersteller gibt, darunter Firmen wie BEA und IBM. Eine Rolle spielt sicher auch, dass Microsoft versucht hatte, eine inkompatible Version von Java auf den Markt zu bringen. Dieses Problem ist meiner Ansicht nach aber keines mehr, denn Microsoft hat mit .NET und J# mittlerweile eine andere Strategie zum Umgang mit Java.

Andere Lizenzen können Forks effizient verhindern - ein Beispiel ist sicher JBoss mit GPL und das Vorgehen gegen Apache Geronimo wegen dem Kopieren von Code (siehe dieser Brief). Denn durch die GPL muss man seine Änderungen veröffentlichen, so dass man nicht "im stillen Kämmerlein" eine eigene Version erstellen kann, deren Änderungen nie veröffentlicht werden, und man kann den Code auch nicht unter einen anderen Lizenz wieder veröffentlichen.

Ein anderer Vorteil von Open Source ist die Innovation. Jeder kann sich beteiligen: Wenn ich eine gute Idee für eine Linux-Erweiterung habe, kann ich sie vorschlagen oder sogar implementieren und einbauen. Allerdings gibt es hier bei Java ein Problem, denn Java wird im Rahmen des JCP-Prozess standardisiert. Wenn ich einen tollen neuen Garbage Collection Algorithmus habe, kann ich ihn einbauen, weil es nach außen keine Änderung ist. Wenn ich aber eine geniale Idee für eine Modifiaktion am JDK habe, die eine Ergänzung zum Standard darstellt oder ihn gar bricht, muss ich durch den JCP-Prozess. Und der kann langsam sein. Man kann es an Spring und EJB 3 festmachen. Spring ist ein nicht standardisiertes Open Source Projekt, EJB 3 ein Standard, die beide im Java Enterprise Bereich zu Hause sind. Am 30.6.2004, als die ersten öffentlichen Versionen von EJB 3 / JSR 220 erschien, war Spring in Version 1.0.2. Als JSR 220 am 11.5.2006 final war, gab es Version 2.0M4 von Spring und dazwischen waren 1.1 und 1.2 erschienen. Dafür gibt es zahlreiche, gute Gründe wie die Integration anderer Persistenz-Ideen in JSR 220, und es gibt sicher schneller JCPs. Aber es zeigt auf jeden Fall, dass man ohne Standard schlicht schnell neue Versionen bauen kann und dadurch auch schnell Feedback aus der Praxis bekommt, mit dem man dann das Produkt iterativ verbessern kann. Und agile Methoden lehren uns, dass schnelles Feedback sehr wichtig ist.

Also: Auch wenn Java Open Source wird, werden Innovationen wie die Unterstützung von dynamischen Sprachen auch weiterhin in einem JCP standardisiert und damit wird es - selbst wenn jetzt sofort jemand eine komplette und tolle Implementierung vorlegt - erst in Java SE 7 in 2008 kommen.

Fazit: Ich glaube, dass der Schritt letztendlich eine konsequente Fortsetzun der Strategie von Sun ist, Software-Assets in Open Source zu wandeln. Die Auswirkungen sind vor allem auf der politischen und juristischen Ebene zu suchen. Für uns als Techniker sollte sich nicht allzuviel ändern.
  10:30 0 comments
Bookmark and Share
J for Java | I for Internet, iMac, iPod and iPad | Me for me

ARCHIVES
Juni 2005 / Juli 2005 / August 2005 / September 2005 / Oktober 2005 / November 2005 / Dezember 2005 / Januar 2006 / Februar 2006 / März 2006 / April 2006 / Mai 2006 / Juni 2006 / Juli 2006 / August 2006 / September 2006 / Oktober 2006 / November 2006 / Dezember 2006 / Januar 2007 / Februar 2007 / März 2007 / April 2007 / Mai 2007 / Juni 2007 / Juli 2007 / August 2007 / September 2007 / Oktober 2007 / November 2007 / Dezember 2007 / Januar 2008 / April 2008 / Mai 2008 / Juni 2008 / August 2008 / September 2008 / November 2008 / Januar 2009 / Februar 2009 / März 2009 / April 2009 / Mai 2009 / Juni 2009 / Juli 2009 / August 2009 / September 2009 / Oktober 2009 / November 2009 / Dezember 2009 / Januar 2010 / Februar 2010 / März 2010 / April 2010 / Mai 2010 / Juli 2010 / August 2010 / Oktober 2010 / Januar 2011 / Februar 2011 / März 2011 / April 2011 / Mai 2011 / Juni 2011 / August 2011 / September 2011 / November 2011 / Februar 2012 / April 2012 / Mai 2012 / April 2013 / Mai 2013 / Juni 2013 / Januar 2015 / Juli 2015 / Februar 2016 /

Links

Twitter
Google +
Slideshare
Prezi
XING
LinkedIn
Das Spring Buch


Feeds

Feedburner


Impressum
Betreiber und Kontakt:
Eberhard Wolff
Leobschützer Strasse 22
13125 Berlin
E-Mail-Adresse: eberhard.wolff@gmail.com

Verantwortlich für journalistisch-redaktionelle Inhalte:
Eberhard Wolff