Standard beachten und Bugs produzieren...

Von e7 am 08.02.2009, 22:34 in der Kategorie e7o.de mit den Tags standard xml rss verbesserung bug e7o.de. Kompletten Eintrag zeigen

Nun hat's mich selbst ganz böse erwischt: In der Sidebar steht ganz groß „Vollständige Feeds“ für meine RSS-Feed, und dabei wurde immer was abgeschnippelt. Ist damals beim Testen nicht so aufgefallen, da die Einträge immer kürzer waren. Der Atom-Feed enthielt schon immer die vollständigen Einträge; dem RSS-Feed fehlte bisher der komplette <content:encoded>-Bereich. Außerdem hab ich inzwischen von <author> auf <dc:creator> umgestellt, da ersteres eigentlich eine vollständige Mailadresse erwartet. Und <guid> enthält jetzt den (oder zumindest einen) Perma-Link (Notiz an mich: SEO-Links rein…)

Ach ja, und es gibt noch eine große, wichtige Neuerung: Der Feed wird jetzt visuell komplett korrekt ausgeliefert. Man sieht nun keinerlei BB-Codes mehr, diese sollten eigentlich komplett in HTML geparst werden. Zumindest ist mir kein BB-Code mehr aufgefallen.

Außerdem habe ich rechts die Sidebar leicht aufgeräumt und umgeschlichtet. Dabei ist mir aufgefallen, dass ich das mit meinem CMS doch noch mal überdenken sollte — es ist doch schon wieder sehr viel Gebastel und Gefrickel. Vielleicht mal wirklich ordentlich Software Engineering betreiben, samt Wasserfallmodell und irgendwelchen Anforderungsanalysen, Sequenzdiagrammen etc. — was allerdings die Sache ziemlich verzögern dürfte.

Ansonsten nur noch der Hinweis: Jeder, der bisher gezögert hatte, meinen Feed zu abonnieren, kann sich jetzt nicht mehr rausreden. Sauber, korrekt umgesetzt, vollständige Einträge, interessanter Content (hoffe ich zumindest). Den Rest bitte ich auf diesem Wege, einfach mal einen Kommentar zu diesem Blogeintrag zu posten. Ich wüsste nämlich gerne, wie viele aktive Leser (die sogar Blogeinträge wie diesen lesen) es so ungefähr gibt — vielen Dank schon mal :) Feedback ist natürlich ebenfalls willkommen, ebenso welche Themen ich weglassen soll, von was mehr kommen könnte usw.

Und nun: Let's follow :)

Java und die Abwärtskompatibilität

Von e7 am 08.02.2009, 20:40 in der Kategorie Niederschmetternde Erkenntnisse mit den Tags buggy implementation abstrus garbage collector konstruktor schrott java programmierung. Kompletten Eintrag zeigen

Dass ältere Programme mit neueren Dateien Probleme haben, ist ja nichts neues; und jede Programmversion bringt häufig eigene Dateiformate mit. Bestes Beispiel sind Photoshop, MS Office und andere. Dann gibt's noch das Phänomen, dass neue Programme die Dateien ihrer Vorgänger nicht mehr lesen können — im Regelfall kennt man das von Word, das sogar bei gleicher Version auf unterschiedlichen Rechnern Probleme gibt.

Nun gibt es ja auch dieses tolle Java. Gibt sich als fortschrittlich, als ziemlich sauber, objektorientiert, und was weiß ich nicht alles. Plattformkompatibel soll es sein, und auch Abwärtskompatiblität hat es sich auf die Fahnen geschrieben. Sprich: Programmcode, den man ursprünglich mal mit 1.4 (oder ähnlich) entwickelt hat, sollte auch durch den aktuellen 1.6-er Compiler laufen. Nun ergibt sich allerdings folgendes Problem:

Test.java:14: cannot find symbol
symbol : constructor A()
location: class A
public B() {
^
1 error

Was ist hier passiert? Ein Blick auf den Code lässt uns rätseln, wenn wir nicht wissen, was hier klammheimlich (wurde sicher irgendwo angekündigt, aber wer liest das schon…) irgendwo in 1.6 eingeschmuggelt wurde:

public class Test {
    public static void main(String args[]) {
        B b = new B();
    }
}

class A {
    public A(int a) {
        System.out.println(„Hallo“);
    }
}

class B extends A {
    public B() {
        System.out.println(„Neu“);
    }
}

Der Javacompiler scheint also das explizite Weglassen (oder unabsichtliche Vergessen) von super(); automatisch nachholen zu wollen. Dumm nur, dass in diesem Fall kein Konstruktor A() existiert, sondern nur A(int). Da der Compiler keine Zahlen erfindet und andererseits (hier) keinen Default-Konstruktor anlegt, muss das logischerweise zu einem Fehler führen.

Und schon ist die Abwärtskompatibilität im Eimer. Aber was macht das schon — wer mit Java bastelt, muss sich sowieso an einiges gewöhnen. Vom Swing-Kaugummi rede ich jetzt gar nicht, das gibt sonst wieder böse Worte von den Java-Fans. Dass Java immer etwas anders implementiert ist als in anderen Sprachen, daran muss man sich auch gewöhnen. Bestes Beispiel hier: s.subString(1, 3). Das gibt nicht etwa drei Zeichen ab dem zweiten Zeichen des Strings beginnend (C++, VB, PHP, Perl, JavaScript (wobei substring() mit substr() von Java identisch ist), SQL) — sondern zwei Zeichen. Auch dass der Garbage Collector selbst nach dem Aufruf von System.gc() nur „möglicherweise“ läuft, kann man mit ein bisschen Mitdenken ausbügeln (Destruktor? Ach, nachher mal…) Dass array.length und string.length() unterschiedlich mit den Klammern dahinter umgehen, ist historisch bedingt. Dass Calendar.get(Calendar.DAY_OF_MONTH)) bei 1 beginnt und Calendar.get(Calendar.MONTH)) bei 0, muss man auch nur wissen, um es zu beachten. Und die Versionsnummern sind uns eh völlig wurscht.

Hatte ich schon mal erwähnt, dass ich Java mag? Nein? Ich weiß warum.