Dieses Jahr widmet sich die JAX mit gleich zwei Tagen dem Thema Java Web Development, special JavaServer Faces. Andy Bosch, Autor des Buches "Portlets und JavaServer Faces", wird mittwochs den JSF Day moderieren, während Matthias Weßendorf am Freitag zu JSF Extreme einlädt. Wir sprachen mit beiden über das Thema JSF und was uns auf den Tagen erwarten wird.
JAXenter: Es ist stiller um JSF geworden, im Bereich der Java-Webentwicklung geben hippe Frameworks wie Grails, (J)Ruby on Rails oder Wicket derzeit den Ton an. Wie hält die JSF-Community dagegen?
Matthias Weßendorf: Findet ihr? Ich finde, dass gerade bei JSF einiges passiert: Die ganzen Bibliotheken stellen gerade auf JSF2.0 um und stellen ihre "Macken" als Bugs gegen die Spezifikation und die Implementierungen ein. Die JSF EG arbeitet MR-Releases der Spec ein und sammelt Ideen für die Zukunft. Überhaupt ist JSF 2 gut angenommen: Das zeigt, dass dieses Release notwendig war!
Andy Bosch: Wer sagt denn, dass es stiller geworden ist? Ich empfinde es gerade anders herum. Über JSF 2.0 wird sehr viel gesprochen. Es wird meist anerkennend erwähnt, dass viele Schwierigkeiten aus JSF 1.x sehr gut gelöst wurden und JSF 2 jetzt eine sehr mächtige Basis für Webanwendungen bereitstellt. Die Expert Group von JSF 2.0 ist sehr bemüht, den Prozess offen und lebendig zu gestalten. Ich habe persönlich noch nie eine Expert Group erlebt, die mit der Community derart intensiv im Dialog ist. Auch empfinde ich persönlich den ersten Hype um Grails / Rails / Wicket vorüber. Jetzt muss der Markt zeigen, ob diese Frameworks auch von der Masse angenommen werden.
JAXenter: Welche Antworten gibt es aus dem JSF-Lager auf modernste Anforderungen wie Ajax-Unterstützung oder mobile Clients wie z.B. iPhone?
Andy Bosch: Naja, Ajax ist nicht mehr wirklich eine „moderne“ Anforderung. Jedes Webframework muss es quasi out-of-the-box schon mitbringen. JSF hat die Ajax-Funktionalität im Standard bereits festgelegt, so dass auf dieser Basis umfangreiche Komponenten im OpenSource-Bereich entstehen können. Für die Unterstützung anderer Devices oder Ausgabeformate generell ist JSF konzeptionell bereits seit Beginn an dafür ausgelegt. Es gibt die Trennung von UI-Komponente und Renderer. So kann ein Render-Kit ausgetauscht werden, ohne die Funktionalität neu programmieren zu müssen. Wicket z.B. ist hier viel stärker an HTML gebunden als JSF, was hier eine eigene Abstraktion bietet.
Matthias Weßendorf: Ajax würde ich nicht mehr als "modern" bezeichnen: Es ist ein Muss-Kriterium. JSF 2 hat ein minimales Ajax-API, das weiter ausbaufähig ist. Generell kann man das API gut mit der eigenen JSF-Bibliothek nutzen, so dass "interoperability issues" in Zukunft weniger werden. Verschwinden werden sie nicht (gänzlich). Ein Grund: Uploads via PPR. JSF 2 weiß nichts über Uploads, aber jede JSF-Bibliothek. Uploads sollen aber innerhalb von JSF 2.x berücksichtig sein.
Zum Thema iPhone/Android wird auch einiges angeboten, von verschiedenen JSF "Tools": IceFaces, PrimeFaces oder Trinidad. Trinidad hat den Vorteil, dass man auf bewährte TAGs/Komponenten zurückgreifen kann. Das Look-And-Feel wird über ein CSS-Skin angepasst. Ich schreibe eine "mobile" Seite und liefere sie für iPhone und Android aus: Das Look-And-Feel wird via Runtime angehängt. Das ist sehr schick: Ohne neue Komponenten zu erstellen/benutzen.
JAXenter: Spätestens in diesem Jahr richten sich alle Blicke auf HTML5: welche Auswirkungen wird dies auf JSF haben und wie bereitet man sich ggf darauf vor?
Matthias Weßendorf: Sehr gut. Für Apache MyFaces gibt es (wird es geben) ein "Google Summer of Code" Projekt, das ein HTML5 RenderKit für JSF2 realisieren wird. Die Gotchas werden wieder in die Spezifikation zurückfließen. Innerhalb der EG gab es kleinere Überlegungen, das eine oder andere Widget zu spezifizieren. Aber... Specs sind langsam... MyFaces wird schon bald erste Ergebnisse liefern können.
JAXenter: Seit letztem Jahr ist das Thema JSF mit zwei Special Days auf der JAX vertreten. Was rechtfertig eurer Meinung nach diesen hohen Stellenwert?
Matthias Weßendorf: Ganz einfach: Es ist die meistverbreitete UI-Technologie im Java-Umfeld. Wachsende Teilnehmerzahlen bei anderen "JSF Events" unterstreichen diesen Trend.
Andy Bosch: JSF ist das UI-Framework im JavaEE-Umfeld. Es hat seit mehreren Jahren bereits eine ständig steigende Entwickler- und Anwenderzahl. Viele Firmen und Organisationen setzen auf JSF, weil es zum einen ein Standard ist, zum anderen aber auch, weil es funktional mittlerweile sehr ausgereift ist. Ich denke, JSF ist es gelungen, die Vorteile eines Standards mit den Vorteilen einer aktiven und schnell reagierenden Open-Source-Community zu verbinden. Dadurch ist JSF sehr populär geworden, was wiederum ein verstärktes Interesse an JSF hervorruft.
JAXenter: Unter anderem wird es auf der JAX um Comet gehen. Welche Vorteile haben Entwickler von push-Diensten wie Comet?
Andy Bosch: Ich selbst bin mir beim Thema Comet noch unschlüssig, ob ich jubeln soll oder lieber fluchen. Sicherlich, Server-Side Push ermöglicht ein ganz neues Spektrum von Anwendungen und UI-Möglichkeiten als bislang. Schaut man technisch aber etwas genauer hinter die Kulissen, ist das teilweise schon noch eine üble Frickelei von JavaScripten. Von daher würde ich meine Einschätzung momentan mit „optimistisch beobachtend“ beschreiben.
Matthias Weßendorf: Interactive GUIs. Das Web kann nun liefern, was der Desktop schon seit Jahrzehnten kann: Wird im Backend was "verändert" bekommt der (Web)Client eine Benachrichtigung ohne große Verzögerung. Das ermöglicht die Erstellung von richtig coolen (Web)Anwendungen! Auch hier gibt es bereits JSF Libs, die das Themen angehen: Oracle's ADF Faces, IceFaces und PrimeFaces. Achja, mit dem steigenden Interesse an WebSockets wird hier eine weitere Optimierung getroffen: Bidirektionale Kommunikation!
JAXenter: Ein Thema auf den JSF Days werden Reporting-Tools sein. Was macht diese so wichtig für die Webentwicklung?
Andy Bosch: Webanwendungen machen heutzutage oftmals mehr, als nur ein paar lustige Apps darzustellen. Komplette Workflows werden über Webinterfaces abgearbeitet, teilweise haben sogar Enterprise-Suiten keine eigenen „Fat-Clients“ mehr. Alles erfolgt nur noch Browserbasiert. Was liegt somit näher, als auch Auswertungen (Reports) online erstellen und analysieren zu können. Bislang hat sich der Anwender immer in zwei Welten bewegen müssen: in der Webanwendung und parallel in verschiedenen Reporting-Tools. Durch die Möglichkeit, beides zu kombinieren, kann der Anwender künftig sehr komfortabel direkt aus seiner Webanwendung die benötigten Berichte erzeugen und ausdrucken.
JAXenter: Das Web Profile ist noch realtiv jung – was bringt es eurer Meinung nach Neues bzw. wie verändert es die Java-Web-Landschaft?
Matthias Weßendorf: Weniger ist mehr! Das Web Profile beinhaltet wichtige Bestandteile, die für die meisten Anwendungen ausreichen. Nicht umsonst laufen bereits heute viele Web-Anwendungen im Tomcat/Jetty ab.
JAXenter: Eine Session wird sich genau mit diesem Thema beschäftigen: Java Web Profile versus Spring Web. Kannst du uns schon einen kurzen Ausblick auf die Lehren geben, die du aus dem Vergleich ziehen wirst?
Matthias Weßendorf: Schlüsselpunkt ist JSF: Es lässt sich mit beiden Welten einfach nutzen, wie auch JPA. Während ich im Web Profile alles habe, was ich brauche, baue ich es mir mit Spring zusammen. Beide Welten haben ihre Vor/Nachteile. Die Session zeigt das WIE mit WELCHER Umgebung und geht auf ein paar Feinheiten der Konstellationen ein.
JAXenter: Vielen Dank für das Gespräch!
Matthias Weßendorf ist Softwareentwickler bei Oracle. Dort arbeitet er an ADF Faces RichClient, einer Ajax-basierten JSF-Komponenten-Bibliothek. Matthias ist ebenfalls aktives Mitglied der Open-Source-Gemeinschaft, wo er sich überwiegend bei den Apache-Projekten MyFaces und Apache engagiert. Vorher war er als CMS-Entwickler der Pironet NDH AG an der Entwicklung eines next-generation CMS, mit UI-Techniken wie XUL und Ajax, beteiligt.
Andy Bosch ist unabhängiger Berater und Trainer für JavaServer Faces und Portlets. Er ist Autor verschiedener Fachbücher (JavaServer Faces, Portlets und JSF) sowie Betreiber der Plattformen http://www.jsf-forum.de und http://www.jsf-portlets.net. Zudem ist er Mitglied der Expertengruppe des JSR-301 (Portlet Bridge Specification for JavaServer Faces) und Mitglied in SENS (www.SoftwareExperts.de).
Kommentare
Nach zig Jahren hat man es dann endlich mal geschafft, die Kinderkrankheiten auszumerzen (die traurigerweise von Anfang an bekannt waren) und klopft sich dann schön auf die Schulter ob dieser wahnsinnigen Erfolgsstory. "AJAX ist ja schon im Standard definiert". Das AJAX aber 2005/2006 schon als "Standard" galt, aber erst seit Ende 2009 im JSF-Standard definiert ist: Soll DAS ein Erfolg sein?
Vielleicht sollte man einfach auch mal einige Entwickler aus der Industrie fragen, was die davon halten, statt Leute die am Standard mitarbeiten oder von Konferenz zu Konferenz tingeln. Ich zumindest glaube nämlich, das von Leuten, die mit 3+ Personen mehr als 2+ Jahre an EINEM grossen JSF-Projekt arbeiten, mehr sinnvoller Inhalt zum Thema "JSF ist ein Erfolg" zu erwarten ist als von Leuten, die sich ein paar Showcases von 10 Seiten zusammenbasteln, um die super CSS-Fähigkeiten von neuen Komponenten oder "Guck mal, wir können PPR" zu zeigen. DAS sind nämlich echt nicht die Probleme, die die Welt da draussen ausserhalb des Reissbretts hat.
Wirkt jetzt vielleicht ein wenig provokant, ist aber keinesfalls beleidigend gemeint. Nur um das von vornherein klarzustellen :-) #zitieren
Guckt euch lieber REST (JAX-RS), GWT oder Wicket oder meinetwegen auch Servlets + FreeMarker an, aber vergesst JSF. #zitieren
Die technische Seite ist natürlich auch wichtig, ich fände es auch hip, wenn ich mein großes Webprojekt ganz locker flockig und groovy in Groovy und Grails hacken könnte, aber die technische Seite ist eben nur eine Seite der Medaille. Und mir wird in diesem Blog leider zu heftig über eben nur diese Seite diskutiert.
Ich will hier keine Lanze für JSF brechen, ich bin selbst auch hin- und hergerissen und deshalb fände ich es schön wenn hier ein konstruktives Pro und Contra seitens Euch Entwickler und Entscheider stattfinden könnte. Mich interessiert vor allem auch Erfahrungen aus Projekten mit JSF, gute wie schlechte...
Los, jetzt seid Ihr dran ! Have Fun !
Euer Marc #zitieren
Abgesehen davon, dass ich JSF im Vergleich zu Wicket viel zu umständlich finde, ist schon der Grundansatz davon krank. Der Zustand des Clients gehört auf den Client. Wenn man gegen dieses Grundprinzip des Webs verstößt bezahlt man das durch teure und schlecht skalierende IT-Infrastruktur. Ich empfehle dir, das Buch über REST von Stefan Tilkov zu lesen. Danach will man sowas wie JSF nicht mehr benutzen und wenn doch, ist man sich zumindest sehr viel klarer über die Nachteile.
Also, lass dich nicht zu sehr von der Herde leiten, denn sie kann auch in die falsche Richtung laufen. Technologieentscheidungen werden in Unternehmen nicht immer auf der besten Grundlage getroffen ... #zitieren
Trepper schreibt, dass er ja Standards eigentlich sinnvoll findet, nur der JSF-Standard an sich, also seine Umsetzung, wäre schlecht. Gleiches schreibt auch Sascha. Okay, zu sagen "JSF ist schlecht" ist die eine Seite, mich interessiert aber WAS ist schlecht an JSF ? Welche Probleme habt Ihr mit JSF gehabt? Fallstricke? Geht Euch der Standard nicht weit genug? Warum? Was fehlt Euch? Das sind die Informationen, die für mich interessant und relevant sind.
Vielleicht meldet sich auch mal ein Befürworter von JSF und schreibt von seinen Erfahrungen. Es soll kein Glaubenkrieg entstehen, lasst uns sachlich miteinander diskutieren. Ich bin gespannt wie sich das hier weiterentwickelt. #zitieren
Die Diskussion aber finde ich sehr gut, denn die Kritik trifft exakt. Groß, schwerfällig, ein Müllhaufen an State wird auf den Client geschleppt (FireBug explodiert förmlich, wenn man sich die hidden Fields ansieht) und jedes mal an den Server übertragen wird. Nur mit vielen Tricks kann diesen Wust minimieren. Und wie da noch AJAX reinpassen will ist mir schleierhaft und in der Praxis der glatte Wahnsinn (s. RichFaces). Sowohl Client als auch Server erliegen am Herzinfarkt.
Auf der anderen Seite (s.o.) ist eine JSF incl. Facelets eine tolle Technologie, um einfach schnell aus fertigen Komponenten gute Lösungen zu bauen, die User mögen. Weniger der Standard als z.B. Primefaces. Einfach in den Werkzeugkasten greifen, zusammenstecken. Fertig.
Das ist die Krux dabei. Nur was soll ich tun? Gebt mir bitte ein Framework wie Wicket aber mit riesen Bibliotheken *lach*, dass auch noch sich direkt an anderen Technologien (z.B. Spring) einsteckt nebst großer Community. Im Moment fällt mir außer JSF eben nur wenig ein. #zitieren
Wenn man gegen diese Grundprinzipien verstößt, um ein vermeintlich einfaches und komfortables Entwicklungsmodell zu bekommen, wird man das an anderen Stellen teuer bezahlen; zum einen durch nötige Trickserei beim Programmieren und zum anderen bei der Skalierbarkeit der Systeme.
REST sehe ich übrigens auch nicht als Framework an, sondern als einen Architekturstil, nämlich den Architekturstil des Webs. Darauf aufbauenend gibt es dann schöne Frameworks wie JAX-RS (bzw. Implementierungen davon wie Jersey).
Interessant dazu finde ich übrigens auch diesen Artikel über Wicket und GWT. http://blog.leonpennings.com/?p=76 Mit JSF wäre der Vorsprung von GWT noch krasser. #zitieren
vorab: Ich finde es gut, das sich mittlerweile so eine Diskussion hier entwickelt hat, ich bin doch überrascht, wie sehr mein Ursprungs-Kommentar da einige Nerven sowohl positiv als auch negativ getroffen hat :-)
Um auch einige Dinge klarzustellen: Ich persönlich finde JSF als Idee nicht schlecht. Ich finde den Ansatz der Komponentenbibliotheken eine sehr gute Sache und mag es, das ich mir schnell neue Oberflächenkomponenten über externe Bibliotheken "dazustöpseln" kann. Genau hier fängt das Problem aber auch an: Mittlerweile benutze ich aus dem JSF-"Standard" nur noch die Oberflächenkomponenten. Für das Templating ist Facelets integriert, für flexible Navigationen Spring Webflow, für die Bean-Verwaltung Spring. Soviel zum "Standard".
Was mir zudem seltsam erscheint sind diese immer wiederkehrenden Artikel im JavaMagazin und auch hier, von denen über JSF als DIE Lösung gesprochen wird. Spreche ich mit Entwicklern, die JSF über Jahre in Projekten einsetzen (für mich ist ein "Projekt" an dieser Stelle eine Anwendung, in der mehr als ein Mannjahr Entwicklung steckt, KEINE 3-5 Seiten CRUD-Anwendungen, die gern als Referenz genommen werden!), bekomme ich genau die gleichen "Probleme" geschildert, die ich ja hier auch kommentiert habe. Darüber wird aber seltsamerweise weder im JavaMagazin noch hier in Artikeln noch auf Konferenzen wie der JAX gesprochen. Da ist immer alles super. Ist ja auch kein Wunder, sind ja auch immer die gleichen Autoren/Speaker, die da durch die Landen tingeln, und manchmal frag ich mich schon, wo da noch die relevante Praxiserfahrung herkommen soll, um solche Technologien tatsächlich objektiv zu betrachten (von der Tatsache, das man für eine objektive Beurteilung vielleicht nicht grad Core-Committer sein sollte sprech ich mal nicht).
Alles ist immer "total toll", der Standard ist jetzt noch besser, super neue Funktionen. Das streite ich auch nicht ab, für neue Projekte ist das sicher eine feine Sache. Gerne unterschlagen werden aber drei Punkte:
1. Viele Probleme von JSF 1.1 und 1.2 waren schon vorher bekannt und in anderen Frameworks auch schon entsprechend gelöst. Stichpunkt: Navigation und Wiederverwendbarkeit von Seiten und Seiten-Teilen. Im Standard (bis 1.2) wurde sich auf den kleinsten gemeinsamen Nenner geeinigt und der war schlicht eine inakzeptable Mischung von Struts 1 mit dem XML-Overhead von J2EE. Klar ist das jetzt im 2.0er anders, aber da sind wir bei Punkt 2:
2. Bis Dinge in den Standard wandern, vergehen Jahre. Stichwort AJAX-Unterstützung, Facelets. Ob ich in JSF 2.0 flexiblere und wiederverwendbare Navigationen a la Spring Webflow hinbekomme, hab ich ehrlich gesagt noch nicht angeschaut. Es kann aber nicht sein, das ich vier Jahre auf
geregelte AJAX-Unterstützung warten muss, Standard hin oder her.
3. Für ältere aber weiterlaufende Projekte ist es schwierig, das ganze ordentlich upzugraden, da meist eben schon andere Frameworks als "Workarounds" für die ganzen Schwächen so tief im System verankert sind, das man jetzt schauen muss, wie man das am Besten auf 2.0 bekommt. Aber vielleicht hab nur ich das Problem und/oder die Meinung, das sich auch ein langlaufendes Projekt technologisch weiterentwickeln muss :-)
Zu diesem ganzen Zirkus von wegen "JSF-CSS-Fähigkeiten" und der Qualität bzw. Prioritäten, die da innerhalb der Apache-JSF-Teams gesetzt werden, hab ich hier http://it-republik.de/jaxenter/artikel/Trinidad-goes-iPhone-2916.html schon was geschrieben. Ich bin immer noch verwundert, wieviel Relevanz dem Thema CSS und Styling dort zugesprochen wird. Wenn DAS die Probleme sind, die die JSF-Gemeinde bewegen, dann bitte ich um erhellende Aufklärung und Beispielprojekte aus der Industrie :-) #zitieren
Für die Autoren und ihre Technologien ist es eine schöne Plattform zur Selbstdarstellung und natürlich wollen sie sich auch nicht den Ast absägen, auf dem sie sitzen und erzählen so immer wieder wie toll doch alles ist. Wenn JSF 2 jetzt so viel besser ist, warum haben genau DIESE Autoren, dann nicht mehr über die Macken von JSF 1x geschrieben?! Ich kann mich an einen einzigen kritischen Artikel zu JSF im Java-Magazin erinnern und der kam nicht von den üblichen Verdächtigen. Das ist armseliger "Journalismus" (dieses Wort mag ich hier gar nicht benutzen). #zitieren
Warum? Weil ich immer noch hoffe, dass die früheren glücklichen Zeiten wieder kommen, in denen ich kaum erwarten konnte, das nächste Heft zu lesen.
Was steht heute drin:
"Wie schaffe ich ein HelloWorld trotz Einsatz von Spring-Technologie X (von Eberhard)"
"Warum die Verwendung von EJB 3 nun endlich angeblich dem Nichtverwenden von EJB das Wasser reichen kann"
"Die nächste vollkommen abstrakte Sicht auf SOA" (Btw.: http://www.gregthearchitect.com/episode_SOA_this.html immer noch sehr sehenswert!)
"Spring-Batch: Wie ich ein paar Zeilen Datenaustausch innerhalb von 2 Jahren programmiert habe (Freund von Eberhard)."
"IBM / Oracle / XYZ BPM-Bloatware: Damit schützen Sie sich bis zur Rente vor weiterer Programmiertätikeit"
"Business-Process-Rules-Hype XXX - So bringen Sie die Kollegen von der Fachabteilung ganz sicher selbst zum Programmieren" (ganz sicher)
"Eberhard erklärt Ihnen, warum Spring immer besser als ein Standard ist"
"Warum Entwickler in 5 Jahren keine Arbeit mehr in Deutschland haben werden (wir helfen Ihnen beim Outsourcing nach Indien, ganz billig, keine Schleichwerbung")
"Faces-Tales: So erstellen auch Sie eine imperformante Franken-GUI - Heute: das Hello-World wird fertig"
"Endlich: Spring-Chunk-Maker in rc 21 erschienen : Das Prerelease 3.0.alpha.0.1.rc21 ist da! Was bringts neues? Fast so geil wie ich selbst (von Eberhard)"
Usw. usw.
Wie gesagt: Mir blutet das Herz immer mehr: Das Java-Magazin gehörte für mich jahrelang zum Berufsleben wie kaum etwas anderes - es verkörperte wie kaum etwas anderes die "Generation Java". Ich freute mich jahrelang jeden Monat auf endlich wieder viele gute Themen die ich brauchen konnte. (Besonders mochte ich die Open-Source-Perlen).
Heute blättere ich das Teil durch, such etwas, das für meine Arbeit relevant ist und finde kaum was.
50 % der Seiten sind Werbung.
Ich fang dann doch den ein oder anderen Artikel zu lesen an, ärgere mich (s.o.), suche weiter, nichts interessantes, OK, der JDK-7-Report ist noch halbwegs interessant, der Bericht über JavaFX entsprach demwas ich wusste - das Heft landet nach max. 15 Minuten im Papierkorb.
Bin trotzdem noch Abonnement - unverbeserlicher Optimist, es könnte ja wieder besser werden...
Deswegen - und weil Kritik ja konstruktiv sein soll: Bringt doch mal wieder davon:
- Praxisbericht: So stelle ich auf GIT (oder Mercurial) um - Servereinrichtung, IDE und Build.
- Open-Source-Perlen: XXX
- Classfish embedded: Schlankes direktes Starten und Debugging.
- Web-GUI heute: Tipps und Tricks zu Vaadin
- Filthy Rich Clients: Solche Tabellen sieht der Anwender gerne
- Das gescheiterte Projekt: Warum unsere Firma noch immer keinen (funktionierenden) ESB hat.
- SAP-Basis: ...
- JPA 2 mit Hibernate: Status Quo.
- Erfahrungsbericht: Migration JPA von Hibernate zu EclipseLink.
- E-Commerce-Strategien: Heute Ikea in China
- Funktionierende SOA: Das Fangen Sie mal klein an. #zitieren
Vielleicht sollte die Redaktion einfach mal stärker die Leserschaft befragen, was sie interessiert, statt die 100. Folge von Spring zu bringen. #zitieren
leider viel Wahres dran. Zu der sehr Spring-lastigen Berichterstattung gesellt sich noch der hohe OSGi-Anteil. Auch hier immer sehr positive Berichterstattung, wenig bis gar nichts kritisches. Dritter grosser Punkt ist "Agilität". Zu 95 Prozent besteht auch die JAX aus diesen Themen. Ist man kein Mitarbeiter oder "Bekannter" der entsprechenden Firmen/Kollegen, hat man schon keine Chance, einen Beitrag auf dieser Konferenz zu platzieren. Ist jedenfalls mein Eindruck, wenn man sich die Speaker-Listen der vergangenen Jahre mal so anschaut. Die albernen "Sorry, aber versuchen Sie es gern nächstes Mal wieder mit einer Einreichung"-Mails kann man sich da auch sparen. Ohne zumindest nem Hinweis, was jetzt nicht passte, nützt es nichts.
Als Ergänzung noch zu den lustigen wiederkehrenden Themen im Java-Magazin. Ich finde die "Ich hab hier Tool xyz, beschreibe langwierig und langweilig, wie man das Zip entpackt und was da für Verzeichnisse existieren, dann machen wir einen Mini-Aufruf, der 0,005% der Funktionen mal zeigt und danach folgt direkt eine Bewertung des Nutzens und der Zukunft des Tools"-Artikel vom immer gleichen Autor auch faszinierend. Die sind so nach Schablone geschrieben und inhaltsleer, das ich mich frage, wo da die Aufwertung zur jeweiligen offiziellen Tool-Dokumentation im Internet bestehen soll, die ich von einem Fachmagazin erwarte.
"Früher" (ja, da war alles besser ;-)) bin ich im JavaMagazin teilweise über echte Perlen gestolpert und konnte ne Menge Infos draus ziehen. Die Erfahrungsberichte waren "ehrlich", Technologien wurden kritisch begutachtet. Irgendwann ist da aber irgendwas gekippt und das JavaMagazin wurde zum Werbemedium für die JAX-Sponsorfirmen und regular Speaker. Mittlerweile überlege ich mir auch ernsthaft, das Abo zu kündigen, da ich mich des Eindrucks nicht erwehren kann, das ich als Leser für dumm gehalten werde. Vielleicht denkt man einfach, das das Niveau der Leserschaft nicht so richtig hoch ist? #zitieren
Werbeplattform für JAX- und sonstige Sponsoren.
Das erklärt vieles.
Auch die dümmlichen Quick-Votes in letzter Zeit hier.
Welche Alternativen gibt es? Hab früher auch mal das Java Spectrum gelesen - das enthielt damals aber fast nur Selbstbeweihräucherungen von selbsternannten Java-Consultant-Meistern. Also auch vollkommen kritiklos.
Ist das besser geworden?
Was gibts sonst noch? #zitieren
"Wie schaffe ich ein HelloWorld trotz Einsatz von Spring-Technologie X (von Eberhard)"
"Spring-Batch: Wie ich ein paar Zeilen Datenaustausch innerhalb von 2 Jahren programmiert habe (Freund von Eberhard)."
"Eberhard erklärt Ihnen, warum Spring immer besser als ein Standard ist"
"Endlich: Spring-Chunk-Maker in rc 21 erschienen : Das Prerelease 3.0.alpha.0.1.rc21 ist da! Was bringts neues? Fast so geil wie ich selbst (von Eberhard)"
Beeindruckend. Ich habe in 2009/2010 folgende Artikel im Java Magazin gehabt:
JSR 330 (siehe da - ein Artikel über einen Standard!) (3/2010)
Spring 3.0 (11/2009)
Spring 3.0M1 (5/2009)
Weihnachtsbuch (2/2009)
Ich finde es schade, dass so etwas einen solchen Kommentar und zudem noch anonym nach sich zieht. #zitieren
@Redaktion: Zustimmung zum Thema "persönliche" Angriffe.
Nichtsdestotrotz würde mich aber die Meinung der Redaktion zu der entsprechenden Kritik interessieren, das durchaus häufig zentral in ein Projekt (JSF, Spring, whatever, ist jetzt wirklich nicht auf diese beiden Technologien begrenzt) involvierte Personen sowohl über entsprechend positiv gefärbte Artikel im JavaMagazin, als auch als Speaker mit Beiträgen gleicher positiven Färbung auf der JAX vertreten sind? Es aber andersrum echt schwierig wird, kritische Auseinandersetzungen mit den jeweiligen Technologien zu finden, die von "Machern/Architekten/Senior-Developern" aus der Industrie kommen, die diese Technologien dann in grossen Projekten einsetzen und nicht nur in Hello-World-Demoszenarien?
Ich kann irgendwie nicht glauben, das es diese Leute entweder nicht geben soll oder diese keine Artikelvorschläge oder Konferenzbeiträge einreichen. :-) #zitieren
Gerade zum Thema der Artikel kann ich nur sagen: Dann reicht doch eigene Artikel mit eigenen Themen bei der Redaktion ein.
Was ich wirklich sehr bedenklich finde ist die Tatsache, dass sehr viele hier der Meinung sind, andere bauen ihnen ein tolles Framework, was dann kostenlos genutzt werden kann. Oder das Framework soll eine allumfassende Plugin-Unterstützung haben, am besten gleich mit allen hippen AJAX-Komponenten, die man dann nur noch zusammen stecken kann und gut isses.
So funktioniert das aber nicht.
Von daher möchte ich hier mal anregen, den Ball etwas flacher zu halten und mal zu überlegen, wer eigentlich die ganze Arbeit macht, über die hier so lautstark hergezogen wird.
Jammern und meckern ist einfach, aber die Dinge anpacken und besser machen, das können die wenigsten.
Nur mal so als Denkanstoß... #zitieren
Erstmal vorab: Ich erwarte nicht, das mir jemand hippe Frameworks baut. Du kannst auch davon ausgehen, das zumindest ich diverse Open-Source-Projekte schon mit Bug-Meldungen sowie Feature-Vorschlägen unterstützt habe, Artikel im Java-Magazin veröffentlicht und auch Konferenzbeiträge eingereicht habe (die aber abgelehnt wurden, um Fehlinterpretationen hier zu vermeiden). Mir ist aber nicht bekannt, das man erst mit einer entsprechenden "Vita" dazu berechtigt wäre, konstruktive Kritik zu äussern, aber ich denk dann einfach mal, das ich dann das Recht dazu habe. :-)
Das ich kein Anrecht auf super-duper-geile Frameworks habe ist mir bewusst, darum ging es zumindest in meiner Kritik aber auch nicht. Mich nervt es nur, wenn die Leute in den entsprechenden Steuer-Gremien (sei es für Standards oder für sonstige Bibliotheken) die Zeit verschlafen und jahrelang Dinge hochloben, die schon zum Zeitpunkt ihres Entstehens veraltet waren (bezogen auf den JSF-Standard) und dann mit der neuen Version, die dann endlich mal einen gescheiten Stand erreicht hat, so tun, als ob alles schon immer so gut gewesen wäre.
Wenn ich X Eur für eine Fachzeitschrift bezahle, erwarte ich, das sie sich objektiv mit solchen Themen befasst und nicht geprägt wird von schönfärbenden Artikeln der jeweiligen in das Projekt involvierten Personen, die auch gesetzte Speaker auf den vom gleichen Verlag veranstalteten Konferenzen sind. Die c't und die iX schaffen es ja auch, trotz einer Vielzahl von freien Autoren, die Objektivität im Auge zu behalten bzw. zu wahren.
Und jetzt bitte kein "dann kündige doch das Abo"-Hinweis, sowas ist genauso deplaziert wie "wenn's dir nicht passt, mach's doch selbst". Sowas kann man bei Projekten wie Wikipedia erwarten, nicht aber bei Fachzeitschriften und Fachkonferenzen, bei denen man für entsprechend aufbereitete Inhalte teilweise nicht wenig Geld bezahlt. Und da darf und kann ein zwischen den Ohren gesunder Mensch durchaus mal hinterfragen, was er da für sein Geld (oder das der Firma) eigentlich bekommt (ausser X Tage Hotel in einer anderen Stadt ;-))
Und zum Grundsätzlichen: Wenn man sich den Thread hier mal ordentlich durchliest, wird durchaus überwiegend konstruktiv Kritik geübt. Das als "jammern und meckern" oder "herziehen" zu verstehen, ist schon arg seltsam und zeugt von einer merkwürdigen Definition des Begriffs "Kritik", die vielleicht mal Grundlage einer Neubetrachtung sein sollte. #zitieren
"Die ganzen Bibliotheken stellen gerade auf JSF2.0 um und stellen ihre "Macken" als Bugs gegen die Spezifikation und die Implementierungen ein."
Kann man dazu noch mehr lesen?
JSF hin oder her - mein größtes Problem mit JSF aktuell ist das es zum Standard erkoren wurde. Und somit steht sich JSF zu oft selber im Weg, denn der blaue Appserver kommt dummerweise schon mit JSF. Und ja, ich könnte da auch die RI austauschen, parent-first auschalten, etc - aber dann funktionieren leider meine bestehenden Anwendungen nicht mehr. Und ich freue mich heute schon auf die nächste Version, denn eins ist bei den Java EE Specs sicher: drop-in-replacements kennen wir nicht.
ps: Artikel schreiben für so ein gemischtes Publikum ist sehr schwierig, und das sage ich aus eigener Erfahrung. #zitieren
Wer garantiert mir, das RichFaces 4.0 jemals weiter als "alpha/beta" kommen wird? Was ist mit IceFaces - wie gut geht es IceSoft? Wie gut geht es denen Morgen? Wie gross sind die Communities hinter den einzelnen Komponentenbibliotheken?
LOL! 7x1 = 7 soll falsch sein! Jetzt probiere ich 9-7 = 2, mal sehen ob es jetzt durchgeht... #zitieren
Es ist auch mit JSF 1.1 nicht "schwer" eine kleine Anwendung zu bauen und natürlich wird es (in der Regel) mit jeder neuen Version eines Standards "einfacher". Problem bei diesen Standards ist aber, das die "richtigen" Probleme eben in grossen Anwendungen auftreten und "stören".
"Kleine" Anwendungen kann ich mit dutzenden Web-Frameworks bauen. Eine "grosse", die über mehrere Jahre supported und weiterentwickelt wird, durchaus häufig von mehr als einem Entwickler, baut man eher mit einem Standard. Und genau hier offenbaren sich eben diverse Probleme, die ja hier mittlerweile ausführlich beschrieben wurden.
JSF 1.1 gibt es seit 2004 und hatte einen Funktionsumfang, der viele Probleme, die in anderen Frameworks schon gelöst waren, neu in einen "Standard" gegossen hat. Da von "stark" zu reden...Nuja :-) #zitieren
Aber: JSF hört dann auf "Standard" zu sein, wenn ich mich für eine Bibliothek entschieden habe... Und die Unternehmen/ Entwickler die schliesslich aktiv an den einzelnen Komponentenbibliotheken arbeiten haben ganz eigene Vorstellungen über Design und Programmiermodell Ihrer Komponenten, und nicht selten haben Sie ganz eigene wirtschaftliche Probleme.
Bitte korrigiert mich wenn ich mich irre, aber wo ist mein "Standard-Mehrwehrt" wenn ich zwar einen standardisierten Komponentenmodell fahre, aber die angebotenen Komponenten nicht austauschbar sind, weil sie unterschiedliche Features, Programmiermodelle und Laufzeitverhalten haben?
Wer garantiert mir, das RichFaces 4.0 jemals weiter als "alpha/beta" kommen wird? Was ist mit IceFaces - wie gut geht es IceSoft? Wie gut geht es denen Morgen? Wie gross sind die Communities hinter den einzelnen Komponentenbibliotheken?
Dann muss ich mich natürlich auch noch freuen, dass JSF so tief im AppServer integriert ist, das ich erstmal eine volle Migration durchführen muss, um in den Genuß von JSF 2.0 zu kommen. Und dann kann ich es nichtmal gezielt für eine Anwendung verwenden, nein, ich darf gleich alle Anwendungen auf das neue Standard hochziehen. Und bitte kommt mir nicht mit "das tolle an J(x)EE ist die Rückwärtskompatibilität" - denn das hat, wenn überhaupt - nur bei HelloWorld-Anwendungen funktioniert.
Gerade in Bezug auf JSF gibt es nicht schlechteres als "Standard" zu sein. Manager und Entscheider werden vor falschen Tatsachen gestellt und die Entwickler dürfen den Kampf mit dem Betrieb ausfechten.
Nein danke. #zitieren
@PGTaboada, gebe dir in insofern Recht, dass ich aktuell nur ein supportetes / kommerzielles JSF-Framework empfehlen würde. Ich würde sogar ausdrücklich gegen irgendwelche alpha oder beta-JSF-Implementierungen votieren. Jedenfalls sofern die Anforderungen zwingend solche instabilen Implementierungen voraussetzen.
Deine anderen Argumente (Migrationsthematiken, tief in AppServer integriert, Kampf mit dem Betrieb) gegen JSF, JEE sind mir zu unspezifisch. Das sind doch Standardthemen :-) #zitieren
Man fängt bei diesen Standards immer bei 100% Features (die Summe aller nützlichen Features, die man aus anderen Frameworks/Bibliotheken schon kennt) als Nice-to-Have an. Dann stellt man fest, das man das in einer ersten Version gar nicht schaffen kann, und einigt sich runter auf 50%. Von da aus wird dann jahrelang rumdiskutiert, welches die nächsten 25% sein sollen, implementiert die und kommt mit der nächsten Version raus. Mittlerweile dreht sich die Welt aber weiter. Ich gestehe einem Standard zu, das er immer ein wenig hinterherläuft, solch lange Zyklen wie bisher beim JSF-Standard sind aber schlichtweg lächerlich.
@Papick: Naja, man kann JSF ja weiterhin losgelöst aus dem JxEE-Standard benutzen und hat damit dann unter Tomcat zumindest diese Problemchen nicht. Aber grundsätzlich geb ich dir Recht. #zitieren
die kritische Betrachtungen von JSF finde ich sehr aufschlussreich, zumal die meisten Artikel (wie bereits angesprochen) wenig von wirklich objektiver Kritik beinhalten.
Allerdings interessiert mich eure Meinung, welche wirklich ernst zunehmende Alternative zu JSF ihr "empfehlen" würdet und warum?
Ist es nicht auch so, dass wenn ich JSF (2.0) und bspw. die Komponentenbibliothek RichFaces mit Spring WebFlow (oder evtl. auch Seam) kombiniere, viele Nachteile von JSF "umgehe"? Mal abgesehen davon, dass damit viele Teile des Standards nicht mehr zum tragen kommen, aber durch Spring WebFlow die Kombination eines QuasiStandards mit einem offiziellen Standard zwar nicht DIE, aber zumindest eine gute Lösung hat? Mich würde eure Meinung hierzu interessieren, vorallem das WARUM NICHT und WAS SONST!? #zitieren
Ich habe mit GWT sehr gute Erfahrungen gemacht. Die Anforderungen an die Betriebsinfrastruktur sind minimal. Das Programmiermodell ist sehr einfach zu lernen, gehört zu den Frameworks die sich am wenigsten Sorgen machen müssen um Finanzierung oder Zukunft, etc. #zitieren
Frag 5 Entwickler und du bekommst 5 Antworten.
Das ist mir schon bewusst, zumal ich denke, dass eine solche Entscheidung nie wirklich objektiv getroffen werden kann und enorm von den speziellen Anforderungen abhängt.
Aber um nochmals auf das auch angesprochene Thema JSF und SWF (Spring WebFlow) zurückzukommen:
Könnte nicht die Kombination von JSF mit bspw. Spring bzw. SWF oder anderen bewährten Frameworks, die bestimmte Nachteile von JSF beheben und die Vorteile von JSF nutzen oder sogar "bestärkten", JSF so "attraktiv" machen?! #zitieren
Kennst du deine Anforderungen, dann kann dir mit einem Workshop geholfen werden. Kennst du Sie nicht, musst du Münze werfen (z.Bsp. Durch Aussagen wie "wir bleiben beim Standard") oder deine Anforderungen erstmal rausfinden. #zitieren