Ben Evans, Autor von „The Cultivation of Java Programmers': Konservatives Designdenken ist der größte Vorteil von Java

Ben Evans ist der Mitbegründer von jClarity. Sein Unternehmen entwickelt Leistungstools und Services, die Entwicklungs- und Betriebsteams unterstützen. Er ist einer der Organisatoren der LJC (London Java User Group) und Mitglied des Exekutivkomitees des JCP (Java Community Process) und hilft bei der Definition einiger Standards im Java-Ökosystem. Er ist außerdem Träger der Auszeichnung „Java Champion“. Er ist Co-Autor von „The Well-Grounded Java Developer“ und „Java Authoritative Technical Manual (6. Auflage)“ (Java in a Nutshell). Er hat zahlreiche Vorträge über die Java-Plattform, Leistung, Parallelität und verwandte Themen gehalten.

Frage: „Java in a Nutshell“ ist ein Klassiker. Die vorherige Ausgabe (5. Auflage) war 1.200 Seiten lang und die sechste Auflage wird in China veröffentlicht Zehn Jahre später sind es nur noch 400 Seiten. Welche Änderungen wurden zwischen den beiden Ausgaben vorgenommen? Was bedeutet dieses Jahrzehnt für Java?

Die erste Ausgabe des „Java Definitive Technical Manual“ wurde kurz nach der Popularität von Java veröffentlicht. Damals waren die Menschen voller Fantasie über Java. In den nächsten fünf Auflagen wuchs das Buch an Umfang und Inhalt. Daher ist der Schwerpunkt jedes Bandes etwas historisch, da zwischen mehreren Versionen eine evolutionäre Beziehung besteht. Dies liegt unter anderem daran, dass es einfacher zu schreiben ist. Sie müssen lediglich wissen, was im Vergleich zur vorherigen Version hinzugefügt oder entfernt wurde. Aber was noch wichtiger ist: In der Anfangszeit hatte Java in den meisten Unternehmen einen langen Lebenszyklus, sodass man oft sehr alte Java-Versionen sah. Daher ist es wichtig, die Unterschiede zwischen den verschiedenen Versionen zu verstehen. Wenn Sie also in einem bestimmten Unternehmen an einer bestimmten Java-Version arbeiten und wissen, um welche Version es sich handelt, wissen Sie auch, was Sie tun können und was nicht und welche Änderungen diese Version im Vergleich zu anderen Versionen hat.

Das war das Erste, was ich ändern wollte, als ich anfing, eine neue Ausgabe zu schreiben. Denn der Lebenszyklus der neuesten Version von Java 8 (an dieser Stelle kann man leicht verwechseln, die 6. Ausgabe des „Java Authoritative Technical Manual“ spricht von der 8. Ausgabe von Java) ist viel kürzer als zuvor. Dies hängt natürlich von der jeweiligen Domäne ab, aber wenn man sich die allgemeine Nutzung anschaut, wird man feststellen, dass ältere Versionen (wie Java 6) nur von einer sehr kleinen Anzahl von Menschen genutzt werden. Natürlich gibt es immer noch einige Verrückte, die Versionen vor Version 6 verwenden, und die meisten Benutzer verwenden Version 7. Mittlerweile erobert Version 8 den Markt in rasantem Tempo. In nur einem halben Jahr nutzen bereits 15 bis 20 % der Nutzer Java 8. Daher ist der Fokus der neuen Version des „Java Authoritative Technical Manual“ offener als zuvor. Wir beginnen, unsere Aufmerksamkeit auf die Welt außerhalb von Java zu richten und werden auch die Gegenwart und die Zukunft diskutieren.

Die zweite wichtige Änderung ist die Länge. Wie Sie sagten, war die 5. Auflage 1200 Seiten lang, während die 6. Auflage nur ein Drittel davon umfasste. Als ich mit der Zusammenstellung der vorherigen Auflage begann Ich habe zwei Drittel des Inhalts entfernt. Wenn Sie die fünfte Auflage gelesen haben, wissen Sie, dass es im zweiten Teil des Buches neben der Erörterung des Hauptinhalts von Java auch um Indizes geht. Dies hat natürlich auch historische Gründe. Als Java zum ersten Mal herauskam, war die Nutzung des Internets nicht sehr verbreitet, daher ist es sehr sinnvoll, dass das Buch über einen eigenen Index verfügt. Aber es gibt noch zwei weitere Gründe: Die Java-Plattform wird immer größer. Im ersten Kapitel von „The Definitive Java Technical Manual“ habe ich die Entwicklung der Java-Version erörtert und auf das schnelle Wachstum der Java-Plattform hingewiesen. Es dauerte 800 Seiten, um die Grundkenntnisse der Java-5-Plattform zu beschreiben. Das war zu Zeiten von Java 5. Wenn die gleiche Methode zur Diskussion von Java 8 verwendet würde, wäre das Buch so hoch wie die Obergrenze. Es ist ersichtlich, dass diese Methode nicht praktikabel ist. Niemand wäre bereit, ein solches Buch zu halten. Ein weiterer Grund (vielleicht hängen diese beiden Dinge zusammen) ist, dass sich die Art und Weise, wie Menschen technische Informationen nutzen, geändert hat. Das Internet ist jetzt überall, die Menschen sind nicht bereit, schwere Bücher mit sich zu führen, und alle Indizes können online in PDFs, auf Websites usw. gefunden werden an Ressourcen. Daher ist es zum jetzigen Zeitpunkt unvernünftig, am Ende des Papierbuchs einen umfangreichen Index hinzuzufügen. Dies ist die wichtigste Änderung zwischen den beiden Versionen des „Java Definitive Technical Manual“.

Als Drittes versuche ich, die sich ändernden Trends und Muster von Java einzufangen. Daher wurden viele Inhalte zur Verwendung von Java in der Vergangenheit entfernt und ich habe modernere Verwendungsmethoden hinzugefügt. Die Leser müssen viel über diese Aspekte sprechen. Es war viel Arbeit damit verbunden, da der Schwerpunkt der Originalversion auf der Beibehaltung des Originalinhalts lag. Von dem in der fünften Auflage verbliebenen Drittel des Inhalts waren in der sechsten Auflage nur noch etwa 25–30 % übrig. Auch diese Inhalte wurden überarbeitet, während die restlichen etwa 70 % des Inhalts völlig neu sind. .

Da wir dieses Buch veröffentlichen wollten, als Java 8 in Gebrauch kam, begannen wir mit dem Schreiben, bevor Java 8 herauskam. Später erschienen einige Arbeiten, die wir zu Beginn nicht erwartet hatten (z. B. versteckte Funktionen von Java 8). Aber dieses Mal haben wir mehr Erfahrung und hoffen, die nächste Version im April 2016 fertigzustellen, wenn Java 9 herauskommt. Tatsächlich habe ich konkrete Pläne gemacht.

Frage: Haben Sie weitere Pläne für „The Well-Grounded Java Developer“?

Dieses Projekt „How to Cultivation as a Java Programmer“ ist sehr gut und der Schreibprozess hat auch sehr viel Spaß gemacht. Aber ich habe viel Energie darauf verwendet, „The Definitive Technical Manual of Java“ zu schreiben, und ich denke, dass ich vielleicht keine zweite Auflage dieses Buches schreiben werde. Ich habe mit Manning, dem ursprünglichen Herausgeber dieses Buches, gesprochen, bin mir aber nicht über die neuesten Entwicklungen im Klaren, daher ist es sehr wahrscheinlich, dass es keine zweite Auflage dieses Buches geben wird.

Frage: Was ist der Unterschied zwischen einem Java-Experten und einem gewöhnlichen Java-Programmierer?

Ich denke, die Ebene der Programmierer kann als Pyramide betrachtet werden, die grob in 3 Ebenen unterteilt werden kann. Ganz unten stehen sehr fleißige Programmierer, die aber vielleicht wenig Interesse am Programmieren selbst haben. Sie können auch gute Arbeit leisten, denken aber nach Feierabend nicht mehr ans Programmieren. Das ist ein normales Phänomen. Die Softwareindustrie braucht viele Programmierer, und dieser Bedarf wächst weiter. Programmierer auf mittlerem Niveau wollen mehr tun, sie lesen Technologie-News und Neuigkeiten auf Websites, sie verfolgen den Fortschritt der nächsten Version, sie kümmern sich um ihre Fähigkeiten, Programmierer auf diesem Niveau sind sehr interessant. Programmierer an der Spitze sind immer von Handwerkskunst und der Natur der Technologie fasziniert. Wenn Sie die Spitze dieser Pyramide erreichen, beginnt eine Feedbackschleife, in der Sie von sich selbst lernen und ein tieferes Verständnis des Handwerks erlangen. Aber ich denke, das Schwierigste ist, wie man von der zweiten Ebene nach oben durchbricht. Wenn Sie auch nur das geringste Interesse an Wissen außerhalb Ihrer Tätigkeit haben, müssen Sie Ihren eigenen Standpunkt finden. Sobald Sie das Fachgebiet gefunden haben, das Sie fasziniert, können Sie Ihrer Neugier nachgehen.

Es gibt ein Sprichwort über Open-Source-Software. Ein guter Open-Source-Entwickler muss seine eigenen Schwachstellen finden und das Problem lösen, das ihn stört. Aus diesem Grund interessieren sich die meisten Menschen für Open-Source-Software und werden oft als Java-Entwickler bezeichnet. Sie finden einen Punkt, der Sie interessiert, und weil Sie nicht wissen, warum, lernen Sie weiter. Das ist das Geheimnis des Wachstums.

Frage: Obwohl Lambda zu Java 8 hinzugefügt wurde, gibt es immer wieder Beschwerden unter Entwicklern, dass die Java-Syntax zu ausführlich ist. Glauben Sie, dass dies der Hauptgrund dafür ist, dass viele Entwickler und Teams vor der Verwendung von Java zurückschrecken?

Das glaube ich nicht. James Gosling erklärt in drei Sätzen das Sprachdesign von Java und warum Java das ist, was es jetzt ist. Der erste Satz ist die sogenannte „Blue-Collar“-Sprache im Englischen. Blue-Collar-Worker sind die Personen, die an vorderster Front arbeiten, während White-Collar-Arbeiter die Arbeit von Büros und Managern darstellen. Java ist eine Programmiersprache, die es berufstätigen Programmierern ermöglicht, echte Probleme zu lösen. Java ist eine praktische Sprache, die reale Geschäftsprobleme löst.

James Gosling sprach auf der JavaOne-Konferenz 2014 über Lambda und einige Designs, die in frühen Versionen von Java nicht vorkamen. Er sagte: Wenn ich nicht den richtigen Weg finde, etwas zu tun, dann habe ich nichts. Tun. Dieser Satz drückt eine langsame und konservative evolutionäre Designphilosophie aus. Wenn Sie verstehen möchten, was Java ist, müssen Sie dies verstehen. Viele Leute denken, dass Java alt ist und die Programmiersprache geändert werden muss, aber sie verstehen nicht, dass die eigentliche Änderung bei ihnen selbst liegt. Sie entwickeln sich in ihren Fähigkeiten weiter, sie wollen weiter und tiefer sehen, und die Sprache spiegelt dies wider. Es ist nicht so, dass die Sprache geändert werden muss, sondern dass sich die Programmierer selbst, die diese Idee hatten, geändert haben. Java war und ist eine konservativ gestaltete Sprache. Dies ist auch ein großer Vorteil von Java.

Als James seine ursprüngliche Absicht, Java zu entwerfen, erklärte, sagte er: Als ich entwarf, wusste ich, dass die Leute eine automatische Speicherverwaltung wollten, die Leute wollten eine starke Eingabe, aber diese Funktionen würden Arbeiter abschrecken. Smalltalk zum Beispiel ist eine ausgezeichnete Sprache, aber sie ist zu fortgeschritten und entfernt sich von der Art und Weise, wie Entwickler tatsächlich denken, wenn sie Anwendungen erstellen. Also hat Java einige dieser Ideen geerbt, sie vereinfacht und diese Ideen in eine Sprache und ein Format gebracht. Diese Dinge erklären die grundlegende Motivation für die Gestaltung dieser Sprache.

Man kann also sicherlich sagen, dass Java eine ausführliche Sprache ist, aber ich denke, dass der zusätzliche Inhalt der besseren Lesbarkeit dient. Besonders wenn Sie ein Junior- oder Fortgeschrittenen-Programmierer sind, können Ihnen diese scheinbar überflüssigen Wörter helfen. Die Menschen werden sich immer daran erinnern, dass unser Produktivitätsbedarf immer größer wird, Code aber immer noch geschrieben wird. Daher glaube ich nicht, dass Java ausführlich ist, obwohl wir einige erweiterte Funktionen hinzufügen können, aber einige Dinge können in einer Sprache nie geändert werden, was eine Schande ist. Natürlich werden wir Fortschritte machen, aber wie ich immer sage, den Leuten geht es immer zu sehr um die Grammatik und nicht darum, was mit der Sprache erreicht werden kann.

Frage: Heutzutage wechseln viele große Unternehmen (Paypal usw.) die Position von Java in Unternehmen. In welchen Bereichen sind Java und Node.js jeweils gut? ?

In dieser Frage liegt ein Missverständnis vor. Tatsächlich gibt es keine große Welle von Unternehmen, die Java aufgeben und auf Node.js umsteigen. Der Node.js-fähige Teil von Paypal ist klein und der größte Teil des laufenden Codes von Paypal ist immer noch Java. Node.js nimmt an einem Pilotprojekt teil, was verständlich ist, dass Node.js eine interessante Umgebung mit einigen interessanten Ideen ist. Node.js ist sehr jung und weist gleichzeitig viele schwerwiegende Probleme auf. Daher ist es noch zu früh, die zukünftige Entwicklung von Node vorherzusagen. Obwohl es auf verschiedenen Entwickler-Websites viele Stimmen gibt, die Node unterstützen, und es auf GitHub viele interessante Projekte gibt (z. B. die Verwendung zum Schreiben von Ardruino oder das Spielen mit Hardware), besteht unter allen Produkten in Produktionsumgebungen kein Zweifel daran, dass Java dies hat die meisten Codezeilen. Unternehmen werden nicht ohne guten Grund auf funktionierende Software verzichten. Obwohl es viele Unternehmer gibt, die Node.js verwenden, kommen und gehen Unternehmer schnell.

Twitter ist eines der interessantesten Produkte der letzten Jahre. Wenn Sie deren Entwicklung beobachten, werden Sie feststellen, dass sie ursprünglich Ruby on Rails verwendet haben. Vor drei oder vier Jahren tauchte auf ihrer Website eine sehr niedliche Zeichentrickfigur auf, der Fail Whale. Es war eine peinliche Sache, und sie haben eine Menge Nachforschungen angestellt, um herauszufinden, was los war, und nachdem sie sich Rubys Müllsammlung angesehen hatten, stellten sie fest, dass sie nichts tun konnten. Gleichzeitig war ihr Java-Pilotprojekt erfolgreich und sie erkannten, dass Java ihre Skalierbarkeitsprobleme lösen konnte. Dann nutzten sie im Laufe der nächsten 18 Monate etwas JRuby als Ausgangspunkt und schrieben dann das gesamte System in Java um. Der Endeffekt ist auch sehr gut, es wurden neue Dienste und eine neue Architektur rund um Java eingeführt. Einst galt Ruby als die Zukunft der Unternehmenssoftware, doch heute ist Ruby nur eine Programmiersprache unter vielen. Die drei am weitesten verbreiteten Sprachen sind derzeit Java, JavaScript und C/C++, aber der Großteil des JavaScript-Codes befindet sich auf der Clientseite. Wenn diese drei Sprachen entfernt werden, werden die Marktanteile anderer Sprachen sinken sehr klein.

Frage: Bisher erfordert das virtuelle Hosting-Modell für Java-Anwendungen, dass die gesamte virtuelle x86-Maschine zum Hosten einer separaten JVM-Instanz zugewiesen wird. Relativ gesehen hostet die Instanz auch eine separate Java-Anwendung. Diese Methode ist sehr ineffizient, aber Java unterstützt keine mandantenfähige Virtualisierung und Cloud-Computing-Konfigurationen nativ. Glücklicherweise gibt es in der Community einige mandantenfähige Java-Lösungen zur Lösung von Cloud-Computing-Problemen. Welche Lösung ist Ihrer Meinung nach ausgereift genug, um auf Produktionsumgebungen angewendet zu werden?

Dabei geht es um zwei Dinge: Die Vermischung von Virtualisierung mit Cloud und Mandantenfähigkeit ist nicht ganz richtig. Auf der QCon Shanghai gab es beispielsweise viele Beiträge zum Thema Docker (Docker ist eine Plattform, die nicht auf Virtualisierung angewiesen ist), und einer der wunderbaren Beiträge kam von Chris Swan. Er zeigte, dass die Verlagerung des CPU-Speichers von einer virtuellen Umgebung in eine Docker-basierte Umgebung bereits zusätzliche Vorteile mit sich bringt, wenn man Java auf Docker ausführt. Wir sollten die Beziehung zwischen Cloud und Virtualität klar klären. Darüber hinaus können Sie noch viele andere Dinge tun, z. B. können Sie mehrere JVM-Hosts einrichten.

Was diese Frage aber eigentlich betrifft, ist die Mandantenfähigkeit. Was dieses Thema betrifft, gibt es für mich ein Produkt, das zu Recht der Champion ist, und das ist Waratek. Waratek kann eine separate Nicht-Hotspot-JVM trennen und die Host-JVM darin ausführen. Die Java Virtual Multi-Tenant-JVC wird in der JVM ausgeführt, und die JVC kann sehr leichtgewichtig sein. Ich denke, Waratek ist ein sehr ausgereiftes Produkt, das gerade eingesetzt werden kann. Da die Deutsche Bank dieses Produkt genehmigt hat, sollte es sich lohnen, es einmal zu studieren .

Frage: Java wird oft mit Scala verglichen. Was sind die Unterschiede in den Designzwecken dieser beiden Sprachen? Ist es möglich, dass sich die beiden Sprachen in Zukunft in genau die gleiche Richtung entwickeln?

Java und Scala sind sehr unterschiedliche Sprachen. Wir haben zuvor über die Designphilosophie von Java gesprochen, jetzt können wir über die Designphilosophie von Scala und die Unterschiede zwischen ihnen sprechen. Scala war ursprünglich eine Sprache aus der Wissenschaft, die ursprünglich von Martin Odersky erstellt wurde. Damals war Java noch Version 4. Zu diesem Zeitpunkt begann Pizza, nach und nach einige dem Java-Paradigma ähnliche Funktionen hinzuzufügen in Java 5. Einige der Funktionen von Pizza dienen als Paradigmen.

Martin ist ein sehr kluger Mensch und Scala hat auch viele tolle Designs. Aber gleichzeitig hat diese Sprache auch ihre eigenen Probleme. Sie wird manchmal als „Küchenspülensprache“ bezeichnet, was zeigt, dass die Menschen eine Hassliebe zu dieser Sprache haben. Die Bedeutung dieser Metapher ist: In der Spüle befinden sich zu viele verschiedene Dinge. Das ist wirklich ein Problem mit Scala, es hat zu viele Funktionen. Es gibt eine Regel des Sprachdesigns, die auch ein wichtiges Prinzip im Java-Designprozess ist: Konservatismus. Insbesondere jedes Mal, wenn Sie eine neue Funktion hinzufügen (ein konkretes Beispiel wird auf Seite 14 von „Die Ausbildung von Java-Programmierern“ besprochen), können auch neue Probleme entstehen. Wenn Ihre Sprache 200 Funktionen hat und Sie eine weitere hinzufügen möchten, muss ich prüfen, wie sie mit allen anderen Funktionen interagiert. Scala fügt ständig neue Funktionen hinzu. Es ist schwierig zu wissen, wie diese Funktionen interagieren. Auch wenn Scala über eine sehr flexible Community verfügt, die Veränderungen akzeptieren kann, sind Änderungen an Sprachfunktionen nicht einfach. Sie werden also feststellen, dass Scala zwar über eine hervorragende Leistung verfügt, Sie jedoch entscheiden müssen, welche Funktionen Sie möchten und welche nicht. Dies ist kein Problem, wenn Sie im Team programmieren. Das eigentliche Problem besteht darin, dass sich der Software-Stack in der modernen Gesellschaft nie ausschließlich auf Code verlassen hat. Das Problem liegt in Funktionsbibliotheken. Es gibt einige Scala-Funktionen, deren Aktionen sich nicht nur auf das Zielobjekt, sondern auch auf andere Dinge auswirken. Je mehr Funktionen Scala bietet, desto leichter überschneiden sich diese Probleme.

Darüber hinaus hatten sie schon immer mit Binärkompatibilitätsproblemen zu kämpfen. Java, Sun und Oracle haben immer geglaubt, dass dies das wichtigste Designkonzept für Java ist, sodass ich ein Programm in Java 1.0 schreiben, kompilieren und in die virtuelle Java 8-Maschine einfügen kann Die Laufgeschwindigkeit wird um ein Vielfaches höher sein als früher. Scala hat diesbezüglich nie ein Versprechen abgegeben und auch in der Vorgängerversion wird es zu Problemen kommen. Im Bibliotheksbereich ist dieses Problem noch schwerwiegender. Ich weiß, dass viele Projekte Scala aufgegeben haben, weil jedes Mal, wenn sie die Bibliothek aktualisieren, das gesamte System abstürzt.

Daher sind die Designideen dieser beiden Sprachen sehr unterschiedlich. Die Leute mögen immer neue Dinge, und die erste Person, die es ausprobiert, wird auch die erste sein, die viele Vorteile genießt, aber in den meisten Fällen bevorzugen die Leute es, die zweite Person zu sein, die es ausprobiert. Sie können zusehen, wie die erste Person einen Fehler macht, und daraus lernen. Und Java ist eine Sprache, die aus den Fehlern anderer lernt. Ich habe gerade die Programmiererpyramide erwähnt. Ich denke, dass Scala nicht für die unterste Ebene geeignet ist. Ihre Rolle besteht eher darin, die Top-Level-Programmierer zum Denken anzuregen. Java ist eine Sprache, die für die gesamte Pyramide gilt und besonders für Programmierer auf niedriger und mittlerer Ebene geeignet ist. Ich glaube, dass es noch viele Jahre lang eine starke und gesunde Scala-Community geben wird, und ich hoffe, dass ich mich mit ihnen austauschen kann. Aber ich glaube nicht, dass Scala von einer Nischensprache zu einer Massensprache werden wird. Es mag zwar mittlerweile Hunderte von Scala-Programmierern auf der Welt geben, aber diese Zahl beträgt höchstens ein Prozent der Java-Programmierer, und dieser Anteil wird wahrscheinlich nicht weiter steigen.