Lassen Sie uns Java EE Offroad-Rallye und Schlamperei treffen! Interview mit Sebastian Dashner, EE-Kommissar von Jakarta

Heute ist Sebastian Dashner in unserem virtuellen Studio. Kurz gesagt, wer ist das:

• Leitender Java Developer Advocate bei IBM;
• Viele interessante Berichte und Videos auf YouTube ;
• Der Autor von Architecting Modern Java EE Applications ,
• Mitglied des Java Community Process: Expertengruppen JAX-RS, JSON-P, Config;
• Ein Committer in einer Reihe von Open Source-Projekten, einschließlich allem, was mit Java EE / Jakarta EE / MicroProfile zu tun hat.

In diesem Interview werden wir über folgende Themen sprechen:

Die Interviews stammen wie immer von Evgeny Trifonov ( phillennium ) und Oleg Chirukhin ( olegchir ) von der JUG.ru Group.

Eugene: Beginnen wir mit einem nicht technischen Problem. Auf Ihrem Twitter habe ich ein Foto von Ihnen in Nowosibirsk in einem JAVA-Sweatshirt gesehen. Wie ist Ihr Eindruck von dieser Reise?

Sebastian: Ich bin froh, dass du das Foto erkannt hast. Ich habe dieses Sweatshirt mit Joker 2017. Ich erinnere mich definitiv an die JBreak-Konferenz. Ich hätte nie gedacht, dass ich in eine so weite Ecke Sibiriens gehen würde - ich glaube, aus meinem Freundeskreis bin ich einer der wenigen, die dort gewesen sind. Außerdem habe ich am Tag vor der Konferenz meinen Geburtstag gefeiert und wir sind mit dem Schneemobil gefahren. Danach haben wir in einem Badehaus gesessen und Kebabs gegessen. Im Allgemeinen gibt es viele schöne Erinnerungen. Die Natur rund um Nowosibirsk ist sehr schön. Und die Tatsache, dass es, wenn Sie Krasnojarsk und Tomsk zählen, für tausend Kilometer um Sie herum keine anderen größeren Städte gibt, ist sehr beeindruckend.

Eugene: Sie sind Java Developer Advocate bei IBM. Dies ist keine sehr verbreitete Position. Andere mir bekannte Entwickleranwälte tendieren dazu, für die Produkte ihres Unternehmens zu werben. Was sind Ihre genauen Aufgaben bei IBM? Versuchen Sie, die Verbreitung und den effizienten Einsatz von Java auf jede mögliche Weise zu maximieren?

Sebastian: Ja, das ist eine ziemlich genaue Beschreibung meiner Arbeit. Ich muss hinzufügen, dass ich in erster Linie nicht so sehr im Interesse des Unternehmens oder des Produkts, sondern der Entwickler bin. Ich bemühe mich, ihre Arbeit zu erleichtern und Dinge auf die eine oder andere Weise im Zusammenhang mit Java Enterprise zu lehren. Ich teile mein Wissen in Blogs, Podcasts, Seminaren und Konferenzen. Ich verkaufe keine bestimmten Produkte, sondern die gesamte Technologie.

Eugene: Sie sind ein großer Befürworter von Open Source, arbeiten aber für IBM, was für die meisten Menschen nicht mit Open Source verbunden ist. Gleichzeitig weiß ich, dass IBM manchmal ziemlich aktiv an vielen Open Source-Projekten teilnimmt, beispielsweise an OpenJ9. In welcher Beziehung steht IBM zu Open Source?

Sebastian: Sie haben richtig bemerkt, dass viele die Beteiligung von IBM an Open Source-Projekten oft unterschätzen - ich selbst hatte keine Ahnung davon, bis ich anfing, in diesem Unternehmen zu arbeiten. Zum Beispiel arbeitet IBM viel in Cloud Native und in Java und ist einer der Hauptverantwortlichen für Kubernetes und Istio. Der Zugriff auf die OpenJ9-Quelle wurde von der Eclipse Foundation eröffnet, die wiederum von IBM erstellt wurde. Das Unternehmen trug auch zur Entwicklung serverloser Technologien wie Apache OpenWhisk bei. Im Allgemeinen sind IBM Programmierer sehr aufgeschlossen - fast alles, was in diesem Unternehmen getan wird, hat einen Open-Source-Aspekt oder eine offene Version. Bisher sind die Leute mit den Bemühungen von IBM in dieser Richtung nicht ausreichend vertraut, und meine Arbeit als Developer Advocate besteht unter anderem darin, die Community auf dem Laufenden zu halten.

Oleg: Ich habe kürzlich auf Twitter gelesen, dass Sie mit Steve Chin eine spezielle JUG-Motorradreise in Japan unternommen haben. Krug auf Motorrädern, was? Könnten Sie das näher erläutern?

Sebastian: Es war eine großartige Reise. Steve Chin und ich sind bereits mehrere Male mit Motorrädern gereist, und jedes Mal versuchen wir, dies mit Reden auf Konferenzen und in Benutzergruppen zu kombinieren. Mehrere solcher Reisen fanden in Deutschland und drei in Japan statt. Auf den ersten Blick scheint es, als ob wir dies nur zum Spaß tun - und natürlich können wir nicht leugnen, dass wir auf diesen Reisen eine großartige Zeit haben. Aus rein praktischer Sicht ist ein Motorrad ein sehr bequemes Transportmittel für Japan oder Mitteleuropa, da Städte mit Benutzergruppen und eine IT-Community nur hundert oder zwei Kilometer voneinander entfernt sind und Sie Staus auf einem Motorrad vermeiden können. Bei jeder dieser Reisen haben wir versucht, die maximale Anzahl von Menschen zu treffen und unser Wissen mit ihnen zu teilen.

Oleg: Sie reisen viel und sind sogar nach Russland gegangen, obwohl es nicht so einfach ist, unser Visum zu bekommen. Es gibt eine Meinung, dass Developer Advocate keine ernsthafte Beschäftigung ist. Als ob Sie um die Welt reisen, Spaß an Konferenzen haben - alles, nur um keinen Code zu schreiben. Glaubst du, du hast wirklich harte Arbeit? Es scheint, als sollte das Fliegen jeden Tag anstrengend sein.

Sebastian: Ich denke, beide Sichtweisen sind ein bisschen richtig. Ich mag meine Arbeit, aber es ist alles andere als immer einfach. Das eine stört das andere nicht. In der Tat können Reisen anstrengend sein, insbesondere wenn Sie sich nicht direkt nach dem Umzug ausruhen, sondern auf einer Konferenz sprechen oder ein Seminar organisieren. Und gleich nach der Konferenz müssen Sie wieder in das Flugzeug steigen, damit der ganze Tag beschäftigt ist. Wenn andererseits diese Aktivität nicht weggetragen würde, würde das Dach sehr schnell aus einem solchen Rhythmus herausgehen und eine Person würde einfach ausbrennen. Wenn ich es schaffe, Menschen an einem Tag etwas beizubringen und ein erfolgreiches Seminar durchzuführen, wird im Allgemeinen sogar Müdigkeit angenehm.

Eugene: Soweit ich weiß, erfordert diese Arbeit viel Aufwand, um auf dem neuesten Stand der Technik zu bleiben. Aufgrund der zusätzlichen Arbeitsbelastung für Developer Advocates ist dies schwieriger als für diejenigen, die ständig programmieren. Ich weiß, dass Sie regelmäßig Code für Jakarta EE schreiben, also haben Sie sich offensichtlich nicht von der Technologie losgerissen. Ist es schwierig, gleichzeitig Entwickleranwalt und Entwickler zu sein?

Sebastian: Ja, natürlich ist es für meine Arbeit sehr wichtig, Programmierer zu bleiben, sonst verlieren Sie den Kontakt zur Realität. Um kompetent über Technologie zu sprechen, benötigen Sie ständige Erfahrung in der Arbeit damit. Und die Programmierzeit ist aufgrund von Konferenzen sehr viel kürzer. Darüber hinaus müssen Sie von der technischen Seite der Dinge wirklich fasziniert sein und bereit sein, Abende und Wochenenden damit zu verbringen. Im Allgemeinen ist ein gewisses Gleichgewicht zwischen beiden Seiten der Aktivität erforderlich.

Oleg: Kommen wir zu technischen Fragen. Auf der ersten Seite Ihres Blogs befindet sich eine Inschrift:

IT sollte einfach und produktiv sein.
Die IT sollte Probleme lösen, keine schaffen.
Ich glaube, dass IT eine Chance ist, kein Kostenfaktor.

Was sind Ihrer Meinung nach die wichtigsten Faktoren für die Produktivität eines Java-Entwicklers? Gibt es Tipps, wie Sie produktiver arbeiten können, Life-Hacks, spezielle technische Nishtyaki und Dienstprogramme wie jcmd oder sdkman?

Sebastian: Ja, es gibt viele solche Programme. Der Einfachheit halber sprechen wir über die Notwendigkeit, übermäßige Komplexität sowohl bei den von uns entwickelten Tools als auch bei Implementierungen, bei denen wir diese Tools verwenden, zu beseitigen. Entwickler werden oft von der Komplexität an sich angezogen, und immer mehr Funktionen werden dem Produkt nur aus sportlichen Gründen hinzugefügt. Sie müssen sich immer fragen: Wird die Welt durch diese Funktion besser? Wird es helfen, ein Problem zu lösen? Wird es uns der Fertigstellung des Produkts näher bringen?

Wenn wir über die Produktivität des Entwicklers selbst sprechen, kann ich wirklich Ressourcen dafür empfehlen. Google mein Name und der Ausdruck "Entwicklerproduktivität". Ich habe einen Videokurs aufgenommen, der auf Youtube gepostet ist , und dort gebe ich nur zu diesem Thema Ratschläge. Es geht um die Verwendung der Befehlszeile, der Tastenkombinationen und der Verwendung der Tastatur. Der allgemeine Punkt ist, wie man mehr Arbeit in kürzerer Zeit erledigt. Wenn Sie sich mit diesem Thema befassen, verzögert sich der Prozess der Automatisierung und Optimierung der Arbeit. Sie werden mehr Zeit haben, über die Lösung des Problems nachzudenken und weniger - dumm auf die Schlüssel zu klopfen. Im Allgemeinen ist die Programmierleistung ein Thema, das mir sehr nahe steht.

Oleg: Soweit ich weiß, sind Sie ein Committer in MicroProfile und können daher alles wissen, was damit zu tun hat. Bitte sagen Sie uns, was um Java EE und Jakarta herum passiert. Ich habe ein wenig darüber gelesen, aber für mich als Person aus der Frühlingswelt ist das alles zu verwirrend.

Sebastian: Wie Sie wahrscheinlich wissen, ist Jakarta EE der Nachfolger von Java EE, das jetzt an die Eclipse Foundation übertragen wird. Dies ist ein ziemlich komplizierter Prozess, der noch nicht abgeschlossen ist, sodass Entwickler Jakarta EE noch nicht verwenden können. Die Grundlage basiert jedoch weiterhin auf Java EE-Standards. Ausgangspunkt ist Java EE 8. Natürlich wird sich Jakarta EE auch in Zukunft auf die gleiche Weise weiterentwickeln wie Java EE durch den JCP (Java Community Process). Dies bedeutet, dass eine Community aus mehreren Unternehmen, Konzernen und einzelnen Entwicklern gemeinsam Standards für die neue Unternehmensversion von Java entwickeln wird.

Aufgrund dieser Änderungen in Java EE entstand MicroProfile. Es wurde von mehreren Anbietern erstellt, die Java EE-Server ausführen. Ziel ist es, eine schnellere Entwicklung der Technologie zu gewährleisten, die weniger an strenge Standards gebunden ist. Es scheint mir sehr interessant zu sein, dass MicroProfile versucht, die Mängel von Java EE in Bezug auf moderne Cloud-native Microservices auszugleichen. Beispielsweise verfügt Java EE noch nicht über Systeme für injizierbare Konfiguration, Fehlertoleranz, Überwachung, alle Arten von OpenTracing und dergleichen. Mit MicroProfile haben Sie Zugriff auf all diese Dinge, sodass Sie sie nicht alle selbst implementieren müssen. Darüber hinaus wird in fast allen Fällen die Kompatibilität mit Java EE gewahrt. Als Grundlage dienen Java EE-Standards (wie JAX-RS und CDI), mit denen die meisten JavaEE-Entwickler bereits vertraut sind. Wenn ich beispielsweise in meiner Java EE-Anwendung Fehlertoleranz finde, schreibe ich dies nicht manuell, sondern integriere MicroProfile in meine Anwendung. Diese beiden Ökosysteme passen sehr gut zusammen. Für viele Anwendungen wie Open Liberty oder Payara unterstützen Laufzeiten sowohl MicroProfile als auch Java EE. In diesem Fall müssen Sie lediglich bestimmte Funktionen in die Laufzeit aufnehmen und dann die erforderlichen MicroProfile-Projekte zur Java EE-Anwendung hinzufügen. Während wir auf den endgültigen Übergang von Java EE zur Eclipse Foundation warten, können Sie diese Lösung verwenden.

Oleg: Denkst du, dass MicroProfile Teil von Jakarta sein sollte?

Sebastian: Das ist eine großartige Frage, und es gibt noch keine endgültige Entscheidung darüber. Persönlich denke ich, dass MicroProfile am besten als eine Art Inkubator für Jakarta EE funktioniert. Der neue Standard wird zuerst zu MicroProfile hinzugefügt (wie dies bei OpenTracing oder der injizierbaren Konfiguration der Fall war), und dann sehen wir uns an, wie sich das System in der Produktion verhält. Wenn sie reif ist, werden die Elemente von ihr, die sich als volle Standards erwiesen haben. Dadurch werden wir einige Unsicherheiten beseitigen, da wir bereits wissen, ob das System in der Produktion gut funktioniert oder nicht.

Oleg: Da wir über Standards gesprochen haben, habe ich Eclipse Specification Processes gesehen, es war ein riesiger Googlodok, der sehr schwer zu verstehen war. Dokumente mit Entwurfsspezifikationen von Jakarta EE sahen aus wie ein höllisches Gewirr. Könnten Sie diesem Ball helfen, sich zu entspannen? Wie unterscheidet sich dies beispielsweise vom Java Community-Prozess?

Sebastian: Die Eclipse Foundation ist eine Open-Source-Organisation. Im Moment versuchen wir, die Form jener Prozesse zu bestimmen, nach denen sich Jakarta EE in Zukunft entwickeln wird. Sie haben JCP erwähnt - daher stimme ich der Meinung voll und ganz zu, dass die Standards für Jakarta EE JCP nachempfunden sein sollten. Ich glaube, dass sich dieses Modell sehr gut gezeigt hat. Es sollte bedacht werden, dass kein Unternehmen ein Monopol auf die Entwicklung von Standards für Jakarta EE hat. An diesem Prozess beteiligen sich mehrere Unternehmen mit mehr oder weniger gleichen Rechten, so dass er nicht in der Entwicklung stecken bleibt, wenn eines von ihnen nicht mehr daran teilnehmen kann. Ich denke, dies ist ein wichtiger Vorteil, da diese Technologie sehr wichtig ist und es sicherer ist, sich in einer offenen Gemeinschaft zu entwickeln.

Oleg: Eine solch ausgefeilte Technologie muss an etwas getestet werden. Verwenden Sie Technologiekompatibilitätskits für Java und Jakarta? Oder haben Sie eine eigene Testsuite?

Sebastian: Das ist auch ein sehr wichtiges Thema. In JCP hatten alle diese TCKs normalerweise eine geschlossene Quelle. Dies war ein ziemlich zweifelhafter Vorteil. Einerseits könnte die Spezifikation Tests liefern, die zeigten, ob eine Implementierung gültig war oder nicht. Aber der gewöhnliche Entwickler wusste nicht, was genau dort im Inneren getestet wurde, wie diese Tests abgedeckt waren usw. Jetzt ist TCK Open Source geworden. Alle Unternehmen und Entwickler können jetzt an ihrer Entwicklung und Verbesserung teilnehmen. Wenn sich herausstellt, dass das Produkt eines Unternehmens nicht wie in der Spezifikation angegeben funktioniert, können Sie dies dem Unternehmen nicht nur anzeigen, sondern auch eine Anfrage in TCK selbst hinterlassen. Oder noch besser, Sie können ein paar Pull-Anfragen senden und TCK selbst verbessern. Sie verbessern also nicht nur die Software eines Lieferanten, sondern das gesamte Ökosystem.

Oleg: Es gibt ein anderes Produkt, dessen Name das Wort "Profil" enthält: IBM WebSphere Liberty Profile. Können Sie uns sagen, was es ist und was der Unterschied zu Open Liberty ist, da Sie bei IBM arbeiten?

Sebastian: WebSphere Liberty Profile ist eine kommerzielle Version von Open Liberty. Dies ist der Java EE-Anwendungsserver, für den IBM kommerziellen Support bietet. Ich könnte mich irren, aber meiner Meinung nach wurde Open Liberty vor anderthalb Jahren Open Source. Dank dessen haben Unternehmensentwickler jetzt einen kostenlosen und produktionsgeprüften Anwendungsserver. Wenn ein Unternehmen kommerziellen Support oder einige kommerzielle Funktionen benötigt, kann es das WebSphere Liberty-Profil verwenden. Es ist 2019, und ich glaube, dass jetzt jedes Unternehmen eine Open-Source-Version seines Produkts bereitstellen sollte, damit Entwickler die Möglichkeit haben, das Produkt kostenlos zu testen. OpenSource ist sehr wichtig, und ich bin froh, dass IBM jetzt mehrere Optionen für den früheren WebSphere Liberty Server hat.

Oleg: Ich habe gehört, dass es über OSGi geschrieben ist. Können Sie uns mehr darüber erzählen, wie es im Inneren angeordnet ist?

Sebastian: Ich persönlich habe Open Liberty nicht entwickelt, aber soweit ich weiß, liegt es wirklich unter OSGi. Es ist interessant, dass Sie dort ganz einfach konfigurieren können, welche Funktionen enthalten sein werden. Wenn Sie nur MicroProfile verwenden möchten, das nur eine kleine Anzahl von Java EE-Standards abdeckt, können Sie das System entsprechend konfigurieren. Oder Sie können es so gestalten, dass Sie eine vollständige Java EE-Anwendung haben. Durch die Tatsache, dass in einer laufenden Instanz nur das enthalten ist, was wirklich benötigt wird, werden eine optimale Startzeit und ein minimaler Ressourcenverbrauch erreicht.

Oleg: Unterscheidet sich die Konfiguration und Verwendung von Liberty Profile von Full Profile? Werden in beiden Fällen die gleichen Werkzeuge verwendet?

Sebastian: Es gibt keine signifikanten Unterschiede in der Verwendung. In Bezug auf die Auswahl der Funktionen können beide Server gleichermaßen konfiguriert werden. Wenn Sie eine Java EE- oder MicroProfile-Anwendung haben, ist das Setup für beide Typen gleich.

Oleg: Unternehmen verwenden seit langer Zeit Full Profile. Wie gerechtfertigt ist die Verwendung von Liberty Profile in großen Organisationen?

Sebastian: Absolut gerechtfertigt. Selbst wenn das Unternehmen kommerziellen Support gekauft hat, bedeutet dies nicht, dass es das vollständige Profil verwenden muss. Es ist durchaus sinnvoll, eine leichtere Version zu verwenden. Wenn das Produkt des Unternehmens auf modernen Microservices und kurzen Laufzeiten basiert, ist es möglicherweise besser, WebSphere Liberty zu wählen und es so zu konfigurieren, dass es beispielsweise nur mit MicroProfile funktioniert. Glücklicherweise haben kommerzieller Support und kommerzielle Funktionen nichts mit der alten Welt von WebSphere zu tun, sodass die Laufzeit selbst überraschend leicht und kompakt ist, sehr schnell startet und in Sekunden bereitgestellt werden kann. Wenn Sie also eine moderne Java EE-basierte Anwendung haben, können Sie Ihre Funktionen entsprechend konfigurieren und nur die Standards einbeziehen, die wirklich benötigt werden. Unabhängig davon, ob Sie kommerzielle Funktionen verwenden, haben Sie immer noch Zugriff auf diese schnelle und moderne Laufzeit.

Oleg: Im Oktober veröffentlichte Oracle Helidon, ein leichtes Microservice-Framework in Java. Soweit ich weiß, verwendet es keinen der vorhandenen Anwendungsserver, sondern baut auf eigenen Bibliotheken auf. Zusammen bilden sie die Grundlage für den Aufbau von Microservices - Funktionen für die Konfiguration, Sicherheitseinstellungen, das Erhöhen des Webservers usw. Zusätzlich zu diesem System wurde MicroProfile sogar implementiert. Ich hatte den Eindruck, dass die Helidon-Entwickler der Meinung sind, dass Java EE zu viel Vermächtnis hat und verworfen und neu geschrieben werden muss. Was denkst du darüber?

Sebastian: Helidon ist ein sehr interessantes Projekt. Aber um ehrlich zu sein, erscheint es mir naiv zu denken, dass Java EE komplett neu geschrieben werden muss. In der Tat benötigen die meisten Anwendungen kein Java EE als Ganzes. In der Regel sind spezielle Funktionen / Standards erforderlich, die am häufigsten in Unternehmensanwendungen verwendet werden. Beispielsweise bietet ein reguläres MicroProfile noch kein JPA oder komplexe Skripte für Multithreading. Dies erfordert mindestens einige Java EE-Komponenten. Im Allgemeinen sehe ich jetzt den Prozess des Erstellens einer Anwendung auf diese Weise. Basierend auf den wichtigsten und modernsten Komponenten von Java EE, z. B. CDI, JPA, JAX-RS, JTA usw., wählen wir die benötigten Standards aus und ignorieren dabei die vielen vererbten Dinge, die in Java EE vorhanden sind. Basierend auf dieser Auswahl verwenden wir die Laufzeit, die alle diese Funktionen unterstützt. Wenn wir etwas im Zusammenhang mit Cloud-nativen Microservices tun, fügen wir MicroProfile-Standards hinzu, z. B. Fehlertoleranz. Eine Laufzeit wie Helidon unterstützt jedoch keine Funktionen, die ausschließlich zu Java EE gehören, und Multithreading oder JPA sind Funktionen, die meiner Erfahrung nach sehr wichtig sind. Ich würde eine Laufzeit bevorzugen, die sowohl Java EE / Jakarta EE als auch Microprofile unterstützt und gleichzeitig die Möglichkeit bietet, die Funktionen auszuwählen, die für eine bestimmte Anwendung benötigt werden. Wenn Sie beispielsweise Persistenz benötigen und über eine Datenbank verfügen, können Sie JPA aktivieren. Im Allgemeinen verfügen Sie über einen Funktionsumfang, der MicroProfile sehr ähnlich ist, es ist jedoch auch etwas von Java EE erforderlich. Diese Laufzeiten sind Open Liberty, Payara, WildFly und so weiter.

Oleg: Soweit ich weiß, ist die Unterstützung moderner Cloud-Technologien eine der interessantesten Funktionen, die in naher Zukunft in Jakarta implementiert werden. Was ist jetzt mit Java in Containern? Soweit ich mich erinnere, gab es vor einigen Jahren auf dem OpenJDK-Bug-Tracker mehrere Fehler in Bezug auf Kompatibilität, Heap-Größe, Signale usw. Ist es jetzt möglich, Java 2019 in Containern zu verwenden?

Sebastian: Ja, definitiv ist es das. Der Grund für die meisten damit verbundenen Probleme war nicht Java selbst, sondern die Art und Weise, wie Linux mit Containern arbeitete. Oft wusste der Container einfach nichts über die verschiedenen Ressourcenbeschränkungen, die festgelegt werden konnten. In neueren Versionen wurden diese Probleme behoben. Jetzt können Sie einfach Java im Container ausführen, und diese Optionen sind standardmäßig aktiviert. Wenn Sie nach der Größe des Speichers im System oder der Standardgröße des Heapspeichers fragen, werden diese Werte korrekt angegeben. Java EE funktioniert hervorragend in Docker-Containern und lässt sich im Allgemeinen gut in Cloud-native Technologien integrieren.

Oleg: Was ist mit der Infrastruktur? Verwenden Sie so etwas wie Kubernetes oder Istio?

Sebastian: Ja, ziemlich aktiv. Docker, Kubernetes, — Istio. Java EE. Cloud-native , , , — , , , ..

: Java EE Kubernetes ? API ?

: Kubernetes Istio . cloud-native . . , Docker, Kubernetes. , - URL, . Kubernetes DNS Istio. . , — -, .

: Java ?

: — Java , . , enterprise- — MicroProfile, cloud-native (Istio, Kubernetes). MicroProfile , . , .

: JPoint « Java Enterprise». ?

: , enterprise-, . — - ; — . Java EE-, , , , .

JPoint. , — . Java-, — .

: . (, «» ). Linux, : ?

: . Linux , , , , . , , . , , . , , . Arch Linux — , . Linux . Ubuntu UI, . — Linux , , , . , , , .

: !

, 5-6 , JPoint «Bulletproof Java Enterprise applications for the hard production life» . Simon Ritter, Kohsuke Kawaguchi, . .
.