Beiträge mit tag "Java

spacolabooks_sidebar

SPACOLA Eclipse WIP 0.33 – Eine explosive Version

0

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 small 200x125Leider 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.

Java

Kleines Quellcode-Gruselkabinett

0

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.

HashMap<String, HashMap<Integer, ArrayList<String>>> listForAllSystems;

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.

if(isExceptionThrown =! false){

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.

if (someObject.equals(null))
    throw new NullPointerException();

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

spacolabooks_sidebar

SPACOLA Eclipse WIP 0.29 Preview-Video

0

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.

Windows

Manchmal ist Windows eben doch großer Mist

4

Alles trieft, alles klebt, die Affenhitze hat Deutschland fest im Griff, und wochenlang gibt es keinen einzigen Tropfen Regen, der die Qual ein wenig lindern würde. Während ich bei bestimmt 40 Grad unterm Dach vor mich hin transpiriere und es seit letztem Monat kaum terminfreie Tage gab, versuche ich im Umzugsstress meinen Blog nicht komplett zu vernachlässigen, auch wenn ich dafür nur noch zwischen Tür und Angel mal die Möglichkeit habe. Aber es kommen wieder bessere Tage, dafür garantiere ich. Die Gelegenheit ist günstig für einen Füllbeitrag zum Thema “Warum Windows manchmal eben doch großer Mist ist”. Hier habe ich zwei skurrile Dinge gesammelt, die mir beim Arbeiten (oder Zocken) mit Windows sinnlos Probleme bereitet haben.

Fangen wir mit dem größten Übel an: Ein Problem mit Windows Server 2003, das scheinbar schon so manchem die Schuhe beim Gedanken daran auszieht. Ich wollte einen gerade unter Windows laufenden Java-Prozess mit Hilfe des Tools jstack.exe untersuchen. Üblicherweise ist das gar kein Problem, man muss eben nur Process-ID wissen, und die erfährt man mit dem tollen Windows-Befehl tasklist. Soweit alles noch in Ordnung. Als ich dann aber jstack mit besagtem Parameter ausführen wollte, erhielt ich diese völlig nichtssagende weil absurd falsche Fehlermeldung: “Not enough storage is available to process this command.” (im deutschen Windows “Nicht genügend Server-Speicherplatz verfügbar, um diesen Befehl zu verarbeiten“).

Einwandfrei. Nicht genügend Arbeitsspeicher bzw. Swap-Speicher für die winzige jstack.exe auf einem eigentlich gut ausgestatteten Windows-Server? Nein, ich glaube eher nicht. Aber danke für deine unbrauchbare Hilfe, Windows! Ich fand eine Microsoft-Hilfeseite, die versucht das Problem näher zu erläutern und Problemlösungen zu bieten. Mit Betonung auf “versucht”, weil Microsoft grandios daran scheitert, denn schon die Fehlermeldung an sich ist einfach Quatsch. Auch eine deutsche Hilfeseite führte mit ihren Anweisungen nur komplett in die Irre.

Zum Glück kannte jemand auf Stackoverflow.com die Lösung. Man muss jstack mit Hilfe von “psexec -s jstack.exe pid” aufrufen, damit es richtig auf dem Zielrechner ausgeführt wird. Das hat also genau gar nichts mit zuwenig Speicherplatz o.ä. zu tun, wie Windows mir weismachen wollte. Wenn man noch nicht einmal die richtige Fehlermeldung angezeigt bekommt, wenn schon ein Fehler auftritt, dann weiß ich nicht, worauf ich mich bei Windows sonst noch verlassen können soll.

Das zweite Problem ist dagegen ein eher kleines, kürzlich entdeckt und gelöst auf einer LAN-Party, also einem gesellschaftlichen Event zum gemeinschaftlichen Zocken netzwerkfähiger Windows-Spiele. Besonders nervtötend ist es, wenn das Windows-Netzwerk an sich fehlerfrei eingerichtet ist, es aber dennoch vereinzelt Spiele gibt, in denen immer derselbe LAN-Teilnehmer (=ich) die Spiele der anderen nicht sehen kann, und umgekehrt. Die Liste in der Lobby ist leer, obwohl alle anderen bereits dem offenen Spiel beigetreten sind. Man sucht sich also einen Wolf, auf der Suche nach dem einen Fehler, der dafür sorgt, dass man in manchen Spielen für alle anderen unsichtbar ist. Die Fehlersuche wird allein dadurch erschwert, dass das Problem nur manche Spiele betrifft, und auch dann noch nicht einmal immer.

lanadapterDas Problem wäre natürlich gar keines, wenn man in solchen Spielen einfach eine Ziel-IP zum Verbinden eingeben könnte, aber so einfach machen es einem die Entwickler nicht. Könnte womöglich manche Spieler überfordern. Des Rätsels Lösung lag dann in der Existenz weiterer LAN-Adapter, die unter Windows installiert waren: darunter der VirtualBox-LAN-Adapter, Tunngle, bei anderen findet man dort etwa Hamachi oder VMware. Alle diese Adapter müssten – auch wenn sie im Moment nicht benutzt werden – explizit deaktiviert werden, weil die Spiele sonst in Versuchung kommen könnten, diese für die Netzwerkverbindung mit den anderen Spielern zu verwenden, anstelle des eigentlich höher priorisierten richtigen LAN-Adapters.

Java

Java-Kram: Nächstmöglicher Zeitpunkt zu fester Uhrzeit

0

Willkommen zu meinem nächsten Beitrag direkt aus meinem Fundus merkwürdiger Java-Lösungen für nicht ganz so alltägliche Programmierprobleme. Normalerweise würde ich meine kreativen Fehltritte sicher NIE veröffentlichen, aber dieses Mal mache ich noch eine Ausnahme, da ich glaube, es könnte den einen oder anderen auf die richtige Spur bringen, wenn er nicht weiter weiß.

Kürzlich war ich dabei, einen kleinen Indexer für dies und das zu schreiben, der einmal am Tag zu einer bestimmten Tageszeit Datensätze aus einer Datenbank zieht. Wofür genau spielt hier natürlich keine Rolle. Jedenfalls wollte ich dafür einen TimerTask verwenden, und der wird beispielsweise mit einem Delay (Verzögerung in Millisekunden bis zum ersten Start), und einem Intervall (Verzögerung in Millisekunden für alle darauffolgenden Starts) gefüttert. Randbedingung war, dass der Indexer einmal am Tag um dieselbe Uhrzeit läuft. Diese Uhrzeit soll man hinterlegen können. Den TimerTask-Kram habe ich weggelassen, und den eigentlichen Indexer-Code auch, um das Beispiel möglichst auf das Essentielle zu reduzieren.

Mein Problem war nämlich, dass ich auf Anhieb nicht wusste, wie ich herausfinden könnte, wann der nächstmögliche Zeitpunkt für eine festgelegte Uhrzeit ist, also ob beispielsweise 14:30 Uhr noch am selben Tag ist, oder erst am darauffolgenden Tag. Wieviele Millisekunden muss ich als Verzögerung des initialen Starts angeben, damit der Indexer zur nächsten Gelegenheit um eine bestimmte Uhrzeit losläuft?

public int[] timeToNextIndexTask(){
		
	int indexHour = 14;
	int indexMinute = 30;
		
	GregorianCalendar now = new GregorianCalendar();
		
	boolean carryHour = false;
		
	int hourOfTheDay = now.get(Calendar.HOUR_OF_DAY);
	int minuteOfTheDay = now.get(Calendar.MINUTE);

	int hoursUntil = hourOfTheDay - indexHour;
	int minutesUntil = indexMinute - minuteOfTheDay;

	if(minutesUntil < 0){
		carryHour = true;
		minutesUntil = 60 + minutesUntil;
	}
		
	// Next scheduled index still today?
	if(hoursUntil < 0)
		hoursUntil = Math.abs(hoursUntil);
	// Next scheduled index tomorrow?
	else if(hoursUntil >= 0)
		hoursUntil = 24 - hoursUntil;
		
	// Remove one hour if there are minutes left to the hour
	if(carryHour)
		hoursUntil--;
		
	if(minutesUntil != 0 && hoursUntil == 24)
		hoursUntil = 0;
		
	return new int[]{hoursUntil, minutesUntil};

}

Nach einer Weile habe ich mir die obige Lösung für mein simples Problem auserdacht. Die Methode timeToNextIndexTask() gibt einen int-Array zurück, der die Zeit in Stunden und Minuten beinhaltet. Das lässt sich ohne Schwierigkeiten in Millisekunden umrechnen.

Aber wie das so ist, fällt einem schon kurze Zeit später auf, wie sinnlos man sich den Kopf darüber zerbrochen hat, und dass diese Lösung zwar funktioniert, aber eigentlich viel zu aufwändig und der Code ziemlich wackelig ist. Meine Frage lässt sich mit zwei GregorianCalendar-Objekten sehr einfach beantworten:

public int[] timeToNextIndexTask(){
	
	long minuteMilliseconds = 60 * 1000;
	long hourMilliseconds = minuteMilliseconds * 60;
		
	int indexHour = 14;
	int indexMinute = 30;
		
	GregorianCalendar now = new GregorianCalendar();
	GregorianCalendar nextTime = new GregorianCalendar();
	nextTime.set(Calendar.HOUR_OF_DAY, indexHour);
	nextTime.set(Calendar.MINUTE, indexMinute);
		
	if(now.after(nextTime))
		nextTime.add(Calendar.DAY_OF_MONTH, 1);
		
	long millisecondDiff = nextTime.getTimeInMillis() - now.getTimeInMillis();
		
	int hoursUntil = (int) (millisecondDiff / hourMilliseconds);
	millisecondDiff -= hoursUntil * hourMilliseconds;
	int minutesUntil = (int) (millisecondDiff / minuteMilliseconds);
		
	return new int[]{hoursUntil, minutesUntil};
		
}

Kurzgesagt, man legt einen GregorianCalender für den aktuellen Zeitpunkt an, und verstellt einfach die Uhrzeit, behält das Datum jedoch bei. Nun muss man lediglich mit Hilfe der Methode after() bzw. before() vergleichen, ob das verstellte Calendar-Objekt in der Vergangenheit oder in der Zukunft liegt. Falls es in der Vergangenheit liegt, muss man einen Tag dazuzählen, und schon hat man seinen gewünschten Zeitpunkt.

Java

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.

Java

Not so weekly rant: Wieso läuft die JVM nicht?

0

Ich weiß nicht ob das typisch für mich ist, dass ich das neue Jahr mit einem Rant einleite, aber zeitlich ist es jedenfalls nicht beabsichtigt. Ich wasche meine Hände in Unschuld. Zunächst also ein frohes neues Jahr. Die tollen, freundlichen Beiträge kommen alle noch die Tage. Wieder einmal habe ich die Hoffnung, dass dieser Artikel all jenen hilft, die mit einem ähnlichen Problem konfrontiert werden. Das Programmiererleben ist sicherlich vieles, aber gewiss nicht einfach.

Vergangene Woche war ich in der Situation eine portable Version einer Solaris JVM (Java Virtual Machine) aktualisieren zu dürfen. Die bisherige Version des JDK6 war leider veraltet und brachte regelmäßig Segmentation Faults im Dauerbetrieb zustande. Ein neueres Update (1.6.0 Update 38) sollte hoffentlich stabiler laufen. Mit einer portablen Version ist eine Java-Installation gemeint, die man einfach auf dem Zielsystem in ein Verzeichnis seiner Wahl entpackt und die sofort (und vor allem ohne betriebssystemabhängige Installation) lauffähig ist. Aus diesem Grund wollte ich mir eine solche Version von Oracle herunterladen. Das war aber schon das erste Problem: Oracle ist nämlich ziemlich scheiße.

Oracle bietet (jedenfalls für Java 6) keine portablen JDKs zum Entpacken an – nur Installer. Da ich auf dem Zielsystem aber keine Installationsprogramme ausführen kann/darf/will, ist das selbstverständlich keine Alternative, zumal ich ja wusste, dass Java problemlos portabel ausführbar ist. Eine Installation ist daher gar nicht nötig. Kurzerhand musste ich also kreativ werden und basteln. Ich wollte den doofen Installer umgehen und die Dateien von Hand extrahieren. Das war gar nicht so schwierig wie ich dachte. Mein Werk wollte ich im Vorbeigehen kurz an einer Client-Anwendung testen, als beim Starten der JVM eine wilde Fehlermeldung erschien:

Error occurred during initialization of VM
java/lang/NoClassDefFoundError: java/lang/Object

Soso, sehr interessant. Die JVM kann die Klasse java.lang.Object nicht finden. Wenn diese Klasse fehlt, dann fehlt praktisch alles. Ein freundliches Google teilte mir mit, dass es vermutlich mit einer fehlenden Datei rt.jar im Verzeichnis /jre/lib/ zusammenhängt. Tatsächlich, diese Datei gab es dort nicht. Ist Oracle wirklich so bescheuert und liefert ein unvollständiges, nicht lauffähiges JDK aus? Ist das die Strafe dafür, dass ich den Installer übergangen habe?

Ist es. Denn der Installer hat zudem die Aufgabe, die rt.jar aus einer gepackten Datei namens rt.pack auszupacken, und diverse weitere Dateien:

./lib/tools.pack
./jre/lib/charsets.pack
./jre/lib/jsse.pack
./jre/lib/deploy.pack
./jre/lib/javaws.pack
./jre/lib/plugin.pack
./jre/lib/rt.pack
./jre/lib/ext/localedata.pack

Warum das so ist, weiß nur der Teufel. Platzersparnis bringt es gegenüber dem umliegenden Archiv keine. Es ist wahrscheinlich reine Schikane. Manche behaupten auch, das wäre ein Mechanismus, um sicherzustellen, dass niemand den Installer umgeht, da dieser ja zum Akzeptieren der AGB auffordert. Zum Glück gibt es die mitgelieferten Java-Tools pack200 und unpack200. Mit deren Hilfe kann man die JAR-Dateien aus den PACK-Dateien befreien – sogar über verschiedene Betriebssysteme hinweg. Und dann klappt das auch wieder mit der JVM.

Seit diesem Tag hasse ich Oracle wieder ein bisschen mehr, und ich bin ein bisschen weiser geworden. In meinen Augen eine echte Schweinerei. Portable Versionen sind super und hinterlassen weniger Spuren. Wenn man weiß was man tut, und wenn man in der Lage ist, sich selbst um die richtigen Pfadangaben zu kümmern, dann hat ein portables Java viele Vorteile, vor allem wenn man viele homogene Systeme unter seiner Obhut hat.

Quellen:
http://www.cynosurex.com/Forums/DisplayComments.php?file=Java/Finding_rt.jar_in_JRE_5.0_Update_9
http://tntit.blogspot.de/2012/04/linux-jdk-6-installation-hard-way.html
http://turbolinux.org/2011/05/error-occurred-during-initialization-of-vm-javalangnoclassdeffounderror-javalangobject/
http://stackoverflow.com/questions/1619662/where-can-i-get-the-latest-jre-jdk-as-a-zip-file-i-mean-no-exe-installer

spacolabooks_sidebar

Spacola Eclipse v0.21 Video Preview

0

Es lebt! Spacola Eclipse ist zwar noch lange nicht fertig, aber ich habe den ersten Meilenstein erreicht: Der erste Gegnertyp fliegt im Spiel herum und man kann schon jede Menge Zeug kaputtballern. Die Gegner können sich zwar noch nicht richtig wehren, aber immerhin nerven sie schon gewaltig. Zur Feier der neuen WIP-Version 0.21 gibt es heute die ersten Preview-Videos, also vollständig bewegte Eindrücke des Spiels. Ich habe endlich eine Desktop-Capture-Software gefunden, die nicht nutzloser Shareware-Müll ist und sogar halbwegs flüssige Bewegungen UND Sound aufnehmen kann.

Das erste Video zeigt das Gameplay des Remakes. Das Intro wird hierzu natürlich abgebrochen. Die schlechte Bildqualität und die ruckelige Grafik bitte ich zu entschuldigen. Das Capture-Programm ist zwar gut, aber leider trotzdem nicht optimal. Der stark verlustbehaftete YouTube-Codec tut dann sein übriges. Das Spiel läuft vollständig flüssig bei (künstlich limitierten) 52 fps und verbraucht nur sehr wenige Ressourcen.

Das zweite Video ist nun naturgemäß nicht so spannend. Es soll im Grunde eigentlich nur zeigen, wie genau ich das Original-Intro in meinem Remake imitiert habe, da ich alles, so weit es mir möglich ist, pixelidentisch halten will. Das Spiel im Demo-Modus würde dann also bisher folgendermaßen aussehen:

Für Späteinsteiger: Spacola Eclipse ist mein kleines Java-Remake (bzw. im Moment eher: Re-Implementation) des Atari ST-Spiels SPACOLA, das 1991 von Dongleware veröffentlicht wurde. Das Ziel ist eine (zunächst) möglichst exakte Nachbildung des Originals für viele moderne Platformen (Windows, Mac OS, Linux, iOS, Android) und in zweiter Instanz die Erweiterung des Spiels um bessere Grafiken, neue Sounds, einen Mehrspielermodus und neue sinnvolle Features.

Java

ConcurrentModificationException bei remove()

0

Bevor ich wieder in einen monatelangen Java-Beitrags-Winterschlaf falle und erneut nur über TV-Serien und alte Spiele schreibe, möchte ich hier noch einen kleinen Anfängertipp geben. Wieso eigentlich? Ganz einfach weil ich in letzter Zeit so einigen ungeübten Java-Programmierern über die Schulter sehen durfte, die alle völlig unvorbereitet in die im Folgenden thematisierte Falle tappen. Scheinbar ist Java in dieser Hinsicht wirklich so unintuitiv, dass es jedem am Anfang passiert, und ich erinnere mich, dass es mir im Studium genauso erging. Ich erkannte das Problem recht schnell und hatte auch sofort eine Lösung parat, die ich seitdem schon ganz automatisch verwende, aber vielleicht fällt das nicht jedem so leicht.

Die Situation ist schnell erklärt: Mittels Zählschleife soll über eine Collection, eine Liste, iteriert werden, die irgendwelche Elemente enthält. Diese erweiterte For-Schleife dient dazu, nicht benötigte Elemente aus der Collection zu entfernen, also eine Art Filterung soll vorgenommen werden. Am Ende verbleiben nur solche Elemente in der Collection, mit denen wir weiterarbeiten wollen. Aus Gründen der Einfachheit sind das in diesem Fall keine komplexen Datentypen, sondern Strings:

List<String> myList = new ArrayList<String>();

// Liste befüllen

for(String curString : myList){
	if(curString.contains("unavailable"))
		myList.remove(curString);                // Bloß nicht!
}

Sieht einfach aus, ist es aber dann doch nicht. Der Code produziert nämlich eine ConcurrentModificationException. Diese Exception ist eigentlich dazu da, zu verhindern, dass eine Collection zeitgleich modifiziert wird, während gerade (z.B. in einem anderen Thread) darüber iteriert wird. Wie man sieht, braucht es allerdings gar keine anderen Threads, um die Exception zu provozieren. Wir dürfen nicht gleichzeitig iterieren und Elemente einfügen oder entfernen. Was kann ich also sonst tun, damit ich meine Elemente wegbekomme?

Eine naheliegende Lösung ist, sich die entsprechenden Elemente einfach bis dahin zu “merken”, um sie erst nach dem Iterieren zu entfernen. Alternativ könnte man sich aber auch nur die Elemente merken, die man behalten möchte, und dabei einfach eine neue Liste generieren. Welche der beiden Methoden nun besser ist, hängt davon ab, ob nach dem Entfernen mehr Elemente zurückbleiben als entfernt werden. Sowas lässt sich aber natürlich nicht immer abschätzen, darum verwende ich meistens pauschal die subtraktive Variante:

List<String> myList = new ArrayList<String>();
List<String> myDeleteList = new ArrayList<String>();

// Liste befüllen

for(String curString : myList){
	if(curString.contains("unavailable"))
		myDeleteList.add(curString);
}

myList.removeAll(myDeleteList);                // Schon besser

Mit der Methode removeAll() gibt es sogar gleich das ideale Werkzeug für solche Operationen. Ich benötige diesen und ähnlichen Code bei meiner Arbeit immer mal wieder. Erfahrene Java-Entwickler wissen natürlich, dass man in solchen Fällen am besten gleich einen richtigen Iterator verwendet, weil man mit diesem auf sichere Weise Elemente beim Iterieren entfernen kann. Ich bin allerdings auch gleichzeitig ein Fan der leicht verwendbaren For-Each-Schleifen, daher bin ich da meist ein wenig im Konflikt. Ist meiner Meinung nach aber auch alles kein Problem, solange man weiß, wie man damit umgehen muss.

Java

Not so weekly rant: import java.muelltonne.JavaSound

0

“Wie bitte? Sound in Java? Wer würde denn so etwas wollen? Und dann wahrscheinlich auch noch 100% plattformunabhängig, ja? Wer Sound in Java haben will, soll wenigstens furchtbar leiden müssen. Also gut, wir machen es! Aber wir machen es so schlecht wie möglich, damit es niemand benutzen will!”

So oder so ähnlich muss das wohl bei Sun geklungen haben, als man sich irgendwann notgedrungen entschloss eine Java Sound API zu entwickeln. Ich kann mir jedenfalls nicht anders erklären, wieso es im Jahr 2012 immer noch nicht möglich ist, anständig mit JavaSound zu arbeiten, wenn es um so simple Dinge wie Ausgabe von z.B. WAVE-Audio geht. Es funktioniert – keine Frage – aber es macht keinen Spaß und es ist eine performancetechnische Katastrophe.

Gestraft ist man vor allen Dingen dann, wenn man sich aus Gründen des Minimalismus und im Sinne der größtmöglichen Platzersparnis entschließt, weitestgehend unabhängig von den bekannten teilweise mehrere Megabyte großen Java-Soundbibliotheken irgendwelcher Fremdanbieter bleiben zu wollen, die vereinzelt scheinbar sogar 3D-Audio in Java realisieren können. Aber sowas wollte ich gar nicht. Ich wollte einfach nur Audiodateien ausgeben ohne zusätzlichen Ballast von irgendwelchen Multimediabibliotheken und Java-Spiele-Komplett-Engines einbinden zu müssen. Ich bräuchte sowieso nur Start, Stopp und einstellbare Loops, mehr nicht. Zum Glück kann das JavaSound alles. Theoretisch.

Man hat die Wahl der Qual zwischen Pest und Cholera. Es gibt java.applet.AudioClip, welches den Vorteil hat, wirklich extrem einfach zu bedienen zu sein. Man kann da gar nichts falsch machen. Leider funktioniert das mit vielen WAVE-Dateien nicht, wenn sie z.B. eine etwas exotischere Samplingfrequenz haben. Auch gibt es Probleme mit sehr kurzen oder sehr langen Audiodateien. Und das Loopen und Abspielen ist mir dann eigentlich doch zu spartanisch. Looppoints wären schon nötig gewesen.

Für so etwas gibt es JavaSound mit javax.sound.sampled.Clip. Funktioniert ähnlich einfach, und bringt gleich die nötigsten Methoden mit, man kann sogar “Vor- und Zurückspulen” und die Anzahl der Loops setzen. Clip leidet allerdings unter einer unglaublich miesen Performance. Das macht sich beim Abspielen eines einzelnen Samples gar nicht bemerkbar, außer man hält den Speicher- und CPU-Verbrauch seiner JVM sehr genau im Auge. Nein, das ganze Ausmaß des Grauens entdeckt man erst, wenn man – wie das z.B. in Spielesoftware recht üblich ist – den selben Clip in sehr kurzen Abständen mehrfach hintereinander abspielt (z.B. Sprung- oder Schieß-Geräusche). Die ganze Anwendung beginnt zu ruckeln, die Sounds werden teilweise verschluckt, manchmal überhaupt nicht abgespielt. Das ist so natürlich nicht akzeptabel. Ich vermute es liegt einfach am nicht unerheblichen Overhead für das Starten und Stoppen der Threads jedes einzelnen Sounds.

Es gab da noch eine weitere Kleinigkeit, die mir die Haare zu Berge stehen ließ. Bei Clip lassen sich zwar bequem die Looppunkte setzen, beim ersten Abspielen mittels loop() scheint es diese aber komplett zu ignorieren. Erst beim zweiten und bei jedem weiteren Mal geht es dann plötzlich wie gewünscht. Ich habe alle erdenklichen Kombinationen versucht, den Audiopuffer geleert, und alle Methoden getestet, die diese Klasse mit sich bringt. Da war nichts zu machen. Ich musste mir schließlich mit einem billigen Workaround behelfen, das Sample zuvor “heimlich” einmal für eine Millisekunde anzuspielen und sofort mit anschließendem Rewind zurücksetzen, damit es dann gleich beim ersten Mal richtig loopt.

JavaSound hat noch soviele Kinderkrankheiten, dass es beinahe schon absurd ist, wenn man bedenkt, wie lange es Java schon gibt. Sogar die deutlich jüngere Dalvik VM unter Android bietet mehr und leistet mehr, ist vor allem sehr viel spielefreundlicher in dieser Hinsicht. Multimedia in Java ist wohl leider noch etwas, das äußerst stiefmütterlich von Sun bzw. Oracle behandelt wird. Okay, dafür gibt es ja wenigstens JavaFX 2.0. Vielleicht taugt das ja für solch verrückte und völlig abwegige Experimente wie Soundausgabe in einer Java-Anwendung.

nach oben