Tag Archive: Java


ocajpKönnen Klassen in Java „protected“ oder sogar „private“ sein? Welchen Case springt ein Switch mit einem null-String an? Ist ein statischer Konstruktor ein Konstruktor mit „static“-Modifier? Werden Methoden oder Variablen dynamisch oder statisch gebunden? Können Interfaces von mehreren anderen Interfaces erben? Kompiliert eine Klasse mit der Methode „private static void main“ und ist diese startfähig? Wer solche Details nicht weiß, braucht sich über das Thema Zertifizierung noch keine Gedanken machen. Ich mache mir bereits seit Monaten Gedanken.

Seit Anfang der Woche bin ich offiziell ein von Oracle zertifizierter Java-Programmierer – endlich! Die hierzu nötige Prüfung habe ich mit 85% bestanden. Zum Bestehen brauchte man 63% der richtigen Antworten, dieser Wert variiert je nach Schwierigkeitsgrad des Aufgabenkatalogs. In meinem Fall handelte es sich um ziemlich schwere Aufgaben. Zum Vergleich: Nur wenige Jahre zuvor waren zum Bestehen stolze 77% nötig, die Aufgaben also wesentlich einfacher. Zweieinhalb Stunden hat man Zeit, sich beinahe 90 hirnverknotende Codebeispiele durchzulesen, im Kopf zu interpretieren und dann via Multiple-Choice die richtige Antwort anzuklicken – weniger als zwei Minuten pro Aufgabe. Ansatzpunkte gibt es natürlich keine. Ein paar kümmerliche Alibi-Wissensfragen zwischen den endlosen Zeilen voller Quellcode sollen wohl beruhigend wirken. Am Ende hat mir die Zeit gerade so gereicht.

Die fast 200 Euro teure Zertifizierung (Schulungsmaßnahmen nicht eingerechnet) zum sogenannten „Oracle Certified Associate, Java SE 7 Programmer“ (kurz OCAJP) ist die erste, die man als Java-Programmierer absolvieren kann, sie ist mittlerweile Voraussetzung für sämtliche weiteren. Jetzt habe ich die Möglichkeit, mich irgendwann sogar als professioneller Java-Programmierer (OCPJP) zertifizieren zu lassen, was ich definitiv plane, aber bis dahin wartet noch sehr viel mehr an Vorbereitung und Training auf mich. Das gedruckte Zertifikat sollte in den nächsten sieben Wochen bei mir eintreffen, bis dahin kann ich mich an der PDF-Version ergötzen.

Wer sich mit dem Thema noch nie befasst hat, aber neugierig auf die Prüfung ist, sollte gewarnt sein. Die Fragen sind wirklich knallhart. Es wird nie nach den allgemeinen Dingen gefragt, die jeder Java-Programmierer beantworten kann. Es werden gezielt die Schwachstellen abgeklopft, all jene Aspekte und Grenzfälle abgeprüft, die viele eben nicht kennen. Die Prüfung spekuliert darauf, dass viele etwa den einfachen Unterschied zwischen String s = „Hallo“; und String s = new String(„Hallo“); nicht kennen, und fragt dann gerne ganz genau nach, wieviele Objekte der Garbage Collector der JVM aufräumen darf.

Ich bin voller Stolz, diese Hürde erfolgreich genommen zu haben. Der OCAJP war der nächste große Schritt, mich im Bereich Softwareentwicklung bzw. Java-Programmierung zu beweisen und zu etablieren. So ein Zertifikat kann eines Tages den Unterschied zwischen Arbeitslosengeld und Gehalt ausmachen. Oder zwischen Gehalt und Gehalt++. Das muss sich alles noch herausstellen. Bis dahin werde ich weiterhin Erfahrung sammeln und Bücher wälzen.

Weil es so lustig war und ich neues Material gesammelt habe, denke ich, dass es an der Zeit ist, das Quellcode-Gruselkabinett mit einem zweiten Artikel fortzusetzen, womöglich zu beenden. Der (nicht näher definierte) Praktikant aus dem ersten Teil hat wieder zugeschlagen und hocheffizienten und extrem sinnvollen Java-Code produziert. Diese Glanzleistung moderner Softwareentwicklerkunst wollte ich denjenigen meiner Leser, die über Programmierkenntnisse (und Englischkenntnisse) verfügen, auf keinen Fall vorenthalten. Wer von Programmieren überhaupt nichts versteht, der wird an diesem Artikel wie gewohnt leider nichts finden können.

Der Praktikant ist offenbar ein großer Fan davon, toString() auf String-Objekten aufzurufen, vielleicht erhofft er sich dadurch noch stärkere Typsicherheit mit Netz und doppeltem Boden oder sowas. Jedenfalls Code wie der obige begegnet mir leider immer häufiger. Solchen Murks mache ich bei Sichtung auch sofort wieder raus.

Ebenfalls ein ständiger Begleiter in seinem Code: Die Angst, dass eine neu (=leer) angelegte Collection vielleicht doch nicht so leer ist, wie sie vorgibt zu sein. Anders kann ich mir nicht erklären, wieso der Praktikant gleich nach dem Erstellen einer leeren Collection diese leert. Womöglich hat er sich hierbei etwas gedacht, ist aber völlig unnützer Code. Ein damit sehr verwandtes Problem ist das folgende:

Aus der API-Dokumentation der oberen Methode: „The Calendar returned is based on the current time in the default time zone with the default locale.„. Der Knackpunkt ist, dass das zurückgegebene Kalender-Objekt immer bereits mit der gegenwärtigen Uhrzeit initialisiert ist. Hier (zur Sicherheit oder aus Unkenntnis) nochmals Uhrzeit und Datum zu setzen und dafür extra ein neues Date-Objekt zu erstellen, ist kompletter Unfug. Überhaupt: Wieso geht er davon aus, dass der parameterlose Konstruktor von Date() die aktuelle Uhrzeit liefert, aber bei Calendar soll selbiges System nicht funktionieren? Nett auch die Wahl des Variablennamens „actCal“ für den Kalender. Er dachte wohl, „actual calendar“ sei eine brauchbare Übersetzung für das, was er ausdrückten wollte. Ich lese da aber irgendwie immer nur „Aktkalender“.

Auch so ein Codekonstrukt, worüber man diskutieren sollte: die Getter-Methode für private Konstanten. Wieso nicht gleich die Konstante als public deklarieren, dann kann man sich das Rumgeeiere sparen. Bei Konstanten durchaus sinnvoll. Aber als verwandtes Problem sei angemerkt, dass der Praktikant zum Beispiel ganz gerne auch mal simple Getter-Methoden innerhalb derselben Klasse aufruft, in der sie definiert werden – anstelle der sichtbaren Variable. Kapselung schön und gut, aber damit ist doch eigentlich Kapselung von der Außenwelt gemeint. Das scheint jemand nicht so richtig verstanden zu haben.

Namenskonventionen für Methoden sind auch so ein Problem für den Praktikanten. Der Name der Methode sagt leider nichts darüber aus, was der Rückgabetyp sein könnte. Im Fall von „componentParser“ ist noch nicht einmal eine Tätigkeit erkennbar. Da meldet die als Frage formulierte Methode „isActive“ eine komplexe Hashmap zurück, und die etwas umständlich benannte Methode „getTheParsedSysInfoComp“ liefert nicht etwa „die kompletten Systeminformationen“ zurück, sondern einen Wahrheitswert – was auch immer dieser aussagen soll. Immer wieder lustig mitanzusehen sind Methodennamen, die erkennen lassen, dass sich dabei wohl jemand beim Ausdenken einen abbrechen musste, etwa „isLoadTimeFromOneSystemOverTime“.

Englisch scheint ohnehin nicht so seine ultimative Stärke zu sein, vor allem wenn die (netterweise konsequent, wenn auch unnötigerweise) im Englischen gehaltenen Kommentarzeilen nur so vor Denglisch triefen. Da wird aus „Pfade herausfiltern“ schonmal „filter the path outside“, oder das weibliche Possessivpronomen „her“ wird auf Systeme und _ihre_ Eigenschaften angewandt. Wenn man kein Englisch kann, sollte man vielleicht nicht unbedingt versuchen, alles immer englisch schreiben zu wollen, oder zumindest mal ein paar Vokabeln nachschlagen, bevor man in die Tasten haut.

Neuer Eintrag für das vielfach gelesene Entwicklertagebuch: Hallo Fans, ich habe eine Kleinigkeit in Bezug auf mein Java-Remake SPACOLA Eclipse zu vemerken. Nachdem ich in der letzten Version bedauerlicher- aber nötigerweise nur unbedeutende Dinge vorstellen konnte, wollte ich dieses Mal einige neue Features für das Gameplay implementieren. So in den letzten Tagen geschehen. Ein Screenshot sagt dabei mehr als tausend Worte.

alpha033

Der Screenshot ist mir leider nicht besonders gelungen, ich hätte da gerne ein paar Gegner im Bild gehabt und so. Screenshots zu machen ist nämlich eine echte Kunst, habe ich festgestellt, und oft ist es schwierig, im richtigen Moment den „Auslöser“ zu drücken. Nun sei es drum, jenes kleine Bild demonstriert gleich mehrere Aspekte, die kürzlich mehr oder weniger fertig geworden sind:

1. Der Spieler kann jetzt theoretisch jedes beliebige Raumschiff lenken (also auch Piratenschiffe), mittlerweile insgesamt sechs an der Zahl. Nützlich wird so etwas für etwaige Fuchsjagd-Multiplayer-Modi oder sowas, also überall da wo jemand die Rolle der fiesen Gegner übernehmen möchte. Im Screenshot ist es eines der Gegnerschiffe, die erst nach Level 8 oder später auftauchen.

2. Komplette Minenfelder sind endlich im Spiel: Dazu habe ich die beiden Standardminen eingebaut, wovon eine nur unter Beschuss explodiert, die andere einen Annäherungssensor hat, der die Mine bei Spielerkontakt zur Detonation bringt. Wenn man da versehentlich hineinfliegt, geht auf dem Bildschirm wirklich die Post ab.

3. Der Station-Trapper, der eine beliebige Raumstation mit einer ganzen Batterie an Minen eines beliebigen Typs bestückt. Die Klasse kennt alle möglichen Defaults für SPACOLA-typische Formationen (unterschiedlich aufgebaute Minenfelder, wie sie eben im Spiel vorkommen), oder man gibt selbst Werte wie Anzahl Elemente, Abstand und Radius vor. Als kleine Erweiterung kann man Minen nicht nur kreisförmig wie im Original, sondern auch in rechteckiger Formation um eine Station platzieren (im Screenshot rechts oben zu sehen), was im Original so niemals vorgekommen ist. Für einen Leveleditor eine vielleicht ganz nützliche Funktion.

4. Explosionen mit Trümmerteilen (Debris explosions) sind endlich fertig, so wie diese im Original von Minen oder bestimmten Piratenschiffen erzeugt wurden. Explodiert eine Mine, so werden viele sich drehende Trümmerpartikel freigegeben, die dem Spieler sogar schaden können. Einzelne Partikel teilen sich dabei auf und verglühen nach einer Weile. Diesen Mechanismus hinzubekommen, da habe ich eine Weile basteln müssen. Das Zeichnen aller Trümmerexplosionen mit den vielen Partikeln habe ich dabei sogar rekursiv implementiert: Wenn die Monochrom-Grafikengine eine Partikelexplosion zeichnen soll, ruft dieselbe Methode sich selbst nochmals mit jedem einzelnen Trümmerteilchen auf. Toll, dass man sowas mal in der Praxis verwenden kann.

dev_snapshot_smallLeider fehlt noch mindestens das „Game Over“ und die Eingabe der Highscore, daher noch immer keine spielbare Demo. Ich denke als nächstes müsste ich mich auch mal um Turrets, also Abwehrgeschütztürme von Stationen kümmern, aber dazu könnte ich tatsächlich mal ein oder besser zwei Wochen Urlaub gebrauchen. Aber immerhin habe ich das Dongleware-Museum Anfang der Woche mal um einige Einträge erweitert, ein paar Beschreibungen ergänzt, Tippfehler korrigiert und Screenshots ersetzt. Manche Dinge muss ich noch einpflegen, dazu komme ich hoffentlich noch. Für Fans lohnt sich ein Blick.

Für ganz Neugierige hänge ich hier noch einen kleinen Eindruck meiner Entwicklungsumgebung an, also das Ding, das ich mir manchmal stundenlang anschaue und merkwürdigen Text eingebe, damit irgendwann hoffentlich mal ein Spiel rauskommt. Ob der Plan aufgeht, wird sich Ende des Jahres vielleicht mal zeigen.

In meinem Beruf komme ich sehr oft mit den Quelltexten vieler Kollegen in Kontakt, deren Programmierwerke ich lesen, verstehen und erweitern können muss. Man gewöhnt sich daran, dass jeder irgendwo seinen eigenen Stil hat, und dass eben jener manchmal besser und manchmal schlechter lesbar ist. Auch ich habe schon Code geschrieben, auf den ich nicht stolz bin, aber man lernt ja schließlich aus Fehlern. Umso amüsanter ist es, wenn man als erfahrener Entwickler hin und wieder zu lesen bekommt, was sich ein blutiger Anfänger so aus seinen Hirnwindungen drückt.

So geschehen vor einigen Monaten, als ein unerfahrener Praktikant (nennen wir ihn im Folgenden einfach „Praktikant“) eine unbedeutende Erweiterung für ein Softwareprojekt schreiben sollte, für das ich teilweise die Verantwortung trage. Ich gehe zwar nicht näher auf die Details der Implementierung ein, aber ich habe drei kleine kuriose Codeschnipsel gesammelt, die mir in seinem Quellcode so aufgefallen sind. Das ist übrigens derselbe Praktikant, der (um mir einen Screenshot zu zeigen) eine Bilddatei in ein leeres Microsoft Word-Dokument eingefügt hat, damit er das Dokument als PDF-Datei exportieren konnte, um es mir dann per E-Mail zu schicken.

Achtung, der folgende Beitrag könnte für Nicht-Programmierer äußerst uninteressant sein.

Fangen wir mit etwas Leichtem an. Die obige, mehrfach verschachtelte Collection beweist zwar, dass der Praktikant einen sicheren Umgang mit Collections haben muss, aber diese einzeilige Ausgeburt der Hölle beweist leider auch, dass er nicht weiß, dass man im Idealfall gegen Schnittstellen programmiert, und dass er es wohl gern übertreibt. Was auch immer in diesem „Ding“ gespeichert wird, es klingt jedenfalls nicht gesund.

Diese Zeile bekommt Sonderpunkte, weil ich darüber erst einen Augenblick nachdenken musste. Mal davon abgesehen, dass der Praktikant sich hier weder an die Namenskonvention für Boolean-Variablen hält, noch verstanden hat, dass eine Boolean-Variable bereits die Antwort auf die Frage ist, bestaunte ich die kreative logische Verknüpfung. Während ich mich ungläubig fragte, ob der Compiler einen „umgedrehten Ungleich-Operator“ wirklich durchgehen lässt, fiel mir dann doch auf, dass das eigentlich eine Zuweisung ist, wobei dem zugewiesenen Wert (false) ein NOT vorangestellt wird (also true). Dieser „Vergleich“ ergibt immer true, der IF-Block wird immer ausgeführt. Dieses Codekonstrukt ist absoluter Käse. Vielleicht wollte uns der Praktikant aber auch nur ein wenig erheitern.

Das ist der Gewinner in der Kategorie „Kreativster Schundcode“. Drei Dinge sind absolut bemerkenswert: Zunächst testet man immer mit dem Gleichheitsoperator (==) auf null, definitiv nicht mit equals. Außerdem testet man normalerweise deshalb auf null, weil man eine NullPointerException vermeiden möchte, während der Praktikant hier sogar noch selbst eine werfen will. Und überhaupt: Der Test auf null mit equals kann niemals funktionieren, denn wenn someObject tatsächlich null sein sollte, wird mit equals bereits implizit eine NullPointerException geworfen, wo versucht wird, explizit eine zu werfen. Für das Fazit lasse ich den von mir sehr geschätzten, leider kürzlich verstorbenen Harold Ramis als Dr. Egon Spengler zu Wort kommen: „Kurz, aber völlig sinnlos.“

Und dann war da noch dieser eine unwahrscheinliche „interne“ Fehler der Eclipse IDE, den ich wohl versehentlich verursacht habe, als ich während eines Debugging-Durchlaufs versuchte das Workbench-Fenster horizontal zu verkleinern. Die Fehlermeldung, die schon beinahe als Realsatire durchgehen könnte, lasse ich im Folgenden einfach mal für sich selbst sprechen:

internalerror_eclipse

Leider nicht ganz pünktlich zum dreijährigen Geburtstag von SuccessDenied.com, der diesmal ein wenig im Stillen gefeiert wurde, hier nun nach beinahe zweiwöchiger artikelloser Phase das versprochene WIP-Preview-Video der neuesten Version meines Java-Remakes: SPACOLA Eclipse WIP 0.29. Ich muss hier allerdings wieder einmal betonen, dass YouTube das Originalvideo nach dem Upload unnötigerweise in matschige Videogrütze verwandelt hat(*). Und die niedrige Framerate des Videos repräsentiert in keinster Weise die eigentlich sehr weichen Bewegungen des Spiels. Um das einmal in Zahlen auszudrücken: Das Video hat eine Framerate von etwa 26 fps, das Spiel läuft aber mit 52 fps, also exakt doppelt soviele Bilder. Den Unterschied sieht man.

Drei Jahre SuccessDenied heißt bei aller Sektstimmung aber auch, dass ich seit bald drei Jahren an dem noch lange nicht fertigen Spiel arbeite, aber das ist für mich kein Problem, denn dafür investiere ich als einziger Entwickler eben zuwenig Zeit. Auch die kommenden zwei bis drei Monate sieht es relativ unrosig aus, denn ich muss mich um viele Dinge kümmern, die ich lange aufgeschoben habe. Ich werde den Quellcode nur noch gelegentlich mal anrühren. Aber spätestens nächstes Jahr lege ich wieder richtig los.

Das Video demonstriert so einige Aspekte, die ich in den letzten Monaten fertiggestellt habe: Wüst ballernde Gegner, die Animation des zerstörten Spielerschiffes, das neue Cheatmenü, Geschwindigkeitswarnungen, herumfliegende Waren, schiffbrüchige Piraten, echte Highscore, Kontoabrechnungen, die Kurzanleitung, einen echten Pausemodus, das Anhalten der Game-Engine (mit TOS-Bomben), und dass man Soundeffekte, Ingame-Musik und Partikeleffekte jederzeit ein- und ausschalten kann. An den wichtigen Stellen im Video habe ich Kommentare eingeblendet, damit man nichts verpasst. Auch ist das Video mit seinen stolzen zehn Minuten leider nicht so knapp geraten, wie ich das ursprünglich wollte. Wer seine Zeit als zu kostbar erachtet, dem sei gesagt, dass ab der Hälfte des Videos nicht mehr wirklich viel neues gezeigt wird. Es geht dann nur noch um Details.

Da ich kein Held im Umgang mit Videoschnittsoftware bin, habe ich das Video relativ schnell zusammengeklickt, ohne Rücksicht auf qualitativ hohe Ansprüche. Es ist nur eine kleine Demonstration des aktuellen Entwicklungsstands. Kommentare sind gern gesehen und Fragen jederzeit gestattet. Die Projektseite des Spiels werde ich in Kürze aktualisieren.

Das nächste Preview-Video wird es frühestens wieder in einem Jahr geben, da ich, wie bereits erwähnt, vorerst nicht mehr dazu kommen werde, neue Features umzusetzen. Aber es geht definitiv weiter.

(*) Nachtrag: Jetzt ist die Qualität des Videos auf einmal besser geworden, dabei habe ich nichts verändert. YouTube stinkt manchmal einfach, dagegen kann man wenig machen. Die verteilen wohl hin und wieder einen Stream mit schlechterer Qualität, wenn die Bandbreite als zu gering eingeschätzt wird.