Beiträge mit tag "Oracle

Oracle Certified Professional, Java SE 7 Programmer

2

Eine gesunde Portion Selbstbeweihräucherung ist wohl nötig, nach dem Lern-Martyrium der vergangenen Wochen: Seit Donnerstag bin ich offiziell ein von Oracle zertifizierter professioneller(!) Java-Programmierer – endlich! Die hierzu nötige zweieinhalbstündige, umgerechnet 215 Euro teure Prüfung habe ich mit sagenhaften 91% glorreich bestanden. Zum Bestehen waren 65% richtige Antworten unter den insgesamt 65 Fragen nötig. Seit geschlagenen vier Jahren schon prokrastiniere ich dieses Thema vor mir her, weil ich genau wusste, was für ein Kraftakt das werden würde. Doch nun habe ich Nägel mit objektorientierten Köpfen gemacht. Ab jetzt bin ich nachweislich ein echter Java-Profi.

Wo die Vorgängerzertifizierung zum OCAJP meist noch ganz essentielle Sprachmechanismen, Konstruktoren, Operatoren, primitive Datentypen und Objekte und ihre Relationen zueinander, Vererbungshierarchien uvm. behandelt, besteht der OCPJP schon zum größten Teil daraus, dass man die halbe Java API auswendig kennen muss. Man sollte wissen welche Klassen und Methoden es gibt, in welchen Packages sie liegen, die dazugehörigen Parameterlisten, Rückgabetypen, welche Checked Exceptions diese werfen können, und das alles zu solch umfangreichen Themengebieten wie Collections/Generics, JDBC, Threads/Concurrency, Input-/OutputStreams, File IO/NIO.2, String-Verarbeitung und diverse andere. Außerdem werden einige Basis-Entwurfsmuster, Abstraktion und professionelles Klassendesign mit allen Fallen und Schikanen thematisiert, was alleine schon Stoff für eine ganze Prüfung gewesen wäre.

Bei allem Stolz auf das tolle Ergebnis, kam es für mich doch eher unerwartet, denn die schiere Menge an Themen, die man für die Prüfung vollständig verinnerlicht haben sollte, konnte einen schon sehr leicht erschlagen. Mein Prüfungsvorbereitungsbuch umfasst knapp 800 Seiten, dazu habe ich gleich zwei offizielle Online-Trainings von Oracle mitgemacht. Insgesamt fand ich den Lernaufwand mit grob geschätzt etwa 90 Nettostunden für meine Verhältnisse bereits enorm – und das obwohl laut Buch 200 Stunden empfohlen werden. Die offiziellen Oracle-Trainings grenzen meiner Meinung nach an Betrug, so behandeln sie nur einen Bruchteil des abgefragten Wissens, und selbst das auch nur oberflächlich, und kosten dazu noch unverschämt viel Geld. Hätte ich mich direkt nach dem Online-Training gutgläubig in die Prüfung gesetzt, wäre ich chancenlos durchgefallen.

Das Buch war schon deutlich hilfreicher, aber dazu musste man den fetten Wälzer erst einmal komplett gelesen haben, was mir schwerfiel. Das Werk scheint zwar bekannt und anerkannt zu sein, jedoch ist es – besonders in der zweiten Hälfte – voller Fehler. Offenbar hatte die Autorin keine Lust mehr, oder hat die Themen selbst nur noch so halb verstanden, über die sie schreiben sollte. Jedenfalls sind nicht wenige ihrer Antworten auf ihre eigenen Übungsfragen schlichtweg falsch, die Aufgaben mitunter fahrlässig missverständlich formuliert, oder sie lässt wichtige Fakten aus den Kapiteln einfach raus, um den Leser dann gezielt bei den darauf folgenden Übungsfragen auf die Schnauze fallen zu lassen. Am Ende habe ich mich über das Buch nur noch geärgert. Trotzdem war es allemal eine passable Vorbereitungsgrundlage.

Schließlich habe ich noch vier unabhängige Mock Exams (mit Erklärungen) absolviert, und ich bin sicher, diese haben mein Prüfungsergebnis am stärksten beeinflusst. Zunächst war ich über den sehr hohen Schwierigkeitsgrad entsetzt, und gleich unter den ersten paar Fragen waren Themen, von denen ich bisher noch nie gehört hatte, wo ich eigentlich nur raten konnte. Allerdings bestätigte mir das Ergebnis am Ende doch, dass es zum Bestehen locker reichen sollte. Dadurch lernte ich, was denn so die typischen Fragestellungen sind, und konnte bei meinen falschen Antworten auch gleich sehen, wo der Fehler lag. Die eigentliche Prüfung kam mir schließlich sogar irgendwie einfacher vor als die Mock Exams – was aber auch daran liegen könnte, dass ich alle Aufgabentypen und die häufigsten Fehler schon kannte, und oft wusste, auf welche Details ich besonders achten musste.

Dummerweise habe ich mir ausgerechnet in der Prüfungswoche die für 2018 längst überfällige Herbst-Erkältung eingefangen, so dass ich, statt mich mit einer Wärmflasche ins Bett zu legen, leider mit Halsschmerzen, dröhnendem Schädel, Triefnase und Husten die Java API pauken und dann sogar die Prüfung mit Handicap ablegen musste. Hätte ich die Prüfung denn nicht kurzfristig verschieben können? Nur theoretisch. Leider war das keine praktikable Option, schon da mein Zertifizierungspfad von Oracle nach Ablauf des Jahres nicht mehr angeboten wird. Hätte ich im Dezember keinen Prüfungstermin mehr bekommen, auf Grund welcher Umstände auch immer, dann hätte ich den OCPJP nicht mehr machen können. Dann hätte ich mit dem OCA Java 8 wieder von vorne anfangen müssen. So gesehen habe ich das Zertifikat also quasi in letzter Minute erlangt.

Ich bin sehr froh, dass das Thema hiermit ein erfolgreiches Ende hat, und ich fürchte, ich kann jetzt erst einmal kein Java mehr sehen. Das war einfach zuviel des Guten. Ist ja zum Glück auch bald Weihnachten, Zeit, mich auf meinen Lorbeeren auszuruhen, und vor allem mich auszukurieren. Und so schnell folgt nun keine nächsthöhere Zertifizierung, was auch gut so ist. Obwohl … ich KÖNNTE natürlich irgendwann die Upgrade-Zertifizierung für Java 8 machen. Naja… nein. Lieber nicht.

Java Toolkit-Sync verschluckt Interrupted-Flag

3

Da mir im Moment der Sinn nicht ganz nach irgendeinem Politikum steht, worüber ich meinen Senf ausgießen müsste, werde ich vorerst noch mehr Softwareentwickler-Kram posten, mit dem ich die geneigten, aber uninteressierten Leser erfolgreich abschrecken kann. Wir danken für Ihr Verständnis.

Wer sich im Internet gezielt über aktives Rendering mittels Canvas in Java informiert, also etwas, das direkt im Zusammenhang mit Java-Spieleentwicklung steht, der wird wahrscheinlich irgendwann über die Methode sync() in java.awt.Toolkit stolpern, also meistens in der Form Toolkit.getDefaultToolkit().sync(). Nun gehe ich stark davon aus, dass die meisten Entwickler diese Codeschnipsel als gegeben ansehen und 1:1 in ihre eigene Klasse einfügen, da sie wahrscheinlich vielfach erprobt sind. So war das bei mir anfangs leider auch. In einem eigenen Render-Thread habe ich Bilder gerendert und anschließend brav das Toolkit „synchronisiert“, was laut Dokumentation irgendwie „gut für Animationen“ ist.

Seit der Umstellung auf aktives Rendering jedoch hatte ich plötzlich Schwierigkeiten damit, den Render-Thread mittels interrupt() vorzeitig zu stoppen, also etwa wenn der Nutzer das Rendering über das Menü beendet oder wenn ein bestimmtes Ereignis auftritt. Zuvor war das nie ein Problem gewesen. Neuerdings läuft der Thread in drei von vier Fällen einfach weiter, sobald ich ihn gezielt unterbrechen will. Das war eine mittlere Katastrophe, denn ich konnte mich jetzt nicht mehr darauf verlassen, dass das Programm das macht, was ich davon erwartete. Mein Programm funktionierte so nicht mehr, und ich wusste nicht, was ich falsch gemacht haben könnte.

Etwa einen halben Tag hat es gedauert, bis ich den Fehler gefunden hatte: java.awt.Toolkit.sync() verschluckt ganz frech das Interrupted-Flag. Es scheint leider wirklich so zu sein. Die Implementation der Java Virtual Machine von Oracle ist hier offenbar fehlerhaft, denn alles funktioniert einwandfrei wenn ich auf sync() verzichte. Sobald ich die Zeile verwende, klappt das Unterbrechen des Threads nicht mehr. Meine Vermutung ist daher, dass das blockierende sync() das Interrupted-Flag mittels interrupted() abfragt (und dadurch löscht!), und dann leider nicht mehr setzt und leider auch keine Exception wirft. Es verschluckt die Thread-Unterbrechung völlig. So wird dieser Mechanismus sogar ganz offiziell in der Java-Doku erklärt:

if (Thread.interrupted()) // Clears interrupted status!

Nun hält sich Oracle selbst nicht daran. Ich habe anschließend in meinem Code keine Möglichkeit mehr, diese Unterbrechung zu erkennen und gegebenenfalls selbst eine InterruptedException auszulösen. Oracle hat hier eindeutig Scheiße gebaut, denn eigentlich ist das Konsens, das Interrupted-Flag nach dem Löschen erneut zu setzen, damit die Unterbrechung nach oben eskaliert werden kann, so dass auch andere Programmteile auf die Unterbrechung korrekt reagieren können. Hier wurde ganz einfach geschlampt.

Und was macht sync() eigentlich? Tja, keine Ahnung. So ganz scheint das nämlich niemand zu wissen. Ich liebe es, wenn die Java-Dokumentation von Oracle so explizit ist, dass man trotzdem keine Ahnung hat, was genau vor sich geht. So auch zur Methode sync() der Klasse Toolkit:

void java.awt.Toolkit.sync()

Synchronizes this toolkit’s graphics state. Some window systems may do buffering of graphics events.

This method ensures that the display is up-to-date. It is useful for animation.

Wenn jemand mal im Internet in einschlägigen Entwicklerforen versucht danach zu fragen, was das genau bedeutet, wird die Frage mit „synchronizes the graphics state“ „beantwortet“, und anschließend als Off-Topic geschlossen. Zurecht wurde wenigstens noch darauf hingewiesen, dass das die Frage kaum beantwortet.

Da ich weder sagen kann, was die Methode macht, in welchen Fällen ich sie brauchen könnte, und welche Vorteile oder Nachteile damit zusammenhängen, werde ich auf sync() gerne verzichten, schon da ich mit dem Interrupt-Problem einen ziemlich schwerwiegenden Fehler entdeckt habe, den ich nicht bereit bin zu akzeptieren – ganz egal wie toll die Funktion ansonsten arbeiten möge.

Oracle Certified Associate, Java SE 7 Programmer

14

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.

Club der anonymen Java-Programmierer

0

javaappletGerade kürzlich dachte ich so bei mir: Warum eigentlich nicht mal wieder einen Java-Artikel schreiben? Die Zeit ist reif dafür. Oracle bringt es mit seiner Intransparenz und seiner faulen Update-Politik offenbar noch fertig, Java komplett in den Ruin zu reiten. In der Öffentlichkeit hatte Java nie einen schlechteren Stand. Dass inzwischen selbst JavaScript ein sehr viel besseres Ansehen als Java genießt, das ist wirklich ein großes Armutszeugnis, das ich Oracle ausstellen muss. Wir erinnern uns an das Jahr 1997: JavaScript war ursprünglich diese nervige Browserspielerei, mit der man den Rechtsklick unterbinden und die Statusleiste im Internet Explorer für blöde Laufschriften missbrauchen konnte.

Java hat bestimmt so einige kleine Problemchen, aber im Moment wird zu Unrecht geschimpft. Das miese Browser-Plugin ist es, das ständig mit neuen Sicherheitslücken negativ in die Schlagzeilen gerät. Dennoch hagelt es jetzt Kommentare in der Art wie: „Java gehört in den Sondermüll und ich kann nur jedem raten, es zu deinstallieren!“. Die Probleme waren kürzlich scheinbar sogar so gravierend, dass das Bundesamt für Sicherheit in der Informationstechnik (BSI) in diesem Drama unbedingt mitspielen wollte und fortan ebenfalls jedem empfiehlt, bloß schnell Java loszuwerden. In meinen Augen allerdings eine ziemlich peinliche Äußerung, die mir beweist, dass der Laden dort auch nur von den üblichen Internetausdruckern geführt wird, die keine Fachkompetenz besitzen. Das ist wie als würde man ständig empfehlen, Windows zu deinstallieren, wenn im Internet Explorer mal wieder eine Sicherheitslücke offengelegt wurde. Das ist mit Kanonen auf Spatzen schießen.

Natürlich würde dort NIE jemand empfehlen, Windows zu deinstallieren. Warum eigentlich nicht? Und wenn wir schon bei Sicherheitslücken sind, wieso empfiehlt das BSI nicht ausnahmsweise was Sinnvolles, z.B. solchen fahrlässigen Mist wie WhatsApp zu deinstallieren, wegen der ganzen Sicherheitslücken, wegen dem komplett unverschlüsselten Traffic, und wegen dem fragwürdigen Datenschutz beim Versenden des kompletten Adressbuches? Aber das ist wohl eine andere Geschichte.

Nichtsdestotrotz hat Java dadurch wieder einen spürbaren Imageschaden abbekommen. Witzigerweise wird Java immer nur dann verteidigt, wenn jemand Minecraft erwähnt. DAS ist so ziemlich der ultimative Beweis dafür, dass es Java schlecht geht: Wenn ein mäßiges aber weitverbreitetes Indie-Spiel so ziemlich das Einzige ist, womit man noch zeigen kann, dass Java manchmal auch ein bisschen toll sein kann. Mich als Java-Entwickler stört das natürlich schon ein wenig, weil Java eigentlich sehr vielseitig und extrem nützlich ist, wenn man platformunabhängig entwickeln möchte. Programmieren in Java macht einfach Spaß und Probleme habe ich damit auch keine.

Nun wollte ich eigentlich einen Beitrag über einen winzig kleinen Fehler in Java schreiben, der mir kürzlich aufgefallen ist, aber ich glaube wenn Java im Moment etwas am wenigsten gebrauchen kann, dann sind das noch mehr Nörgler. Stattdessen werde ich mich mit diesem Beitrag einfach öffentlich solidarisch zu Java bekennen. Ich bin gerne Java-Programmierer und ich würde es am liebsten noch eine Weile bleiben. Es gibt nichts zu bereuen.

nach oben