Anmelden
Liebes Tagebuch,
ich kann mich noch wie heute daran erinnern, als mein Lieblingsschokoriegel Raider in Twix umbenannt wurde. Groß war die Aufregung. Würde der Riegel mir nach wie vor so gut schmecken? Würde die Qualität und der Preis stabil bleiben? Und müsste ich nicht eigentlich aus Solidarität zu dem Gewohnten zukünftig mein Leben lang auf seinen Genuss verzichten? Solche und ähnliche Fragen gingen mir damals durch den zugegebenermaßen noch recht jungen Kopf.
Ein ähnliches Gefühl überkam mich nun wieder, als ich heute die Hallen der Oracle-Code-One-Konferenz betrat, welche als "kleine" Schwesterkonferenz der Oracle OpenWorld aktuell in San Francisco stattfindet. Als treuer Fan der JavaOne-Konferenz habe ich die Ankündigung, die Konferenz solle eine neue Ausrichtung und damit – konsequenterweise – auch einen neuen Namen bekommen [1], natürlich als Eklat empfunden. Hatte Oracle denn nicht verstanden, dass sich mit der JavaOne in den letzten 20 Jahren die Konferenz für die Java-Community entwickelt hat? Wollte man dieses jährliche Familientreffen wirklich aus Marketinggründen opfern?
Nach dem ersten Konferenztag bin ich deutlich entspannter. Oracle hat mit der Neuausrichtung eine Evolution und keine Revolution gestartet. Und das ist meiner Ansicht nach auch gut so. Einmal abgesehen von der rein visuellen Umgestaltung, von Java-Blau auf Oracle-Rot, gibt es nach wie vor unzählige Sessions, Workshops und Hand-On Labs zu den unterschiedlichsten Java-Themenfeldern. Zusätzlich wurde das Angebot und somit auch die Auswahl für die Teilnehmer um eine Reihe neuer Themen erweitert: "Modern Web", "Containers, Serverless & Cloud", "Big Data & Data Science" und "Emerging Technologies", um nur einige zu nennen. Eigentlich konnte man all diese Themen auch in den letzten Jahren schon verstreut, in Form einzelner Sessions, in der Konferenzagenda finden. Sie waren bisher nur nicht so präsent vertreten und explizit ausgewiesen wie in diesem Jahr.
Ich habe mich im Laufe der letzten Wochen bewusst mit etlichen Java-Entwicklern über die Neuausrichtung und die Umbenennung der Konferenz unterhalten. Es ist schon interessant zu sehen, dass insbesondere diejenigen, die vor 20 Jahren, mit dem Aufkommen des Java-Hypes, den etablierten Cobol-, Delphi- und C-Communitys mangelnde mentale Flexibilität vorgeworfen haben, heute scheinbar genauso unflexibel reagieren. Die heutige IT-Landschaft und die darin stattfinden Projekte sind deutlich heterogener als noch vor Jahren. Die neu aufgenommenen Themen der Code One sind alles Themen, mit denen heutzutage nahezu jeder Entwickler in seiner täglichen Arbeit in Berührung kommt beziehungsweise kommen sollte. Und wenn nicht, wäre es eventuell an der Zeit zu hinterfragen, ob das eigene Jobumfeld noch zeitgemäß und somit zukunftssicher ist.
Die von einigen geäußerte Befürchtung, die Umbenennung der JavaOne hin zu Oracle Code One wäre als Signal zu verstehen, dass Oracle sich langsam, aber sicher aus der Java-Welt zurückziehe, teile ich nicht. Zum einen verdient Oracle nach wie vor, direkt oder indirekt, sehr gutes Geld mit Java. Zum anderen hängt der Erfolg zu vieler eigener Produkte an Java, als dass man dieses Feld anderen überlassen wollte.
Natürlich ist auch Oracle die Brisanz ihrer eigenen Positionierung zum Thema "The Future of Java" klar. Daher ist es auch nicht verwunderlich, dass die traditionelle Java-Keynote genau unter diesem Motto stand.
George Saab (Vice President of Development, Oracle) und Mark Reinhold (Chief Architect of the Java Platform Group, Oracle) betonten im Rahmen der Keynote mehrfach die große Bedeutung der Programmiersprache Java für die Entwicklergemeinde und ihr eigenes Unternehmen und versicherten, dass Oracle sich auch weiterhin stark für die Weiterentwicklung von Java einsetzen werde. Beide wiesen dabei noch einmal auf das von Oracle im letzten Jahr gegeben Versprechen – "deliver enhancements and innovations more rapidly" – hin und natürlich auch auf die Tatsache, dass Oracle dieses Versprechen durch
auf jeden Fall erfüllt hat.
Natürlich war auf das neu angedachte Supportmodell [3], welches in den letzten Wochen in der Community für einige Aufregung gesorgt hat, ein Thema. Das neue Modell zwingt Nutzer des Oracle JDKs, die keinen Support zahlen wollen, alle sechs Monate zu einem Versionswechsel, da nur die jeweils aktuelle Version frei zur Verfügung steht. Möchte man länger an einer Version festhalten, wird automatisch ein entsprechender Supportvertrag fällig. heise Developer berichtete bereits ausführlich dazu.
Fairerhalber sollte an dieser Stelle erwähnt werden, dass es natürlich jedem Entwickler freisteht, statt des Oracle JDK eine der möglichen Alternativen zu wählen. So hat Oracle laut Reinhold bisher immer alle Features aus dem jeweils aktuellen JDK frühzeitig der Open-Source-Gemeinschaft zur Verfügung gestellt, sodass darauf aufsetzenden Implementierungen, wie OpenJDK, nahezu zeitgleich am Markt erscheinen konnten. "Oracle Java == OpenJDK" oder anders formuliert "Java is still free", so die plakative Formel Reinholds.
Wie geht es nun aber konkret weiter mit dem JDK? Was können wir in den kommenden Versionen an neuen Features erwarten? Auch diese Frage wurde im Rahmen der Keynote von Mark Reinholds beantwortet, indem er unter anderem einige Demos aus den folgenden Projekten präsentierte:
Mit dem Projekt Amber wird das Ziel verfolgt, regelmäßig neue produktivitätssteigernde Java-Features einzuführen. Bisher geliefert wurden "Local-Variable Type Inference" (JEP 268 [7]) in JDK 10 und "Local-Variable Syntax for Lambda Parameters" (JEP 323 [8]) in JDK 11. In der Entwicklung und somit vorgesehen für das kommende JDK 12 befinden sich "Lambda Leftovers" (JEP 302 [9]) und "Pattern Matching" (JEP 305 [10]). Zusätzlich soll es in JDK 12 Previews von "Switch Expressions" (JEP 325 [11]) und "Raw String Literals" (JEP 326 [12]) geben.
Mit dem Projekt Loom soll das aktuelle Thread-Modell um Fibers (User-Mode Threads) erweitert werden. "We want to make concurrency simple(r) again!", so die Kernaussage des Projekts. Während das aktuelle Thread-Modell auf OS Kernel-Threads aufsetzt und somit ein Thread-Wechsel und der zugehörige Context-Switch recht teuer ist, werden Fibers durch die Java VM verwaltet und kommen deutlich "leichtgewichtiger" daher. Projekt Loom ist somit eine direkte Antwort auf heutige Anforderungen an Java-Anwendungen, in denen Concurrency eine zunehmend wichtigere Rolle spielt (siehe auch "Project Loom:Fibers and Continuations for the Java Virtial Machine [13]").
Projekt Panama soll die Verbindung zwischen der Java VM und sprachfremden APIs verbessern und wendet sich somit vor allem an C-Programmierer beziehungsweise die Anbindung ihres Codes. Die Liste der angedachten Features ist relativ umfangreich und reicht von nativen C- bzw. C++-Funktionsaufrufen aus der JVM heraus, über APIs zur Verwaltung nativer Bibliotheken, bis hin zu native-orientierter JIT-Optimierung.
Liebes Tagebuch, mein Fazit für den ersten Tag der JavaOne, ich meine natürlich Oracle Code One, ist durchweg positiv. Es gibt nach wie vor mehr als genug Sessions rund um das Thema Java. Meine Befürchtung, meine Lieblingssprache könnte langsam, aber sicher ins Hintertreffen geraten, ist völlig ungerechtfertigt.
Aber auch beziehungsweise insbesondere die alternativen Tracks sind wirklich interessant. Sie ermöglichen einen wichtigen Blick über den Java-Tellerrand hinaus und geben einem die Chance, sich mit vielen der aktuellen Trendthemen, wie Modern Web, Cloud, Serverless oder Data Analytics, näher auseinanderzusetzen. Mehr dazu aber in meinem nächsten Tagebucheintrag. Morgen ist ja auch noch ein Tag.
URL dieses Artikels:http://www.heise.de/-4200542
Links in diesem Artikel:[1] https://www.heise.de/meldung/Goodbye-JavaOne-Wie-20-Jahre-Geschichte-einfach-wegexpandiert-werden-4029049.html[2] https://www.heise.de/developer/artikel/Der-neue-Releasezyklus-von-Java-4165009.html[3] https://www.heise.de/developer/artikel/Wird-Java-jetzt-kostenpflichtig-4144533.html[4] https://openjdk.java.net/projects/amber/[5] https://openjdk.java.net/projects/loom/[6] https://openjdk.java.net/projects/panama/[7] https://openjdk.java.net/jeps/286[8] https://openjdk.java.net/jeps/323[9] https://openjdk.java.net/jeps/302[10] https://openjdk.java.net/jeps/305[11] https://openjdk.java.net/jeps/325[12] https://openjdk.java.net/jeps/326[13] https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html
Copyright © 2018 Heise Medien
[unable to retrieve full-text content]
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Android feiert 10. Geburtstag und die besten Smartphones 2018 sind fast alle vorgestellt: Zeit für eine Bilanz und einen Blick nach vorne.
Mehr zu:
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Nur noch 20 Sekunden Sauerstoff! Schaffe ich es, die Lebenserhaltung zu reaktivieren? Im Adventure "Deliver Us The Moon" kämpft der letzte Astronaut um sein Leben und um die Rettung der Menschheit.
Das Indie-Adventure Deliver Us The Moon: Fortuna spielt in einer Zukunft, in der die Energiereserven der Erde verbraucht sind. Mittlerweile gibt es eine Siedlung auf dem Mond und eine neue Energiequelle, die den Fortbestand der Menschheit sichern soll. Über ein Energieübertragungsnetz wird die Erde vom Mond aus versorgt – bis eines Tages das Licht ausgeht. Vom Mond kommt kein Lebenszeichen mehr. Und keine Energie.
Jahre nach dem Blackout wagen die wenigen verbliebenen Mitarbeiter der World Space Agency einen verzweifelten Rettungsversuch: Der Spieler schlüpft in die Rolle eines WSA-Astronauten, der mit der letzten verbliebenen Rakete zum Mond fliegen soll mit dem Auftrag: Deliver Us The Moon.
Das Adventure stammt von dem kleinen niederländischen Entwicklerteam KeokeN Interactive [1], die sich 2016 über eine Kickstarter-Kampagne [2] erfolgreich finanziert haben und Ende September 2018 den ersten Teil "Fortuna" des Adventures Deliver Us The Moon auf Steam veröffentlicht haben. Schon 2015 hatten sie in der Indie Arena auf der Gamescom mit der detailreichen Grafik des Spiels für Aufsehen gesorgt. Die ist wirklich sehenswert.
Als erste Aufgabe muss der Spieler die Rakete startklar machen, wobei nur eine Kollegin per Funk einige Anweisungen gibt und vor einem nahenden Staubsturm warnt. Der Sturm ist dann auch dafür verantwortlich, dass der Kontakt mit dem Kontrollraum kurz nach dem Start abbricht. So ist der Astronaut auf sich alleine gestellt. Auf ihn warten zahlreiche Aufgaben wie das Ankoppeln an die Station Kilometer über der Mondoberfläche und die Aktivierung der Lebenserhaltung. Einige Aufgaben lassen sich entspannt erledigen, bei anderen zählt jede Sekunde – meist, weil die Luft knapp wird.
Neben den dringenden Aufgaben muss der Spieler Hinweise auf den Verbleib der Stationsbesatzung und auf die Ursache des Blackouts sammeln. Die Handlung ist – typisch für ein Adventure – linear, hält aber einige Überraschungen bereit. So findet der Spieler im weiteren Verlauf einen kleinen, ASE genannten Roboter als Sidekick.
Das Adventure überzeugt mit seiner sehenswerten Grafik und dichter Atmosphäre, die trotz Monstermangel teilweise an Alien erinnert. Die Energiestation ist in ihrer Dreidimensionalität der ISS nachempfunden. Die Steuerung über die Tastatur lässt sich leider nicht ändern – bei der Bewegung in Schwerelosigkeit helfen abgesehen von WASD weitere Tasten. Glücklicherweise unterstützt das Spiel auch Gamepads.
Stirbt man bei einer schwierigen oder zeitkritischen Aufgabe, geht es ab dem letzten Speicherpunkt weiter. Diese bestimmt allerdings das Spiel, eine manuelle Speicherfunktion gibt es nicht. Oft bleibt deshalb nur, die letzen Schritte noch einmal durchzuspielen.
Die Grafik von Deliver Us The Moon basiert auf der Unreal-4-Engine. Die erste Episode Fortuna läuft derzeit nur auf Windows-PCs (mindestens Windows 7, DirectX 11) und kostet auf Steam [5] rund 20 Euro. Auf Kickstarter hatten die Entwickler auch eine Version für die XBox in Aussicht gestellt. Geplant sind insgesamt fünf Episoden – der Mond wird also noch einige Überraschungen bereithalten.
()
URL dieses Artikels:http://www.heise.de/-4188115
Links in diesem Artikel:[1] https://www.deliverusthemoon.com/[2] https://www.kickstarter.com/projects/keoken/deliver-us-the-moon?lang=de[3] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4187955.html?back=4188115[4] https://www.heise.de/ct/bilderstrecke/bilderstrecke_4187955.html?back=4188115[5] https://store.steampowered.com/app/428660/Deliver_Us_The_Moon_Fortuna/[6] mailto:rop@ct.de
Copyright © 2018 Heise Medien
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Mehr Infos zu den heutigen Themen:
Google Plus: https://heise.de/-4183950
Linux: https://heise.de/-4183628
Portal und Portal+: https://heise.de/-4183638
Funk für Ampeln: https://heise.de/-4183853
Mehr Infos zu den heutigen Themen:
Fachkräftemangel: https://heise.de/-4182854
Mobilfunkversorgung: https://heise.de/-4182625
British Airways: https://heise.de/-4183263
Rechtspopulist Jones: https://heise.de/-4158441
"Ein Computer auf jedem Schreibtisch und in jedem Haushalt" -- das prognostizierte Microsoft-Gründer Bill Gates in den siebziger Jahren; und er behielt recht. Inzwischen verdrängt eine immer größere werdende Armada von spezialisierten, "smarten" Geräten den klassischen PC; die Verkaufszahlen von Desktops und Notebooks sinken seit Jahren.
Ist der PC nun dem Tode geweiht? Oder wird er auch in zehn Jahren noch so relevant sein wie heute? Über dieses saukontroverse Thema diskutieren Carsten Spille und Jan-Keno Janssen vom c't Magazin mit Fabian Scherschel von heise online und Robert Thielicke von Technology Review.
Die c't 21/18 gibt's am Kiosk, im Browser und in der c't-App für iOS und Android.
Alle früheren Episoden unseres Podcasts gibt es unter www.ct.de/uplink.
Mehr zu:
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
Komplexität ist die zentrale Herausforderung in der Softwareentwicklung. Daher gilt es, immer bestrebt sein, Komplexität zu eliminieren. Schließlich sollten wir immer lieber einfache Probleme lösen wollen als komplexe. Aber manchmal beten wir Komplexität an – und das kann Komplexitätsprobleme unlösbar machen.
In der Softwareentwicklung geht es nur scheinbar ums Programmieren. Einen Zehnzeiler kann jeder schreiben. Das Problem sind komplexe Systeme. Wenn ein System so groß ist, dass ein einzelner Mensch allein es nicht verstehen und weiterentwickeln kann, sind Konzepte wie Modularisierung entscheidend. Modularisierung teilt das System in kleine Einheiten auf, die ein Mensch weiterentwickeln kann. Dann wird Komplexität entscheidend. Aber bei solcher Komplexität können Einzelpersonen keine Projekte mehr durchführen, sondern nur noch Teams. Das führt zu organisatorischen Herausforderungen.
Wichtig ist in diesem Zusammenhang das Gesetz von Conway [1]. Es besagt, dass die Architektur eines Systems die Kommunikationsstrukturen der Organisation abbildet, die das System umsetzt. Für jedes Modul in der Software gibt es also eine Einheit in der Organisation und für jede Kommunikationsbeziehung zwischen Organisationseinheiten eine Abhängigkeit zwischen den Modulen in der Software.
In Conways Paper von 1968 ist aber noch etwas anderes beschrieben: Wenn eine Organisation ein großes System entwickeln will, dann muss sie viele Leute in das Projekt holen. Da Kommunikation in einem großen Team schwierig ist, bricht sie ab einer bestimmten Teamgröße zusammen. Da Kommunikation und Architektur sich gegenseitig beeinflussen, führt die mangelhafte Kommunikation zu einer chaotischen Architektur und zusätzlicher Komplexität.
Conway geht aber weiter: Offensichtlich sollte man sich, wenn irgend möglich, auf elegante Lösungen fokussieren, die ein kleines Team umsetzen kann. Aber das Prestige eines Managers hängt von der Größe des Teams und des Budgets ab, für das er oder sie zuständig ist, so Conway. Daher wird ein Manager möglichst ein großes Team und ein großes Budget anstreben.
Das scheint zunächst kein Problem zu sein. Wenn das Projekt eigentlich mit einem kleineren Team gelöst werden kann, sitzen eben einige rum. Das kostet Geld, gefährdet aber Projekt und Architektur nicht. Conway sagt aber, dass das Parkinsonsche Gesetz [2] zuschlägt. Parkinson erklärt mit dem Gesetz, warum einige Verwaltungen zwar mehr Mitarbeiter einstellen, aber trotzdem nicht mehr leisten. Dieses Gesetz besagt, dass eine Aufgabe die zur Verfügung stehende Zeit aller Mitarbeiter vollständig ausfüllt. Auch wenn die Aufgabe einfach und schnell bearbeitet werden kann, beteiligen sich immer mehr Personen daran, bis alle Personen in der Organisation mit Arbeit versorgt sind. In einem Software-Projekt werden also alle Teammitglieder an dem Projekt arbeiten, unabhängig davon, ob das notwendig ist. Dementsprechend wird dann die Organisation groß werden, die Kommunikation gegebenenfalls zusammenbrechen und die Architektur chaotisch werden
Die Erkenntnis von Conway, die mittlerweile 50 Jahre alt ist, ist vor allem interessant, weil sie eine Erklärung dafür sein kann, wenn ein großes wichtiges Projekt eine schlechte Architektur hat und schwer weiterentwickelt werden kann.
Die Manager aus diesem Paper beten Komplexität an, ohne dass ihnen das klar ist. Sie wollen ein möglichst großes Team und machen so ein Problem zu komplex, weil eine große Organisation die Architektur zusammenbrechen lassen kann.
Aber nicht nur Manager, sondern auch wir Softwarearchitekten beten manchmal Komplexität unbewusst an. Das passiert beispielsweise, wenn wir unreflektiert Patterns wie Event Sourcing, Architekturen mit vielen Schichten oder Microservices nutzen, ohne den Nutzen in dem spezifischen Kontext und die Komplexität genügend abzuwägen.
Auch der Technologie-Spieltrieb kann zu überbordender Komplexität führen. Schließlich suchen wir alle technische Herausforderungen und wollen besonders spannende Projekte umsetzen. Dazu sind moderne Ansätze und besonders komplexe Systeme gut geeignet. Ebenso lösen wir manchmal technische Probleme, die sich eigentlich gar nicht stellen. So entstehen sehr generische oder skalierbare Lösungen, die von den tatsächlichen Anforderungen so nicht gefordert werden und dadurch zu viel Komplexität erzeugen.
Ein besonders krasser Fall von Komplexitätsanbetung ist die Aussage "Das funktioniert bei uns nicht. Unsere Herausforderungen sind viel größer als die von Amazon oder Google." Ich habe das schon von Mitarbeitern unterschiedlicher Unternehmen gehört. Solche Äußerungen sind verwunderlich: Unternehmen wie Amazon oder Google betreiben ausgesprochen komplexe IT-Systeme und ihr wirtschaftlicher Erfolg hängt unmittelbar von diesen IT-Systemen ab. Sie gehören nicht zuletzt wegen dieser IT-Systeme zu den wertvollsten Unternehmen der Welt.
Auf den ersten Blick kann man die Äußerungen als Abwehrhaltung interpretieren: Amazon und Google haben eine moderne Organisation und eine Cloud-Infrastruktur, aber in der noch viel komplexeren Umgebung des Unternehmens geht das alles leider nicht. Aber vielleicht schwingt Stolz mit, denn schließlich kümmert man sich um nahezu beispiellose Herausforderungen. So oder so gilt auch hier: Die Komplexität hat zwar natürlich Nachteile, aber eben auch den Vorteil, dass man sich eben mit bestimmten Ansätzen wie Cloud, Continuous Delivery oder Microservices nicht beschäftigen muss, weil das ja eh nicht geht.
Es ist also fraglich, ob wir Komplexität wirklich immer vermeiden. Sich nur auf Techniken zu konzentrieren, Entwürfe möglichst einfach und elegant zu machen, nützt nichts, wenn wir unbewusst Komplexität doch anbeten. Deswegen ist es wichtig, sich über diese unbewussten Mechanismen klar zu werden. Natürlich gibt es dennoch viele komplexe Probleme, die tatsächlich schwer zu lösen sind.
Vielen Dank an meine Kollegen Jens Bendisposto, Jochen Christ, Lutz Hühnken, Michael Vitz und Benjamin Wolf für die Kommentare zu einer früheren Version des Artikels.
In der Softwareentwicklung geht es vor allem darum, Komplexität zu handhaben. Am besten wäre es, Komplexität gleich zu vermeiden. Aber leider kommt es manchmal zur – bewussten oder unbewussten – Komplexitätsanbetung, die zu unnötig komplexen Systemen führt.
URL dieses Artikels:http://www.heise.de/-4170914
Links in diesem Artikel:[1] http://www.melconway.com/Home/Committees_Paper.html[2] https://de.wikipedia.org/wiki/Parkinsonsche_Gesetze
Copyright © 2018 Heise Medien
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Video merken Mail versenden Permalink
FreshRSS