... newer stories
Saturday, 7. July 2012
JFS 2012 reviewed
javatux, 17:11h
Wie jeden ersten Donnerstag im Juli fand auch dieses Jahr das Java Forum Stuttgart statt. Mit weit über 1K Teilnehmern ist es das größte Java-Ereignis im süddeutschen Raum (und sicherlich auch darüber hinaus), das man auf keinen Fall verpassen sollte. Hier trifft man alte Bekannte, lernt neue hinzu und hat genügend Zeit, zwischen den Vorträgen sich mit Gleichgesinnten auszutauschen.
Ein echtes Highlight oder Hype war nicht auszumachen in diesem Jahr. Das Cloud-Thema hat sich inzwischen etabliert, Konzepte für Parallelität gibt es, aber noch nicht im Sprachkern, Eclipse 4 hat die Erwartungen erfüllt, der Drive früherer Jahre hat aber gefehlt. Einzig der Mobil-Bereich mit Android scheint etwas Schwung in die Java-Welt zu bringen.
Auf der anderen Seite zeigt es auch, dass sich Java etabliert hat und einer der Gründungsziele der JUGS, die Verbreitung von Java, inzwischen erreicht wurde.
Bis zum nächsten Jahr...
Ein echtes Highlight oder Hype war nicht auszumachen in diesem Jahr. Das Cloud-Thema hat sich inzwischen etabliert, Konzepte für Parallelität gibt es, aber noch nicht im Sprachkern, Eclipse 4 hat die Erwartungen erfüllt, der Drive früherer Jahre hat aber gefehlt. Einzig der Mobil-Bereich mit Android scheint etwas Schwung in die Java-Welt zu bringen.
Auf der anderen Seite zeigt es auch, dass sich Java etabliert hat und einer der Gründungsziele der JUGS, die Verbreitung von Java, inzwischen erreicht wurde.
Bis zum nächsten Jahr...
... link (0 Kommentare) ... comment
Wednesday, 27. June 2012
Java Aktuell
javatux, 20:24h
Wer nach dem gestrigen Kurz-Vortrag (auf Englisch) über "10 Years PatternTesting" auf dem Eclipse Demo-Camp etwas ausführlicher die Entstehungsgeschichte hinter PatternTesting nachlesen will, findet in der aktuellen Ausgabe des iJUG-Magazins "Java aktuell" einen Artikel über "10 Years PatternTesting" (javaaktuell032012.pdf (pdf, 670 KB)
).
Die iJUG als Herausgeber dieser Zeitschrift ist ein Dachverband der Java User Groups im deutschsprachigen Raum, der auch die JUGS angehört.
Ansonsten besteht auch auf dem Java Forum Stuttgart am 5. Juli die Gelegenheit, die Geschichte von PatternTesting und einen Rückblick auf die letzten 10 Jahre life mitzuerleben (Track F4, 12:15 - 13:00).
Die iJUG als Herausgeber dieser Zeitschrift ist ein Dachverband der Java User Groups im deutschsprachigen Raum, der auch die JUGS angehört.
Ansonsten besteht auch auf dem Java Forum Stuttgart am 5. Juli die Gelegenheit, die Geschichte von PatternTesting und einen Rückblick auf die letzten 10 Jahre life mitzuerleben (Track F4, 12:15 - 13:00).
... link (0 Kommentare) ... comment
Thursday, 3. May 2012
Die 11 goldenen Logging-Regeln
javatux, 23:36h
Logging ist (neben einem Exception-Handling, das diesen Namen auch verdient) das wichtigsten Hilfsmittel, um Fehler im Betrieb zu finden. Leider wird diese Erkenntnis gerne ignoriert.
Für alle Nicht-Ignoranten gibt es die 11 goldenen Logging-Regeln von Simon Wiest:
PDF: diegoldenenlogging-regeln2006-02-20 (pdf, 178 KB)
Für alle Nicht-Ignoranten gibt es die 11 goldenen Logging-Regeln von Simon Wiest:
- Alle Meldungen in Englisch abfassen.
- Jede Meldung als vollständigen Satz formulieren.
- Jede Meldung freistehend formulieren.
- Eine Meldung nicht der Formatierung wegen auf mehrere Zeilen aufteilen.
- Textvariablen immer in einfache Anführungszeichen setzen.
- Meldungen so formulieren, daß sie im Code verbleiben können.
- Meldungen immer mit einem Punkt abschließen.
- Meldungen, die eine Exception ausgeben, mit Doppelpunkt abschließen.
- Wird der Beginn eines Zeitraumes angezeigt, die Meldung mit drei Punkten (...) beenden.
- Wird das Ende eines Zeitraumes angezeigt, die Meldung mit einem Punkt (.) beenden.
- Besser den Beginn als das Ende einer längeren Operation anzeigen.
PDF: diegoldenenlogging-regeln2006-02-20 (pdf, 178 KB)
... link (0 Kommentare) ... comment
Thursday, 19. April 2012
Star Wars in ASCII
javatux, 00:16h
Heute mal was zum Entspannen: wenn man sich Star Wars mal in ASCII anschauen will, einfach ein Terminal öffnen und
telnet towel.blinkenlights.nleingeben ;-)
... link (0 Kommentare) ... comment
Friday, 23. March 2012
10 Years PatternTesting
javatux, 08:23h
On 23th March 2002 Matt Smith and Vincent Massol initiated PatternTesting to find some of the common anti patterns like a forgotten e.printStackTrace you can find in many projects.
2002 is also the year where asserts are provided with JDK 1.4. With this new keyword it is possible to place detectors in your code for better findings of programming errors. Together with PatternTesting it is possible to automate this process e.g. to find method calls which get null arguments or returns null as return value - a common cause for NullPointerExceptions.
Today is now released the jubilee release - PatternTesting 1.2.10-YEARS. One of the new features of this release is PatternTesting Agent which must be started as Java agent:
More infos how to use the ClasspathMonitor can be found in the PatternTesting Wiki. Look at the Hello World example in the section Getting Started.
Happy PatternTesting
2002 is also the year where asserts are provided with JDK 1.4. With this new keyword it is possible to place detectors in your code for better findings of programming errors. Together with PatternTesting it is possible to automate this process e.g. to find method calls which get null arguments or returns null as return value - a common cause for NullPointerExceptions.
Today is now released the jubilee release - PatternTesting 1.2.10-YEARS. One of the new features of this release is PatternTesting Agent which must be started as Java agent:
java -javaagent:patterntesting-agent-1.2.10-YEARS.jar ...It provides the ClasspathMonitor of PatternTesting Runtime with the needed infos about the class loader to find unused classes or Jar files or to detect incompatible classes (this are classes with the same signature but different versions). The agent is only needed for class loaders which are not direct supported by the ClasspathMonitor (as e.g. is the case for the IBM JDK). For the normal Sun JDK you don't need it.
More infos how to use the ClasspathMonitor can be found in the PatternTesting Wiki. Look at the Hello World example in the section Getting Started.
Happy PatternTesting
... link (0 Kommentare) ... comment
Thursday, 2. February 2012
PatternTesting in Action
javatux, 23:08h
Today I received a mail from Reikje who uses PatternTesting and who was the beta tester for the new ProxyRunner feature in 1.2.0. In his blog Testing just got better you can read about his experience of testing with PatternTesting.
Enjoy it.
Enjoy it.
... link (0 Kommentare) ... comment
Saturday, 7. January 2012
PatternTesting 1.2.0 Released
javatux, 18:18h
Today there is a new release of PatternTesting available. What's new? First it can be now used as OSGi bundle. And second the support for parallel testing was extended:
What's else new? Some testers (ComparableTester and RuntimeTester) were added, an uberjar for patterntesting-rt is now provided and some bugs are fixed. For more changes read the release notes.
Happy PatternTesting
- patterntesting.concurrent.experimental.ParallelProxyRunner
- patterntesting.concurrent.junit.ParallelSuite
What's else new? Some testers (ComparableTester and RuntimeTester) were added, an uberjar for patterntesting-rt is now provided and some bugs are fixed. For more changes read the release notes.
Happy PatternTesting
... link (0 Kommentare) ... comment
Sunday, 1. January 2012
2012
javatux, 21:17h
2012 wird mal wieder ein Jahr, an dem die Welt untergeht. Aber bis dahin bleibt noch Zeit für ein paar gute Vorsätze dieses Jahr, als da wären:
- mehr Sport treiben (mind. 2 Stunden pro Woche),
- mit der App-Entwicklung für iPhone und iPad anfangen und
- sich von Facebook zu verabschieden.
Frohe Neues Jahr!
... link (0 Kommentare) ... comment
Wednesday, 28. December 2011
Stuttgarter Testtag 2012
javatux, 11:28h
2012 ist es wieder soweit. Zum einen geht mal wieder die Welt unter, zum anderen findet am 23.03.2012 der Stuttgarter Testtag 2012 zum dritten Mal statt. Es wird sich wieder alles rund um das Thema "Testen" drehen, ein Schwerpunkt wird dieses Mal das Testen mit und durch AOP sein. Wer zum Testen etwas zu sagen hat, hat bis zum 31.01.2012 Zeit, einen Beitrag dazu einzureichen (s.a. www.jugs.org/tt2012/cfp.html).
Abends wird dann 10 Jahre PatternTesting gefeiert. Hier besteht dann die Gelegenheit, sich in gemütlicher Runde mit anderen Teilnehmern auszutauschen und auch über Themen abseits von Java und Testen zu diskutieren.
Damit wir den Teilnehmern einen kostenlosen Eintritt ermöglichen können, haben wir mit T-Systems einen Premium-Sponsor gewinnen können. Aber wir brauchen noch weitere Sponsoren - wer hier uns gerne unterstützen wollen, findet unter www.jugs.org/tt2012/sponsoring.html weitere Informationen bzw. kann unter aop@jugs.org weitere Infos anfordern.
Auf ein erfolgreiches und test-getriebenes 2012
Abends wird dann 10 Jahre PatternTesting gefeiert. Hier besteht dann die Gelegenheit, sich in gemütlicher Runde mit anderen Teilnehmern auszutauschen und auch über Themen abseits von Java und Testen zu diskutieren.
Damit wir den Teilnehmern einen kostenlosen Eintritt ermöglichen können, haben wir mit T-Systems einen Premium-Sponsor gewinnen können. Aber wir brauchen noch weitere Sponsoren - wer hier uns gerne unterstützen wollen, findet unter www.jugs.org/tt2012/sponsoring.html weitere Informationen bzw. kann unter aop@jugs.org weitere Infos anfordern.
Auf ein erfolgreiches und test-getriebenes 2012
... link (0 Kommentare) ... comment
Thursday, 13. October 2011
Ein Programmierer sieht rot
javatux, 22:12h
Im aktuelle Javamagazin ist der Artikel "Ein Programmierer sieht rot" erschienen. Dazu erreichte mich die Frage, wie man mit Hilfe von PatternTesting JUnit-Tests mit Hilfe von Properties gruppieren kann, das in dem Artikel nur angedeutet wird. Hier die Auflösung: der Trick besteht einfach darin, dass man vor der Test-Methode (oder vor die ganze Test-Klasse) einfach ein @RunTestOn oder @SkipTestOn mit einer selbstdefinierten Property setzt:
Das Ganze kann man mit @RunTestOn auch andersrum machen: man definiert sich eine Property, und nur wenn diese Property gesetzt ist, wird der Test auch ausgeführt. Problematik dabei ist, dass man hier immer alle Properties angeben muss, wenn man alle Tests ausführen will. Ist keine Property gesetzt, wird auch kein Test ausgeführt. Ansonsten sind aber beide Verfahren gleichwertig.
@Test @SkipTestOn(property="SKIP_EXPORT_TEST") public void testEmptyExport() throws IOException { ... }Sobald dieser Test mit der Option -DSKIP_EXPORT_TEST aufgerufen wird, wird der Test ausgeblendet. Wichtig dabei ist, dass der SmokeRunner oder ParallelRunner als Testrunner verwendet wird:
@RunWith(SmokeRunner.class) public final class DatenpaketTest { … }Man kann auch mehrere Optionen angeben:
@Test @SkipTestOn(property={"SKIP_IMPORT_TEST","SKIP_EXPORT_TEST"}) public void testImportExport() throws IOException { ... }Sobald eine der beiden Properties gesetzt ist, wird der Test ausgeblendet.
Das Ganze kann man mit @RunTestOn auch andersrum machen: man definiert sich eine Property, und nur wenn diese Property gesetzt ist, wird der Test auch ausgeführt. Problematik dabei ist, dass man hier immer alle Properties angeben muss, wenn man alle Tests ausführen will. Ist keine Property gesetzt, wird auch kein Test ausgeführt. Ansonsten sind aber beide Verfahren gleichwertig.
... link (0 Kommentare) ... comment
Wednesday, 28. September 2011
Semantisch-Orientierte Programmierung
javatux, 00:00h
In der aktuellen Ausgabe des iJUG-Magazins "Java aktuell" befindet sich ein Artikel über die "Semantisch-orientierte Programmierung mit Java" (PDF: javaaktuell042011.pdf (pdf, 364 KB)
). Es basiert im Wesentlichen auf den Ideen, die hinter den Soplets (s. soplets.org) stecken.
Die iJUG ist ein Dachverband der Java User Groups im deutschsprachigen Raum, der auch die JUGS angehört. Eines der Ziele der iJUG ist es, den User Groups ein stärkeres Gewicht gegenüber Oracle zu geben, was mir seit der Übernahme durch Sun dringend nötig erscheint.
Die iJUG ist ein Dachverband der Java User Groups im deutschsprachigen Raum, der auch die JUGS angehört. Eines der Ziele der iJUG ist es, den User Groups ein stärkeres Gewicht gegenüber Oracle zu geben, was mir seit der Übernahme durch Sun dringend nötig erscheint.
... link (0 Kommentare) ... comment
Thursday, 4. August 2011
Bundles bauen
javatux, 13:25h
Wenn man mit OSGi arbeitet, wird man sehr schnell feststellen, dass man die Bibliotheken, die man gerne einsetzen möchte (oder muss), auch als OSGi-Bundle vorliegen muss. Was macht man aber, wenn man die gewünschte Jar-Datei nicht als Bundle vorfindet? Dann muss man die Jar-Datei um die entsprechende Meta-Information anreichern, die aus einer Jar-Datei ein OSGi-Bundle macht. Wie? Anhand des JDBC-Treibers für DB2 werden wir die einzelnen Schritte durchexerzieren.
Man kann die MANIFEST.MF-Datei manuell erstellen, besser und weniger fehleranfällig ist es aber, wenn man dazu die BND-Tools benutzt. Benötigt wird hiervon die Jar-Datei
biz.aQute.bnd.jar.
Falls man mit Eclipse arbeitet, bieten sich auch die bnd-tools als Eclipse-Pluginan, die über die Update-Site http://bndtools-updates.s3.amazonaws.com installiert werden können. Dieses Plugin bietet u.a. einen Viewer für Jar-Dateien an, mit dem man recht komfortabel den Inhalt der Jars und deren Manifest-Datei anschauen kann.
Als Bundle-SymbolicName wird für Jar-Dateien, die bereits als OSGi-Bundles vorliegen, meist der oberste Package-Namen verwendet. So verwendet Commons Lang von Apache "org.apache.commons.lang" als symbolischen Namen. Bei Jar-Dateien, die noch nicht als OSGi-Bundle vorliegen, hat es sich eingebürgert, hier noch den Namen des Projekts oder der Firma voranzustellen, um es von den Original-Jar-Dateien abzugrenzen. In unserem Fall verwenden wir also nicht "com.ibm.db2jcc", sondern z.B. "de.blogger.oli.com.ibm.db2jcc". Man kann aber auch einen beliebigen anderen Namen hierfür verwenden.
Bei der Bundle-Version nimmt man am besten die Version des Treibers. Dies ist im Falle von dbj2cc.jar schon etwas schwieriger, da man diese Version auch nicht innerhalb der Jar-Datei findet. Unter DB2 JDBC Driver Versions findet man aber einige Hinweise, um welche Version es sich handeln könnte (hier war es die Version 3.53.70).
Für die Bundle-RequiredExecutionEnvironment müssen wir wissen, welche Java-Version wir mindestens benötigen. Dazu finden wir in der Manifest-Datei den Hinweis, dass sie mit JDK 1.4.2 gebaut wurde, d.h. der Treiber ist unter J2SE-1.4, J2SE-1.5 und JavaSE-1.6 lauffähig.
Über Export-Package gibt man bekannt, welche Packages nach außen sichtbar sein sollen. Ein Blick in die Jar-Datei lässt vermuten, dass dies die Packages "com.ibm.db2.jcc" und "sqlj.runtime", sowie alle Packages unter "COM.ibm.*" und "sqlj.runtime.*" sind.
Bei Import-Package kann man es sich einfach machen und einfach "*" als Wildcard eingeben. Dann ermittelt das BND-Tool die Imports selbst - allerdings kann er nur die direkten Imports erkennen oder schießt manchmal auch über das
Ziel hinaus und findet auch Imports, die nur in Ausnahmefällen benötigt werden. Da es sich in unserem Fall um einen JDBC-Treiber handelt und dafür die Packages "java(x).sql" benötigt werden, helfen wir BND mit com.ibm.db2.jcc.licenses, java.sql*, javax.sql*, *;resolution:=optional auf die Sprünge. *;resolution:=optional bedeutet dabei, dass alle restlichen Imports optional sein sollen.
Bei Private-Package machen wir es uns einfach - alles was übrig bleibt, kennzeichen wir als "private". Damit ergeben sich folgende Einträge für db2jcc.bnd:
Weitere Information zum Bau von Bundles findet sich z.B. unter
http://swik.net/Spring/Interface21+Team+Blog/Creating+OSGi+bundles/b2yoy
Vorbereitungen
Im wesentlichen unterscheidet sich ein Bundle von einer normalen Jar-Datei dadurch, dass unter META-INF/MANIFEST.MF zusätzliche Meta-Informationen wie- exportierte Packages
- importierte Packages
- und mehr (z.b. importierte Packages)
Man kann die MANIFEST.MF-Datei manuell erstellen, besser und weniger fehleranfällig ist es aber, wenn man dazu die BND-Tools benutzt. Benötigt wird hiervon die Jar-Datei
biz.aQute.bnd.jar.
Falls man mit Eclipse arbeitet, bieten sich auch die bnd-tools als Eclipse-Pluginan, die über die Update-Site http://bndtools-updates.s3.amazonaws.com installiert werden können. Dieses Plugin bietet u.a. einen Viewer für Jar-Dateien an, mit dem man recht komfortabel den Inhalt der Jars und deren Manifest-Datei anschauen kann.
Analyse DB2Driver
Am Beispiel des JDBC-Treibers für DB2, der als Päärchen db2jcc.jar und db2jcc_license_cu.jar daherkommt, wollen wir uns an den Bau eines OSGi-Bundles machen. Fangen wir mit der ersten Jar-Datei, db2jcc.jar, an. Folgende Informationen (neudeutsch: Properties) benötigen wir für das Bundle:Bundle-Name: db2jcc Bundle-Description: DB2 JDBC driver Bundle-SymbolicName: Bundle-Version: Bundle-RequiredExecutionEnvironment: Export-Package: Import-Package: Private-Package:Diese Information schreiben wir in die Datei db2jcc.bnd, die in dieser Form von den BND-Tools als Steuer-Datei benutzt werden kann. Die ersten beiden Einträge sind schon ausgefüllt und benötigen eigentlich keiner weiteren Erklärung.
Als Bundle-SymbolicName wird für Jar-Dateien, die bereits als OSGi-Bundles vorliegen, meist der oberste Package-Namen verwendet. So verwendet Commons Lang von Apache "org.apache.commons.lang" als symbolischen Namen. Bei Jar-Dateien, die noch nicht als OSGi-Bundle vorliegen, hat es sich eingebürgert, hier noch den Namen des Projekts oder der Firma voranzustellen, um es von den Original-Jar-Dateien abzugrenzen. In unserem Fall verwenden wir also nicht "com.ibm.db2jcc", sondern z.B. "de.blogger.oli.com.ibm.db2jcc". Man kann aber auch einen beliebigen anderen Namen hierfür verwenden.
Bei der Bundle-Version nimmt man am besten die Version des Treibers. Dies ist im Falle von dbj2cc.jar schon etwas schwieriger, da man diese Version auch nicht innerhalb der Jar-Datei findet. Unter DB2 JDBC Driver Versions findet man aber einige Hinweise, um welche Version es sich handeln könnte (hier war es die Version 3.53.70).
Für die Bundle-RequiredExecutionEnvironment müssen wir wissen, welche Java-Version wir mindestens benötigen. Dazu finden wir in der Manifest-Datei den Hinweis, dass sie mit JDK 1.4.2 gebaut wurde, d.h. der Treiber ist unter J2SE-1.4, J2SE-1.5 und JavaSE-1.6 lauffähig.
Über Export-Package gibt man bekannt, welche Packages nach außen sichtbar sein sollen. Ein Blick in die Jar-Datei lässt vermuten, dass dies die Packages "com.ibm.db2.jcc" und "sqlj.runtime", sowie alle Packages unter "COM.ibm.*" und "sqlj.runtime.*" sind.
Bei Import-Package kann man es sich einfach machen und einfach "*" als Wildcard eingeben. Dann ermittelt das BND-Tool die Imports selbst - allerdings kann er nur die direkten Imports erkennen oder schießt manchmal auch über das
Ziel hinaus und findet auch Imports, die nur in Ausnahmefällen benötigt werden. Da es sich in unserem Fall um einen JDBC-Treiber handelt und dafür die Packages "java(x).sql" benötigt werden, helfen wir BND mit com.ibm.db2.jcc.licenses, java.sql*, javax.sql*, *;resolution:=optional auf die Sprünge. *;resolution:=optional bedeutet dabei, dass alle restlichen Imports optional sein sollen.
Bei Private-Package machen wir es uns einfach - alles was übrig bleibt, kennzeichen wir als "private". Damit ergeben sich folgende Einträge für db2jcc.bnd:
bsn: de.blogger.oli.com.ibm.db2jcc version=3.53.70 Bundle-Name: db2jcc Bundle-Description: DB2 JDBC driver Bundle-SymbolicName: ${bsn} Bundle-RequiredExecutionEnvironment: J2SE-1.4,J2SE-1.5,JavaSE-1.6 Bundle-Version: ${version} Export-Package: com.ibm.db2.jcc,COM.ibm.*,sqlj.runtime,sqlj.runtime.*;version=${version} Import-Package: com.ibm.db2.jcc.licenses,java.sql*,javax.sql*,*;resolution:=optional Private-Package: * -classpath: db2jcc.jar -output: ${bsn}-${version}.jarMit den ersten beiden Zeilen definieren wir zwei Variablen, die wir intern verwenden, um uns die Arbeit etwas zu erleichtern. Die letzten beiden Zeilen werden durch ein Minus "-" eingeleitet und werden als entsprechende Option an das BND-Tool durchgereicht.
BND-Tool aufrufen
java -jar biz.aQute.bnd.jar db2jcc.bndDamit wird die Datei de.blogger.oli.com.ibm.db2jcc-3.53.70.jar erzeugt, die sich jetzt als Bundle in Felix oder anderen OSGi-Containern laden lässt. Wichtig beim Aufruf ist, dass die Steuer-Datei die Endung ".bnd" trägt.
Weitere Information zum Bau von Bundles findet sich z.B. unter
http://swik.net/Spring/Interface21+Team+Blog/Creating+OSGi+bundles/b2yoy
Zusammenfassung
Um aus einer normalen Jar-Datei ein OSGi-Bundle zu machen, sind folgende Schritte nötig:- biz.aQute.bnd.jar herunterladen
- .bnd-Datei erstellen (s. Beispiel db2jcc.bnd)
- Original-Jar wrappen: java -jar biz.aQute.bnd.jar db2jcc.bnd
... link (0 Kommentare) ... comment
Monday, 11. July 2011
Tamagotchi for Java-Developers
javatux, 20:26h
Last week there was the Java Forum Stuttgart with more than 1000 people, a lot of tweets and a lot of tips. One of the tip in a talk was TDGothi - the tamagotchi for TDD (Test Driven Design). Should I test it? Why not.
After installation I enabled it as fast view. Here my short result after 2 days working with it:
After installation I enabled it as fast view. Here my short result after 2 days working with it:
- works stable
- is fun (not more)
- does not disturb you
... link (0 Kommentare) ... comment
Tuesday, 28. June 2011
Was ist SOP?
javatux, 22:35h
Anfang Juni fand bei der JUGS ein Workshop zur Semantisch Orientierten Programmierung (SOP) statt. Die Kernidee dabei ist, dass die Datenbeschreibung mit Java-Hausmitteln erfolgt, nämlich Enumerations gekoppelt mit Annotations. Genau diesen Ansatz habe ich mit der Version 0.6 von gdv.xport ausprobiert und die Datenbeschreibung des GDV-Formats in die entsprechende Enumeration (z.B. Feld100) umgesetzt. Die Logik für den Umgang mit diesen Enumeration musste ich zwar selber schreiben, aber der große Vorteil dieses Ansatzes besteht darin, dass neue Satzarten sehr leicht von Außenstehende ergänzt werden können. Dies war mit der vorigen Version nicht so einfach möglich.
Und darin liegt in meiner Einschätzung auch der große Vorteil des SOP-Ansatzes: die Datenbeschreibung erfolgt komplett mit Java-Mitteln. Damit reicht ein Blick in den Source-Code für die aktuelle Beschreibung. Klar geht das auch mit einer eigenen DSL und selbstgeschriebenem Generator, aber hier ist oft die Gefahr, dass man eigentlich Generator-Entwicklung macht (von Problemen mit dem Refactoring mal ganz zu schweigen).
Näheres zu SOP findet man über die Vortragsfolien des Workshops oder aber auch über soplets.org.
Und darin liegt in meiner Einschätzung auch der große Vorteil des SOP-Ansatzes: die Datenbeschreibung erfolgt komplett mit Java-Mitteln. Damit reicht ein Blick in den Source-Code für die aktuelle Beschreibung. Klar geht das auch mit einer eigenen DSL und selbstgeschriebenem Generator, aber hier ist oft die Gefahr, dass man eigentlich Generator-Entwicklung macht (von Problemen mit dem Refactoring mal ganz zu schweigen).
Näheres zu SOP findet man über die Vortragsfolien des Workshops oder aber auch über soplets.org.
... link (0 Kommentare) ... comment
... older stories