CRE090 Java

Ein Überblick über die Java-Plattform

Episode image forCRE090 Java

Gut 12 Jahre nach Markteinführung hat die Java-Platform sich in einem Maße etabliert, dass sie nicht mehr vom Markt wegzudenken ist. Doch nicht alle angestrebten Märkte konnte die von Sun Microsystems entwickelte Plattform für sich vereinnahmen - trotzdem ist Java ein wichtiger Baustein der heutigen IT-Infrastruktur.

Im Gespräch mit Tim Pritlove bieten die Java-Entwicklern Dirk Jäckel und Boggle einen Überblick über die heutige Situation der Java-Platform und erläutern Vor- und Nachteile, Realitäten und Anwendungsmöglichkeiten von Java. Konkret kommen zur Sprache: die Entstehungsgeschichte von Java, Aufstieg und Fall von Java im Web, die Java-Distribution, die Funktionsweise und Optimierungen der Java VM, die Geschwindigkeit der Java VM, Speicherverwaltung und Garbage Collection, die Features und Schwachstellen der Java-Programmiersprache, Integrierte Entwicklungsumgebungen (IDE) für Java, Werkzeuge für die Softwareentwicklung mit Java, Das Lizenzmodell und alternative Java-Implementierungen, Groovy und andere alternative Programmiersprachen für die Java-VM, der Community-Prozess für Java, Entwickeln für mobile Platformen mit J2ME und für Server mit J2EE.

avatar
Tim Pritlove
avatar
Boggle
avatar
Dirk Jäckel
Shownotes

Links:

70 Gedanken zu „CRE090 Java

  1. War auf jeden Fall ein guter Überblick über alles was es so gibt und für mich auch einiges neues dabei. Eine Anmerkung hätte ich noch zu machen: JavaEE kann man sich nicht wirklich downloaden, es ist vielmehr eine Spezifikation welche von den unterschiedlichen Application Servern (Websphere, JBoss, Tomcat, Glassfish, …) implementiert wird. Auf diesen laufen dann eben dann z. B. die EJBs.

  2. Ich arbeite schon relativ lange selbst mit Java und hätte mir persönlich speziell bei den Enterprise Sachen ein wenig mehr Tiefgang gewünscht. Aber es ist auch ein sehr umfangreiches Feld.

    Der Podcast hat mir auf jeden Fall die Wartezeit bim Arzt gerade etwas verkürzt.

    Nochmal zur J2EE. Was man sich da holt um zu entwickeln sind im Prinzip nur die entsprechenden Servlet-Klassen und zugehörige Interfaces von denen man ableitet, bzw. die man implementiert. Das ist in der Regel ein einziges JAR-File. Die Hauptarbeit findet dann allerdings wie schon von Tom erwähnt in den Application Servern statt.

  3. @VM Damals:
    Pascal!! Die Pascal P4 Maschine ist ein Vorbild für die Java VM gewesen. Ist sogar sehr ähnlich. Haben wir in der Lehrveranstaltung „Abstrakte Maschinen“ gelernt.

  4. Ich möchte auch noch folgendes loswerden:
    Ich mag Java, als Sprache. Aber ich finde J2EE überbewertet. Gut, ich habe jetzt nicht wirklich Erfahrung aber J2EE empfinde ich als extrem umständlichen bloat. Höllisch zum Debuggen. Was man sich da quälen muss, um etwas auf die Beine zu stellen was man in Ruby-on-Rails oder TurboGears mit ein zwei Handgriffe fertig hat! Brr. Ich mag Javas JIT, Annotations, Code Generation (cglib), anonymous classes, reflection etc. Aber z.B. JSF is extrem umständlich. Finde ich sehr unelegant und bringt einen dazu redundanten Code zu schreiben. Alle HTML Elemente heißen irgendwie anders un man muss alles neu lernen. Da finde ich CherryPy (verwendet bei TurboGears) viel eleganter. Dort kann man von einer anderen Seite „ableiten“ und z.B. den title überladen und einen body einfügen etc. Mach sowas mal mit JSF!

    Ok, es gibt plugins mit denen das einfacher geht. Aber wir mussten an der Uni ohne solche plugins auskommen. Und glassfish. Brr. Wirklich tolle sprechende Fehlermeldungen. lol Ja, das Webinterface ist schon klasse, aber man muss echt lange lernen was der *wirkliche* Fehler sein könnte, wenn Fehlermeldung X kommt. Wenn du z.B. einen EJB in deinen Archiv hast. Du hast ihn korrekt annotiert und alles. Aber du refernzierst eine Klasse dies auf dem Server net gibt. Dann kommt nicht etwa die Meldung, das eine Klasse referenziert wird, die es nicht gibt, sondern dass kein EJB in dem Archiv gefunden wurde. Wtf, ich hab einen Bean drin? Da sucht man lange bis man da drauf kommt. Und ich hatte noch viel mehr Probleme mit dem *#!$% glassfish bei der Übung zur Lehrveranstaltung „Technologien für Verteilte Systeme“. Naja, hatte mit den 2 anderen Übungsteilen schon genug Punkte. (Hibernate ist besser (korrekter, vollständiger) als TopLink, aber Glassfish verwendet TopLink.)

    Vieleicht ist ja alles mit JBoss viel viel besser.

  5. Natürlich nennt man „das“ Linken. Nicht statisch, ja. Aber es gibt tatsächlich einen „LinkerError“. Aber nur in sehr wenigen Fällen. Kann jetzt auf die schnelle keinen absichtlich provozieren.

  6. @Basistypen: Ich nen die „builtin“ Typen. ;) Aber der richtige Name ist „primitive“ type. (Gibt auch die Methode isPrimitive() bei Class Objekten.)

    Und ja, List-Comprehension (vor allem mit Lazy Lists) fände ich sehr sehr Praktisch. So wie’s das in Haskell, JavaScript, Python, Ruby, … gibt. Und closures so wie sie in Ruby existieren wäre natürlich auch net. Und Generatoren (also das „yield“ Statement), so wies das in Python, Ruby, C#, JavaScript (und Groovy?) etc. gibt.

    Wozu man closures schön verwenden kann:
    xm = Builder::XmlMarkup.new
    xm.instruct!

    xm.items do
    sql = ActiveRecord::Base.connection()
    items = sql.execute(’select id from items where external_id is null‘)
    for item in items
    xm.item do
    xm.id item[‚id‘]
    end
    end
    end

    render :xml => xm.target!

    (Kein schöner Rails Code, aber darum gehts jetzt net.)
    Das generiert den XML Code (natürlich nicht so schön formatiert, per default):

    1
    2
    3

    Damit braucht man kein embedded XML oder so was spezielles, und man kann trotzdem den XML Baum in eine Ruby-Syntax abbilden. Man kann hier auch keinen End-Tag vergessen! Wieder das selbe wie mit dem (nicht) vergessen eine Datei (auch im Exception fall) zu schließen.

  7. Ok, da hats mir den XML Code gefressen. Nochmal:
    <?xml version=“1.0″ encoding=“utf-8″?>
    <items>
    <item><id>1</id></item>
    <item><id>2</id></item>
    <item><id>3</id></item>

    </items>

  8. @Tim und wozu Annotations gut sind:
    Annotations werden extrem viel in J2EE verwendet. Z.B. für Dependency Injection. Also wenn ich einen Bean schreibe, den ich in einen J2EE Container hosten will, dann kann der gewisse Kontestinfos bekommen (muss aber nicht). Weil da ja Inversion of Control eine Rolle spielt (don‘ call us, we call you) „lässt“ man sich die dependencies injection (anstatt das man sie holt). Also ich hab Bean A und will da drinn auf Bean B zugreifen. B kann wo anders gehostet sein, kann Stateless oder Stateful sein oder was auch immer. Ist mir Wurscht. Ich will eine Referenz darauf. Ich weiß auch garnet die Implementierungsklasse, nur das Interface. Dann deklarier ich dieses Feld in meinen Bean A:
    @EJB private B b;
    Und fertig. Sehr Praktisch. :)

    Ich hab auch mal was mit Annotations geschrieben, einen Option Parser: http://twoday.tuwien.ac.at/pub/stories/305002/ (ziemlich praktisch, oder nicht?)

    Ok, ich hör auf zu spamen und lerne wieder für den Test morgen.

  9. Wie immer schöner Podcast!

    Zu J2ME/PhoneME:

    PhoneME ist die OpenSource Implementierung der CDC,CLDC,MIDP,Foundation,Personal Basis und Personal Profile. J2ME darf es sich erst nennen, wenn es durch die Test Suite von Sun gegangen ist.

    Es gibt einige Platformen für die J2ME verfügbar ist, die aber nicht Open Source sind, z.B. die J2ME Implementationen für Nokia S40 Geräte.

    Für Mac (PowerPC) gibt es eine Version von Phoneme Advanced (entspricht J2ME CDC mit Foundation/Personal Basis/Personal Profil). Für Phoneme Feature (=J2ME CLDC/MIDP, das was auf den meisten Telefonen ist) gibt es das bisher nicht. Für den Advanced Stack habe ich einen Port auf Mac OSX Intel gemacht, der demnächst auch in das offizielle Repository kommen soll. Wer das schonmal ausprobieren will, Sourcen und Binarys gibts hier: http://markus.heberling.net/lang/de/2008/04/25/phoneme-advanced-on-osx-intel/

    @panzi
    Der Optionsparser sieht echt ziemlich praktisch aus. Werde ich mir mal beizeiten anschauen.

  10. Und zu GPL und linken und so:

    J2SE steht unter der GPL+Classpath-Exception, die erlaubt explizit das „Linken“ zu den Java Core APIs.

    Im Gegensatz dazu steht PhoneME unter der GPL ohne diesen Zusatz, mit der Begründung, dass die meisten Implementationen sowieso von den Geräteherstellern vorgenommen werden, und die können sich dann aus der GPL rauskaufen. Ich seh das etwas anders, aber gut so ist das im Moment.

  11. Hm, also *nur* GPL hat aber auch Auswirkungen auf BSD Code. Der wird dann eben auch automatisch zu GPL. Sowas wie Trolltechs QPL wäre wohl besser, das erlaubt jede Art von freier Software, also z.B. auch LGPL. Für proprietäre Software muss man dann immer noch zahlen.

    QPL bei der allwissenden Müllhalde: http://de.wikipedia.org/wiki/QPL

  12. Zum Thema IDE und JBuilder:

    Borland hat vor einiger Zeit seine ganze IDE Sparte in eine eigene Firma ausgegliedert (Codegear). Die Entwicklung dieser wurde allerdings nicht eingestellt.

    So ist vor Kurzem der JBuilder 2008 erschienen. Dieser basiert zwar nun auf eclipse, bietet aber noch weiterführende Funktionalität. Für Einzelentwickler bietet Codegear auch eine kostenlose Version – genannt Turbo – an, die leider um einige Moddelierungsfunktionen beschnitten ist. Diese gefällt mir selber dennoch besser als das Standard-Eclipse (und NetBeans).

  13. Wozu dient eigentlich diese VM? Man könnte doch einfach direkt in die Maschinensprache des Prozessors übersetzen.
    Der Java-Bytecode ist doch scheinbar unnütz, da er per JIT sowieso in Maschinensprache umgewandelt wird.

  14. Klar kann man direkt in Maschinenspreache des Prozessors übersetzen. Dann läuft die Anwendung aber auch nur noch auf diesem Prozessor.

    Wenn man hingegen erst in Bytecode übersetzt, und erst zur Laufzeit in Maschienensprache, dann läuft die Anwendung unverändert auf allen Systemen auf denen es eine VM gibt.

    Ausserdem kann man dann auf jeder dieser Systeme eigene Optimierungen durchführen. Wenn du ein C Programm so übersetzt, dass es auf allen x86-kompatiblen Rechnern läuft, dann verliest du alle Optimierungsmöglichkeiten die über den x86 Standart hinausgehen. Und auf PPC oder MIPS oder ARm oder wasweissich läufts dann auch nicht mehr. Bei Java reicht ein Jar für alle Systeme.

  15. Danke für den Podcast, hab mich darauf gefreut wie ein kleines Kind. :)

    Um die Scriptsprachen noch zu ergänzen: Es gibt noch PHP 5 in Java und das nennt sich Quercus http://quercus.caucho.com/ und ist vorallem auf dem Resin Java App Server gross geworden. Das schöne daran ist wiederum, dass sich nun mit PHP Java ansprechen lässt. Somit könnte man für Frontend PHP/HTML machen und im Background die Logik in Java haben.

    Es gibt einige Vorteile wenn man PHP in Java und nicht in C hat. Siehe http://quercus.caucho.com/quercus-3.1/doc/quercus.xtp#Benefits%20of%20Quercus

    Have PHun!

  16. Als Ergänzung zu JVM:

    Es gibt ja nicht nur die Möglichkeit Java in Bytecode in der JVM laufen zu lassen, sondern auch mittels GCJ http://gcc.gnu.org/java/ in Maschinencode zu übersetzen.

    Leider benutzt(e) GCJ bis anhin die unvollständige GNU Classpath und nicht SUNs Java. Somit können featurereiche Programme nicht übersetzt werden.

  17. Also, dass die beiden nicht Smalltalk nennen konnten, als sie nach dem VM-Konzept gefragt wurden, ist schon ein wenig traurig. Java ist eine Mischung aus Smalltalk und C++: VM-Konzept, Klassenframework-Konzept, Reflection und Single Inheritance von Smalltalk, Syntax und statische Typisierung von C++. Smalltalk war in jeder Hinsicht seiner Zeit voraus: VM, Objektorientierung, dynamische Typisierung, Closures und wird heutzutage plötzlich wieder in Form von des viel gehypten Ruby „neu erfunden“. Es ist nicht verwunderlich, dass die Design-Pattern-Gurus der „Gang of Four“ und Kent Beck („eXtreme Programming“) aus der Smalltalk-Welt kamen. Der Erfolg von Java hätte eigentlich Smalltalk zugestanden, Java könnte man im Vergleich dazu beinahe als Rückschritt ansehen, aber durch die C-artige Syntax konnte man wohl leichter C++-Programmierer für sich gewinnen.

  18. @fred Hab ich durchaus dran gedacht, nur die lisp machine war IMHO halt etwas früher, ergo hab ich die erwähnt. Ansonsten ist der Kommentar richitg. Neben der C-Syntax gab es schon andere, glückliche Begleitumstände für Java, wie the Rise of the Web und Sun’s intelligente Strategie, Märkte zu schaffen, indem man offene Standards definiert (was ja jeweils einige Vorleistung erfordert).

  19. @panzi:
    Borland macht sein Geld vorallem im Bereich Software Development Life Cycle und Application Lifecycle Management. Also mit Lösungen zur Projektplanung, Modellierung und Verwaltung.

    Die IDEs waren zeitweise sogar ein Verlustgeschäft für Borland, weshalb sie auch in CodeGEAR ausgelagert wurden. CodeGEAR hat es afaik mittlerweile geschafft das Ruder herumzureißen und mit ihren Produkten wieder Gewinn zu erzielen.
    Nun sollen sie jedoch offenbar für 23 Mio US-$ an das kalifornische Softwarehaus „Embarcadero“ verkauft werden.

    Mal sehen, was draus wird.

    Gruß Hador

  20. Ich möchte hier nochmal drauf hinweisen, das J2EE wesentlich mehr als EJB ist, auch wenn diese Technologie am bekanntesten/vielleicht auch am verbeitetsten ist. Zu J2EE gehören u.A. auch: JMS (Messaging, Komplett separat, in gewisser Weise orthogonal zu EJB), JAX-WS und SAAJ (Webservices), JAXB (XML-Bindings), Java Mail, Servlets/JSF (Webapps), JPA (ORM/Persistenz), JTA (Transaktionen) und die Management-APIs. Es sind J2EE-Architekturen möglich, die komplett ohne EJBs auskommen. Sowas gibt es auch durchaus in der Praxis.

  21. @boggle, J2EE
    Jo klar. Wenn ich EJB sag mein ich fälschlicher Weiße auch gleich JMS, Servlets/JSF, JAX-WS (Webservices sind Stateless Session Beans) und wie der ganze Bloat noch heißt. Ich finde die Ideen hinter den jeweiligen Modulen extrem gut, die Umsetzung kommt mir jedoch extrem bloated und umständlich vor. Mit den Annotations wurde zwar viel besser, ganz gut ist es aber noch lange nicht (aus meiner subjektiven Sicht). Man sollte sowas wie Ruby on Rails mal mit Java implementieren. Sprich ich sollte mir mal Grails und Sails (<- wirkt aber tot?) anschauen.

  22. Danke für den tollen Podcast! Ich mag Java und bin froh, dass hier nicht die ganze Zeit darauf herumgehackt wurde, von wegen Geschwindigkeit, fehlender Mehrfachvererbung, C++ ist sowieso besser, usw…

    Weiter so!

    Viele Grüße aus Österreich.

  23. Wieder einmal vielen Dank für diesen schönen Podcast.

    Als nahezu ausschliesslich mit Java hantierender Software-Techniker hätte ich natürlich an diversen Stellen meine Anmerkungen los werden wollen (wie z.B. das hier bereits erwähnte Fehlen der Erwähnung von Smalltalk als Vorbild), abe insgesamt war ich angenehm überrascht.
    Besonders was Tim angeht :) Du lässt ja ungerne ein gutes Haar an Java und das was Du (wohlgermerkt als Moderator!) zu diesem Thema gesagt hast gefiel mir sehr gut.

    Java ist alles andere als perfekt, bietet mir – allen Schwächen zum Trotz – aktuell aber die interessanteste Plattform für die Entwicklung grösserer Software-Systeme.

    Java als Sprache ist unbestritten bestenfalls ein guter Kompromiss. Die JVM als Kitt zwischen vorhandenen, bewährten Bibliotheken und ausdrucksstärkeren Sprachen wie Groovy, Ruby, Phython oder Scala zu sehen führt bei der Bewertung am weitesten – das habt ihr ja auch sehr gut dargestellt.

    Ich hatte hier eher ein Rant auf die Sprachschwächen und andere Hässlichkeiten erwartet :)

    Was ich noch erwähnen würde ist tatsächlich der kostengünstige Einstieg:

    . Java war schon immer frei verfügbar, die JDK-Sourcen inklusive,
    ohne die viele APIs (für mich) kaum zu benutzen waren.
    Das ist zwar kein OpenSource, aber wenigstens hatte man schon
    immer die Sourcen verfügbar!

    . Es gibt diverse mittlerweile recht ausgereifte Entwicklungsumgebungen,
    die kostenlos verfügbar sind und auch ohne ‚Enterprise-Aufpreis‘
    datenbankbasierte Applikationsentwicklung erlauben

    . Es gibt sehr gute frei verfügbare Tutorials und Quellen die einem
    einen schnellen Einstieg erleichtern

    . Es gibt für die meisten APIs und Specs frei verfügbare Implementierungen,
    D.h. ich bekomme selbst einen ge-clusterten Applikationsserver kostenlos und im Source

    Ich habe das mal mir .NET versucht und bin dann unter Linux dann an der GUI-Entwicklung gescheitert: Mono ist ziemlich weit, aber portable GUIs habe ich bisher nur in Java hinbekommen. Das Thema GUIs in Java ist auch kein rühmliches, aber mit aktuellen Techniken und viel Einarbeitungszeit bekommt sehr ansehnliche GUIs hin die wirklich überall laufen – selbst auf dem Mac, dessen Java-Geschichte auch seine Hochs und Tiefs hat (im Moment stecken wir in eine Tief…).

    Was die Weiterentwicklung von Java angeht, würde ich mich dem gesagten anschliessen und würde sogar noch weiter gehen: lasst es wie es ist. Closures in Java wären z.B. schön, aber es nützt alles nichts, wenn man die JDK-Libraries nicht entsprechend umbaut.

    Die Gernerics waren/sind schon grenzwertig – ich denke die Entscheidung für Type Erasure war die richtige, wird aber auch zu Recht kritisiert. Dasselbe – vielleicht noch schlimmer – wird u.U. mit Closures passieren. Wer weiss.

    Vielleicht noch einmal für alle die mit Closures und ‚anonymen Funktionen‘ nix anzufangen wissen. Klassiker der JDK-Lib ist das Interface Runnable, was eine Implementierung des Command Entwurfsmusters ist: ein Stück Code den man als Parameter in eine Methode stecken will:

    interface Runnable {
    void run();
    }

    Ein entsprechende Methoden-Signatur sähe dann etwa so aus:

    Thread(Runnable task)

    D.h. einem Thread übergebe ich das was er ausrühren soll, also etwa

    new Thread(
    new Runnable() {
    public void run() {
    System.out.println(„Hello world…“);
    }
    }).start()

    Das ist der erwähnte ‚Boiler Plate Code‘. new Runnable(), d.h. anonyme (weil namenlose) inner classes gibt es erst seit Java 1.2, was besonders für Event Handler im awt wichtig war.

    Man würde lieber so etwas schreiben wollen:

    new Thread( { System.out.println(„Hello world…“) } )

    was so in etwa auch in Groovy aussieht.

    Invoke Dynamic wäre cool und mit solchen JVM-Erweiterungen lieber die ausdrucksstärkeren Sprachen voran bringen. Dass es abgesehen von IntelliJ keine funktionierende IDE-Unterstützung für Groovy gibt ist übrigens traurig. Sun hat seine Anstrengungen lieber in Ruby und JavaScript gesteckt – nachvollziehbar, aber enttäuschend für jemanden, der es vermeidet sich im Web-Bereich zu vergnügen (muss wohl doch nochmal die Kohle für IntelliJ locker machen…)

    Nochmal vielen Dank für Eure Mühe mit dem Podcast und hier noch ein paar URLs zum Thema:

    http://www.javoxx.com (ehemals http://www.javapolis.com)
    Sehr gute Vorträge zum Thema Java sowohl Video als auch Podcast
    (javapolis.podomatic.com)

    http://www.javapuzzlers.com
    DIE Grundlage für Rants auf Java :)

    http://www.theserverside.com
    http://www.infoq.com
    Informationen zu Server Side Java (and more…)

    http://www.javaworld.com/podcasts/jtech/
    Java World Podcast, ab und zu ganz interessante Interviews

    hansamann.podspot.de/rss
    Grails Podcast, Germish, d.h. English mit deutlichem Akzent.
    Nicht jedermann’s Sache, bietet aber ein wenig Unterhaltung in Sachen Groovy

    http://www.nabble.com/codehaus—Groovy-f11866.html
    Groovy Mailing List

    http://www.groovy-forum.de
    Deutsches Groovy & Grails Forum

    Marcus

  24. Erst einmal Danke für diesen informativen Podcast.
    Wenn man sich Java so anschaut, glaubt man fast, dass es aus allen Nähten platzt.
    Neue Sprachfeatures schön und gut, nur wollen diese Features auch beherrscht sein. Und dann stellt sich die Frage bei all den Entwicklungen: Quo vadis Java?
    Zum Schluss noch ein kleiner Java Song, der zum Podcast passen dürfte:
    http://stud4.tuwien.ac.at/~e0508142/fun/JAVATheSong.mp3

    Viele Grüße
    Compiler

  25. Ich möchte mich für den Podcast auch bedanken! Chaos Radio habe ich erst vor ein paar Wochen entdeckt und höre nun haufenweise Podcasts (extra nen mp3 Player zugelegt :-) weiter so!

    @Java: Ich habe Mehrfachvererbung im Zusammenhang mit dem Observer Pattern schmerzlich vermisst. „Observable“ z.B. ist kein Interface, sodass ich das nicht einfach mal eben zu meiner Klasse „dazu erben“ kann (Stichwort Mixin- Klasse), wenn diese bereits von irgendetwas anderes geerbt hat.

  26. bzgl. Observerpattern:

    Ich verstehe das Problem nicht. Üblicherweise macht man sich ein sinvoll benanntes Interface, und implementiert dieses dann in den entsprechenden Klassen. Das lässt sich ohne Probleme in Java umsetzen. Die Instanzen dieser Klassen können dann dem „Notifier“ hinzugefügt werden. Dieser kann dann die gesetzen Objekte via Methoden aus dem Interface benachrichtigen.

    Dirk

  27. Ich habe die fertigen Konstrukte aus dem Java util Packet gemeint. Klar kann man jedes mal alles selber implementieren (beim Observer macht das in der Tat nicht soo viel Aufwand, es ), aber mit Mehrfachvererbung könnte man an dieser Stelle Arbeit und Codeverdopplung sparen.

  28. Java ist schon eine coole Sache. Aber für serverseitige Webanwendungen bevorzuge ich trotzdem PHP. (Man kann auch mit PHP sauber programmieren)

    Für Desktop Anwendungen eignet sich auch .NET ganz gut. Weil das bisher ganz vergessen wurde.

  29. Pingback: Java News | News | Programmierung & Software Entwicklung Java J2ME Android

  30. @Markus
    Klar, theoretisch ist das ein Vorteil. Aber doch nur, wenn ich mein /usr/bin zwischen Rechnern unterschiedlicher Prozessorarchitekturen teile. In der Praxis ist es doch so, dass ich eine Binärdatei pro Rechner habe. Im Serverbereich hat man sogar oft dutzende von identischen Rechnern. Warum sollte ich mir den Quellcode laden, dann erst in ein Zwischenformat übersetzen und dann von diesem Zwischenformat zur Laufzeit zur Maschinensprache gehen.

  31. Klar, wenn du den Quellcode hast kannst du das machen. Aber es soll ja auch so böse Sachen geben, wie kommerzielle Programme, wo du den Quellcode nicht hast. Wenn die in Java sind, kann da trotzdem optimiert werden.

    Ausserdem gibt es genug Enduser, die nicht mal wissen, wie man compilieren schreibt, die haben also überhaupt keine Chance die volle Performance zu bekommen. Die werden sich die angebotenen Binärpakete installieren und gut ist. Und wenn sie nicht das passende System für diese Pakete haben, haben sie Pech gehabt und können die Software nicht nutzen.

    Für den Anbieter der Software hat es zudem den Vorteil, dass er nicht für alle möglichen Betriebssysteme eigene Binärpakete bereitstellen muss, sondern eins für alle ausreicht.

  32. @Christoph
    Auch ich programmiere häufig und viel OOP in PHP und versuche, meinen Code an MVC anzulehnen. Meine Erfahrungen an „Standart“-Software wie z.B. PHPmyAdmin, WordPress, etc sind, dass sie eher nicht den bekannten akademischen Leitsätzen von Softwareentwicklung (uml, patterns, mvc, separation of concerns, usw) entsprechen. Stattdessen wird einfach mal drauf los programmiert.

    Java zwingt dich mehr dazu, dich über solche dinge gedanken zu machen und daher ist Software in Java in der Regel „sauberer“ und durchdachter.

  33. Irgendwie war die erste Hälfte des Podcasts suboptimal. Am Anfang wollte ich quasi Smalltalk in den Monitor schreien, aber das wurde hier ja schon erwähnt. Die Erklärung von Garbage Collectoren, obwohl vom Inhalt richtig, war auch eher verwirrt.

    Bzgl. JVM Startup-Zeiten: VisualWorks Smalltalk startet ohne irgendeine Verzögerung. Wenn man mit SBCL (Steel Bank Common Lisp) ein Core-File startet, gibt es auch quasi keine Verzögerung. Der JVM Startup ist einfach auch im Vergleich zu ähnlichen Systemen pervers langsam.

    Bzgl. der Java-Sprache: „Java ist das neue COBOL.“ … Daß Java an vielen Hochschulen gelehrt wird, hilft nicht dabei gute Java-Programmierer zu finden. Gute Java-Programmierer gibt es genauso selten wie gute XY Programmierer. Java zu benutzen ist nur vorteilhaft, wenn man Horden von Dummy-Programmierern anstellen möchte. Das ist leider Realität und so sieht dann auch die Qualität vieler Java-Software aus…

    Bzgl. Eclipse: Eclipse hat einen Fortschrittsbalken für das Erstellen einer neuen Klasse, den man sich auch wirklich bewegen sieht, wenn man gerade nicht an einer Kiste mit zwei Gigabyte RAM und nem Dual-Core sitzt… Für das Erstellen einer Datei von einem Template ist das schon sehr hart… Wer Common Lisp mit Emacs/SLIME programmiert, hat _viel_ handlichere Tools bei der Hand, und das läuft auf praktisch jedem Rechner der letzten 15 Jahre…

  34. Zum Thema „Der JVM Startup ist einfach auch im Vergleich zu ähnlichen Systemen pervers langsam.“ habe ich mal kurz auf meinem MacBook Pro die Startup + Ausführzeit von HelloWorld gemessen:

    java HelloWorld 0,15s user 0,07s system 103% cpu 0,212 total
    java HelloWorld 0,15s user 0,07s system 102% cpu 0,213 total
    java HelloWorld 0,15s user 0,07s system 98% cpu 0,222 total
    java HelloWorld 0,15s user 0,07s system 103% cpu 0,210 total
    java HelloWorld 0,15s user 0,07s system 97% cpu 0,228 total
    java HelloWorld 0,15s user 0,07s system 102% cpu 0,214 total
    java HelloWorld 0,15s user 0,08s system 100% cpu 0,230 total

    Mir ist ehrlich gesagt unklar, was an 200 – 230 Millisekunden „pervers langsam“ sein soll. Sicher sind andere schneller, aber alles unter einer Sekunde merkt ein normaler Anwender eh nicht.

    Wie lange braucht denn so ne Smalltalk- oder LISP-VM dafuer?
    Welche freien oder zumindest kostenlosen empfehlenswerten IDEs und VMs gibt es eigentlich für Smalltalk oder LISP?

    Vielleicht mag Tim ja mal ne Sendung über Smalltalk machen? Aus der LISP-Sendung habe ich mitgenommen, dass die vernünftigen Tools sauteuer sind. Man korrigiere mich bitte!

    Dirk

  35. 200 Millisekunden auf einem Macbook für HelloWorld soll nicht langsam sein? Also bitte.

    Ich gehe mal davon aus, dass dein Macbook mit ca 2GHz und zwei Cores daherschiesst und somit also ca 4 Milliarden Taktzyklen pro Sekunde hat. Deine Java-VM braucht knapp eine Milliarde davon, um überhaupt zu starten und „Hello World“ auszugeben und das findest du nicht langsam?! mach mal den Vergleich mit C, perl oder meinetwegen einem Bashscript, das liegst du Faktoren drunter.

    Ich weiss nicht, was dieser ganze Javabloat soll, der auf Handies 10 Sekunden braucht, um ein blödes Pokerspiel zu starten. Der als Plattform für Homeentertainment (MHP) mit dem Versuch, einen Embedded-ARM-Core mit 10MB grossen Binärmüll zu verwirren, mehr als gründlich versagt hat. Der als GUI-Applikation auf allen mir bekannten Betriebssystemen zum kotzen aussieht und sich immer wie ein Fremdkörper verhält. Kein Mensch braucht das ausserdem im Web, weder im Browser noch auf der Serverseite. Weder aus Gründen der Performance noch aus der der Ästhetik. Wartbarer ist es auch nicht.

    Versteht mich nicht falsch, ich behaupte nicht, dass es nicht verwendet wird und dass man es deshalb nicht verstehen sollte oder man dabei nichts lernen kann. Aber brauchen, in dem Sinn, dass es irgendetwas bietet, was sich anders nicht schlanker, performanter, besser und überhaupt leichter verständlich erledigen lässt, tut das keiner.

    Daniel

  36. Was in meinem Posting grade gänzlich unterging, ist, Euch für den Podcast zu danken. Informativ und schön erklärt war es allemal – meine Kritik richtet sich ausschliesslich an die Sprache als solche, ihrern mit unerklärlichen Stellenwert auf dieser Welt, die zusammengerechnet vielen Stunden Wartezeit, die mich das bisher schon gekostet hat.

    Daniel

  37. @Daniel

    Es ging um den Vergleich zu Smalltalk oder LISP also hohen Programmiersprachen. Leider hast Du zum Thema mit deinem Kommentar nichts beigetragen.

    Warum programmierst Du nicht alles in Assembler, wenn es Dir nur auf optimierte Geschwindigkeit und Kompaktheit ankommt? C ist doch eigentlich auch schon „Bloat“ und ineffizient?

    Dirk

  38. (SBCL, Linux, Core Duo)
    % time ./sbcl-hello-world
    Hello World!
    ./sbcl-hello-world 0,00s user 0,00s system 59% cpu 0,011 total

    SBCL kostet nichts. Eine Smalltalk VM habe ich gerade nicht bei der Hand.

  39. Kurze praktische Frage: In der Sendung wurde ein RSS-Reader für J2ME angesprochen. Links werden im Standard-Browser geöffnet. Da stellt sich für gleich die Frage, wie kommt man zu seinem RSS-Reader zurück? Ich kenne Java-Anwendungen auf meinem Handy als relativ schwerfällig. Auf meinem Nokia ist sogar der Taschenrechner eine Java-Anwendung. Wenn ich mir nun vorstelle, ständig zwischen zwei Apps wechseln zu müssen … Hinzu kommt noch, dass die Anwendungen bei Nokia ja tief in den Menüs versteckt sind.

    Die Aussage von Tim (war bestimmt nur ein Versprecher) fand ich lustig: Wenn OpenSource dann auch auf allen Plattformen (im Zusammenhang mit Emulatoren für die Entwicklung von J2ME-Anwendungen auf dem Mac). :-D

  40. Vielen vielen Dank fuer CRE im Allgemeinen und fuer die Sendungen zu Programmiersprachen im Speziellen! Ich hab das Archiv vor ein paar Wochen gefunden und mitlerweile fast alle alten Sendungen nachgehoert.

    Ich interessiere mich auch sehr fuer das Analyse-Tool, dass beim refactoring in layers helfen soll. Bitte bitte moeglichst bei Dirk und Boggle nerven und noch an die show notes anhaengen.

  41. @Kay

    Die Funktion heisst platformRequest(String url) und unter Nokias Series60 Platform ist es keine Problem zum RSSBrowser zurückzuwechseln. Der wird durch den Wechsel nicht beendet. Deshalb kann man leicht zurück. Da gibts so ne Applikations-Taste. Wenn man die gedrückt hält kommt man in die Liste der laufenden Aplikationen.

    Dirk

  42. @dirk: Ah, ok. Ich habe nur ein billiges 3110 ich glaube mit Series40. Da ist das wohl nicht so einfach. Wobei sich das beim Series60 per Task-Manager auch nicht gerade intuitiv anhört.

  43. der Vollständigkeit halber…
    erstmal großes lob für den podcast. ein wunderbarer überblick zum thema java und dem ganzen drum rum. Zum Thema trennen von java programmen innerhalb einer jvm sei hier noch osgi erwähnt. damit gewinnt die jvm enorm an dynamic. mehr infos unter http://www.osgi.org

    gruß rené

  44. Ich bin beim Hören gerade an der Stelle mit der Umstellung der Lizenz auf GPL.

    In dem Zusammenhang fände ich einen Podcast über all die verfügbaren Lizenzen (GPL, LGPL, Apache, Mozilla, …), deren Bedingungen, Komaptibilitäten und technische Konsequenzen (statisches/dynamisches Linken etc.) ganz interessant.

    Möglicherweise ziemlich schwere Kost, aber Du schaffst das, Tim ;-)

  45. Immer wieder ein guter Begleiter auf dem Weg zur Arbeit! Weiter so!

    Sebastian (Namensvetter) und Henrik hatte schon nach dem Eclipse Plugin/Tool gefragt, welches den Code in Layer/Divs aufteilt, um den Code sauber zu halten und zu refactorn. In den Links habe ich leider nicht entsprechendes gefunden. Darum wäre eine URL und/oder Namen nett.

    Gruß Sebastian

  46. In meinen Augen leider einer der schlechteren CRE-Podcasts.

    Viele Punkte wurden aufgegriffen, aber nicht zu Ende gebracht; stattdessen seid ihr „vom Hundertsten in Tausende“. Einige Fachbegriffe wurden bereits vorausgesetzt und, wenn überhaupt, erst später erklärt. Stattdessen wurden andere, wie z.B. die HotSpot-Engine oder die Enterprise Editition doppelt erläutert (zuerst einfach, an anderer Stelle nochmal genauer).
    Alles in Allem meiner Meinung nach also ein bisschen strukturlos.

    Hinzu kommt, dass ich mir über die Zielgruppe nicht so ganz im Klaren bin: Oben steht „Für Java-Insider ist sicherlich nicht viel neues dabei.“, was wohl durchaus der Realität entsprechen dürfte. Mir als jemandem, der schonmal ein paar einfache Java-Programme geschrieben hat, aber eigenlich keine Ahnung von der Plattform hat(te), fehlten aber einige Basics, was wohl auch mit den oben schon erwähnten „nachgereichten“ Erklärungen zusammanhängt.
    Vermisst habe ich etwa den Punkt, was der Application Server (Tomcat) nun eigentlich genau macht oder praktische Beispiele für Webanwendungen in Java.

    Gewünschr hätte ich mir auch mehr über die Programmiersprache Java, aber da habt ihr halt den Fokus stärker auf die Plattform gelegt.

    Ein Punkt, der bei diesem und in den meisten anderen Programmiersprachen-CREs wenn überhaupt nur in Nebensätzen erwähnt wurde, ist die Art der Auslieferung: Vorkompiliert, als Bytecode oder zum Interpretieren?
    Für mich als Programmier-Anfänger nicht ganz selbsterverstänlich und äußerst interessant. Was macht die JVM denn nun eigentlich genau?

  47. @Jan2 @Tim @Alle: Gern, so denn Tim weiter über Java berichten mag ;-) Was wären denn gewollte Themen?

    @Sebastian: Leider kann ich den Link nicht mehr ausgraben, aber wenn ich ihn doch noch finde, poste ich ihn hier.

    So, und hier nochmal ein ganz netter Microbench zum Thema java ist langsam:

    http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/

    Zwei Dinge sind spannend: 1) Das Verhältnis Java C++ 2) Die Geschwindigkeit von für die JVM implementieren Skriptsprachen vs. C-Implementationen von Skriptsprachen (Groov 1.6 C-Python)

  48. Also Schlagwörter zu denen ich sehr gerne etwas hören würde wären z.B:
    AOP in Java, Dependency Injection, Performance im Vergleich zu anderen Sprachen, noch mehr über Buildsysteme, Annotations, ev. auch populäre Frameworks.
    Vielleicht ist ja was dabei, was euch Spaß machen würde :-)

    Grüße

  49. Mal eine soundtechnische Anmerkung: So konstantes Hintergrundrauschen waere auf jeden Fall sehr angenehm. Ich weiss nicht, ob Du das geschnitten hast oder nur an den Reglern rumgedreht, aber oft hoert es sich wie ein Wackelkontakt im Kopfhoerer an. Sehr nervig.

    Aber dafuer ist der Stereoeffekt sehr fancy ;)

  50. Netter Podcast.
    Ich finde, GCJ hätte eine Erwähnung verdient. Eine Einschätzung zur Performance des erzeugten Codes von gcj hätte mich interessiert.
    Desweiteren hätte man auch was zu Kaffe sagen können.

  51. Hallo. Welche praktische Bedeutung hat Java heute bei Embedded Systems? Damit meine ich einerseits Set-top-Boxen, Haushaltsgeräte, Autoradios/Navigationssysteme und Smartcards als auch Maschinensteuerungen in der Industrie. Zwar wird oft behauptet, Java hätte zu große Hardwareanforderungen für diese Anwendungen, andererseits sind GHz-CPUs und Gigabytespeicher bei Embedded Systems für Maschinensteuerungen in der Industrie heute üblich. Ähnlich sieht es bei Autoradios/Navigationssystemen aus. Die Netzwerkanbindung in der Industrie ist fast überall gängig, was auch für Java sprechen würde, auf dem Server und auch auf den Clients.

  52. Hi,
    das ist ein netter Podcast, wobei mir ein paar Sachen nicht so recht einleuchten wollten.
    Zum einen seh‘ ich die Notwendigkeit für die angesprochen Closures nicht. Das Beispiel Exception Handling zieht für mich nicht wirklich, denn Java hat doch genau dafür eine eigene Lösung.

    Mir fehlt da ein Beispiel, wo klar wird, dass man das wirklich braucht.
    Ich hab oft den Eindruck – insbesondere beim Hören des C++ Podcasts – dass Programmierer, die vorher C/C++ oder andere Sprachen geschrieben haben, irgendwann Java programmieren müssen und sich lieber erstmal über die fehlenden Features beklagen, als sich mit den Gegebenheiten und modes of operations von Java auseinanderzusetzen.

    Als Physiker nutze ich Java wirklich gerne, weil ich mich auf mein eigentliches Programmierproblem konzentrieren kann, ohne dass ich den technischen Sch**** machen muss, wie etwa Speicher zu allozieren und es trotzdem schnell läuft (im Gegensatz zu voll intepretierten Sprachen). Gerade im letzten Punkt kämpft Java ja immer noch mit Vorurteilen aus den frühen 90’ern.

    Außerdem ist wohl klar, dass es gerade im Vergleich mit C++ sehr komfortabel ist, ein deratig großes Framework mitgeliefert zu bekommen, dass man für wirklich sehr viele daily life Probleme ohne third-party libraries auskommt, oder etwa nicht?

    Was ich mir mal wünschen würde, wäre ein Podcast mit einem C++ Liebhaber – wie pavel – und einem erfahrenen Java-Programmierer, der Java auch mag.

  53. Das ist so eine der Folgen wo ich mir nach den mittlerweile 4,5 Jahren mal einen Teil zwei wünschen würde. Interessant wäre vor allem die JavaEE Ecke mal etwas näher zu beleuchten die imho der heute industrierelevante Teil von Java ist (EJBs, CDI usw.). Zumal das einfach ein riesiges Thema im Bereich kommerzieller Webanwendungen ist und wir da in Deutschland auch mit Leuten wie Adam Bien (adam-bien.com/) einige der angesehensten Entwickler überhaupt haben.
    In dem Zusammenhang wäre sicher auch ein kleiner Rundumschlag über die verfügbaren Webframeworks wie JSP, Wicket, Play und vor allem das immer prominenter werdende Vaadin (basierend auf GWT) interessant.

  54. Pingback: MM109 Pie Malum Domine Dona Nobis Requiem | mobileMacs

  55. Gerade diese alte Folge noch mal gehört. War das schön, als es in CRE noch manchmal um Programmiersprachen ging. Diamanten, Fledermäuse, Kryptogeld und die Sendung mit der Maus sind ja ganz nett. Aber es ist wirklich schade, dass der am Anfang so starke Hardcore-IT-Teil seit Jahren so gut wie gar nicht mehr bedient wird. Schon schade, da das eine Nische ist, die CRE wirklich gut besetzt hat. Folgen zur Sendung mit der Maus kann ich tendenziell auch woanders finden (was nicht heißen soll, dass die Folge nicht gut gewesen wäre).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.