Cher journal,
dans un soucis de remise à niveau, j'aimerai prochainement me lancer dans les nouveautés Java. (en italique car certaines ne sont plus très nouvelles :)
entre autres : J2EE 1.5, EJB 3.0, J2SE 1.6, Struts/JSF
Ca fait 2 ans que je développe sur un ERP, mais celui-ci étant un peu vieux, il n'utilise aucun framework, aucun EJB, et aucun truc moderne d'une manière plus générale. A part masteriser J2EE 1.4, je masterise plus grand chose...
Je connais un peu JSF par le biais de Sun Creator, mais ce soft est tellement bugué chez moi, que je perd beaucoup (en cherchant pourquoi ca ne marche pas, alors qu'en fait c'est un bug) du gain de productivité généré par JSF.
Et struts, c'est pas le truc officiel sun, mais faut reconnaitre qu'autour de moi beaucoup de gens connaissent Struts, et pas JSF. Lequel apprendre ?
Autrement, j'ai vu que J2EE 1.5 était là, p'têtre l'occasion de se mettre à jour, vous en pensez quoi ? De réel changements par rapport au 1.4 ?
Pour ce qui est de J2SE, j'voulais me lancer dans les nouveautés du 1.5, et v'là ty pas que le 1.6 est sorti... (il est loin le temps où sun laissait couler des années entre chaque version). Ca vaut le coup d'attendre les bouquins dessus, ou bien un bouquin couvrant la 1.5 fera l'affaire ?
Le gros point noir, c'est les EJB. Je ne connais pas du tout, et pourtant il parait que c'est incontournable. Je ne sais même pas à quoi ca sert, j'ai parcouru quelques sites vite fait, mais ca ressemble souvent à une sorte de branlette intellectuelle. Mais pour le coup, si c'est l'impression qui en ressort, les avis sont plus positifs que moi. "Les EJB c'est bon mangez- en", je ne cesse de lire un peu partout.
La plupart des ouvrages disponible couvrent les EJB 2.0, mais les EJB 3.0 sont sortis, et il parait que c'est beaucoup plus simple ! J'attendrais donc bien un peu avant d'acheter un bouquin, histoire d'en prendre un qui traite des 3.0... :-/
Voilà, ca fait beaucoup de chose, du coup j'ai pensé que ca méritait un journal privé. En plus il y a matière à troll, donc les moules sont contentes, et les pierre tramo aussi.
Si quelqu'un a un avis, une référence d'ouvrage, ou une blague, il est cordialement invité à commentairiser.
Merci !
Journal Remise à niveau Java
30
juil.
2006
# Moi ! Moi ! Moi !
Posté par Zakath (site web personnel) . Évalué à 3.
Juste, java sapusaipalibre, c'est un langage tout caca avec une syntaxe de merde et plein de buzzwords pour décideurs pressés.
Tu ferais mieux de te mettre à un vrai langage !
Mais c'est vraiment parce que tu l'as demandé gentiment.
[^] # Re: Moi ! Moi ! Moi !
Posté par cho7 (site web personnel) . Évalué à 9.
Donc à choisir, je préfère un faux langage qui me donne de quoi bouffer, d'autant que je néglige pas pour autant le vrai langage (python bien sûr)
[^] # Re: Moi ! Moi ! Moi !
Posté par Sylvain Sauvage . Évalué à 5.
Trop gros, passera pas.
[^] # Re: Moi ! Moi ! Moi !
Posté par Louis Nyffenegger . Évalué à 1.
# Java6 sorti ?
Posté par Pinaraf . Évalué à 4.
Mais c'est vrai que des snapshots compilés et leur code source sont dispos depuis au moins 1 an.
http://mustang.dev.java.net
# Mouais
Posté par patapon . Évalué à 9.
Si tuveux faire du j2ee, les trucs fashion, c'est spring, hibernate et certains framework mvc (on entend bcp parler de tapestry).
Il parait que jsf c'est pas tip top malgré la grosse poussé commerciale de sun, je sais pas si les specs des ejb3 on été validés mais c'est pas tres repandu et meme si struts c'est mort, j'ai eu recemment vent d'un nouveau projet basé sur du struts dans la boite où j'effectue ma mission.
[^] # Re: Mouais
Posté par Dring . Évalué à 3.
Par contre, des applis struts, j'en vois des tonnes. Et pourtant, je ne trouve pas que struts soit la panacée, bien au contraire.
Je crois que struts 2 est en chantier, il s'agit de la fusion avec une autre techno.
Donc, sur la techno à apprendre, je dirais struts 2, jsf (un peu) et spring.
[^] # Re: Mouais
Posté par cho7 (site web personnel) . Évalué à 2.
Merci pour les infos.
[^] # Re: Mouais
Posté par Boa Treize (site web personnel) . Évalué à 2.
Par contre je crois qu'EJB 3.0 n'aura pas grand chose en commun avec ses prédécesseurs d'un point de vue technique, donc ça peut valloir la peine de s'y intéresser. (Je ne me suis pas encore penché dessus, ce n'est que du ouï-dire.)
[^] # Re: Mouais
Posté par Yannick (site web personnel) . Évalué à 2.
Pour les EJB, la version 3 est sortie avant cet été. Sun a pas mal communiqué sur les ejb entity 3.0, qui ressemblent à de l'hibernate avec annotation.
Pour struts, dire que c'est mort,je croit pas, y'a encore du monde dessus, bien que ça ne soit pas pas super génial (en plus la doc est pourrie). Pour JSF, j'ai pas essayé, mais il me semble que ça n'est pas prévu que pour le web.
Pour les trucs fashion, je dit Groovy, grails (version java de ruby on rails), et le MDA...
[^] # Re: Mouais
Posté par Sébastien Koechlin . Évalué à 3.
Pour l'instant Spring a bien la cote, et Struts est toujours dans les cartons parce qu'il est bien maitrisé et qu'on n'a pas trouvé un truc dont le coût d'apprentissage justifie la migration.
[^] # Re: Mouais
Posté par farib . Évalué à 2.
[^] # Re: Mouais
Posté par tene . Évalué à 7.
- si c'est un objet ne gérant aucune donnée, mais devant juste effectuer une opération.
- si c'est un objet ne gérant que des données "intermédiaire" devant effectuer une opération
- si l'objet gère en fait la donnée critique
- si l'objet est juste un message devant arriver quelque part
- etc...
C'est là que les concept de session bean (stateless et stateful), d'entity bean, de message driven bean, etc... apparaisse.
L'implémentation derrière est (comme dans pratiquement tout les cas) de montrer au client un objet qui a l'air "local", de marshaller l'appel (d'une façon ou d'une autre) afin de l'envoyer sur le réseau au serveur, qui va en déduire quel appel réel effectuer. Les nuances se situe généralement sur comment trouver l'objet distant et le fait que l'appel soit plus ou moins bloquant.
Si tu connais les web service (stateless session bean), COM+, Corba, RMI, ou même les RPC, tu as normalement une idée de ce que veulent faire les EJB.
Comme presque toujours dans le monde java, on y ajoute le mot "enterprise" parce que ça le fait, et on y ajoute une série de bullshit marketing style "scalability", "transparence", "performance", "reliablity",... etc...
Ce qui rend les EJB particulièrement lourd, c'est qu'à l'inverse de certain techno (genre COM, Corba ou Web Service), y'a pas vraiment une contrat first approach (tu ne définis pas avant dans un langage à part le contrat que ton objet expose), le contrat est en quelque sorte inclus dans le code. Et dans le cas des EJB<=3, ce code est particulièrement lourd (y'a bcp à taper) et complexe à maintenir (tu veux rajouter un param à une méthode, c'est vite long, et du coup, les développeurs fainéant que nous sommes préfère l'éviter, ce qui amène parfois à des design douteux). La version 3 ne change pas complètement cela, elle intègre la annotations java 5, donc c'est un peu moins lourd à écrire. Un autre désavantage des EJB, c'est qu'ils sont lourd et chiant à tester, ou même à utiliser, tu te retrouves vite à contraindre tes développeurs à avoir un serveur d'application surchargé sur chaque poste de dev. (pareil pour pas mal d'autre truc: unit tester un EJB est pas trivial, les perf sont parfois suprenante, etc...).
En très coutr pour répondre au journal: amha, si tu vises le court terme: Struts, Spring, Hibernate. Si tu trouves ça fun, regarde JSF, mais c'est pas encore top utilisé, et ça ne couvre pratiquement que la couche présentation.
ps: wikipedia en dit tous de même plus que moi: http://en.wikipedia.org/wiki/Enterprise_Java_Bean
[^] # Re: Mouais
Posté par farib . Évalué à 3.
T'as evoque les Web Services. Cet hiver j'ai eu une unite de Corba, et bien que je comprenne ce que ca fait, j'arrive toujours pas a voir d'interet concert a l'utilisation :-(
Java, c'est un petit peu "overwhelming". Je suis completement perdu dans les technos. Le tutorial J2SEE de Sun fait 1500 pages. On sait pas par ou commencer, et on a 500 IDE dont le seul argument semble etre qu'il te fait pisser du code plus rapidement que le voisin.
Bref, c'est mon point de vue, mais j'avoue que j'arrive pas du tout a rentrer dans la logique et le langage J2EE.
[^] # Re: Mouais
Posté par Sylvain Sauvage . Évalué à 2.
Euh, tu ne trouves pas un intérêt concret à faire exécuter sur une machine distante du code dans le langage que tu veux sans grosse différence avec du code local ?
Ou sous un autre angle : tu ne trouves pas un intérêt concret à offrir un service distant dans un langage évolué (= sans s'obliger à manipuler les octets d'une connexion TCP ou d'un paquet UDP (ni à gérer ces communications d'ailleurs)) sans forcer pour autant ni la plate-forme ni le langage des utilisateurs du service ?
[^] # Re: Mouais
Posté par Yannick (site web personnel) . Évalué à 1.
Je suis entrain de me dire que c'est dingue que je doive l'expliquer. Sun n'a pas fait une belle plaquette commerciale ??? Z'on des cours à prendre chez ms...
[^] # Re: Mouais
Posté par tene . Évalué à 2.
Euh vi c'est clair, le prob aussi c'est que java, c'est pas que Sun, et en général après avoir du te tapé oracle, bea, ibm et sun faire leur blabla sur le produit qui est plus scalable, plus secure, plus clusterisable, plus whatever que l'autre, t'en reste avec une impression de flou... ça le fait plus d'avoir un évangéliste ms entrainé pour, qui commence sa présenation par un slide t'expliquant que les slide ça fait chier tous le monde et que t'en auras qu'un... (bon après reste à voir la pertinence de l'info et retirer l'aspect marketing, mais en tous les cas c'est plus ludique).
Le problème général avec cette "infrastructure", c'est:
- qu'elle est relativement complexe, un hello world en "J2EE" est atrocement compliqué (par rapport à ce que ça devrait être). Pratiquement tu te retrouves vite avec un bulldozer pour écraser une mouche. Et ce n'est pas parce qu'une solution est "d'entreprise" que ça veut dire qu'elle est lourde...
- que la plupart de ces "avantages" ne sont pas réellement gratuit: dans le cadre de l'appel d'objet distant le vrai problème n'est pas la technologie de "transport" (EJB, COM, Corba, etc...) mais la définition du contrat entre les parties, et pour cela, la technologie n'aide pas. Dans le cas du clustering, le problème sera d'avoir un système cohérent en cas de crash (principalement la persistence des données) et là dessus, la techno ne peut que partiellement aidé (on reste obligé de se poser la question et si on intérragit avec des systèmes tiers ça devient vite très complexe). Le même raisonnement s'applique à la plupart des "parties" de J2EE.
- que ce n'est pas si "standard" que cela, tous le monde implémente un peu le standard "à sa mode" avec ses extensions, ce qui veut dire que l'avantage du standard est nettement moindre. (ceci dit c'est clair que ça vaut mieux qu'une anarchie complète). Il faut aussi ne pas oublier que le "standard" est relativement libre: il impose l'organisation du binaire, pas des sources par exemple.
Allez j'y retourne... (faire du des EJB dialoguant avec un fax en envoyant un sms...)
[^] # Re: Mouais
Posté par Nelis (site web personnel) . Évalué à 1.
Spring et Hibernate sont incontournables.
Pour les frameworks web:
Struts, ça commence à dater un peu (mais c'est encore très utilisé).
Spring-MVC, le framework web de Spring est assez simple et très flexible.
Tapestry, un framework web orienté composants est très très bien fait.
Sinon, EJB 3, ça sera très similaire à Hibernate, donc dans un premier temps, focalise toi sur Hibernate.
Bon courage
# JSF
Posté par Narmer . Évalué à 3.
Je suis à peu près dans la même situation que toi, mais nous migrons actuellement d'un framework masterisant java 1.4 à du spring/struts/sitemesh/quartz , log4j , hibernate et tous les autres mots clefs à la mode. ça me permet de me remettre au gout du jour.
Je te conseille d'accentuer ton effort sur JSF et de ne pas te focaliser que sur cet outil de sun , je te conseille callisto nouvellement releasé et qui integre le developpement JSF. Si ce n'est pas déja fait il faut vraiment s'impregner des notions de JavaServer Faces, car les notions de composant réutilisable, d'intégration dans l'ide favorise vraiment la productivité.
Il y a aussi oracle JDevelopper qui integre les JSF. De plus jdev integre nativement je crois les ADF la bibliothèque impressionnante de composant jsf d'oracle.
Hope that helps . . .
JamesHolmes.com Java Server Faces Resources
http://www.jamesholmes.com/JavaServerFaces/
Developing Smart Web UIs with Ajax, JSF and ADF Faces
http://www.oracle.com/technology/pub/articles/cioroianu_jsfa(...)
https://ajax4jsf.dev.java.net/
Librairie des composant jsf d'alfresco
http://wiki.alfresco.com/wiki/Component_Library
MyFaces - the free JSF Implementation
http://www.irian.at/myfaces-sandbox/home.jsf
Eclipse Callisto
http://www.eclipse.org/callisto/
Oracle ADF (JSF Components)
http://www.oracle.com/technology/products/jdev/htdocs/partne(...)
jsf [RIALTO - Rich Internet Ajax Toolkit - OpenSource]
http://rialto.application-servers.com/wiki/jsf
etc etc ..
[^] # Re: JSF
Posté par cho7 (site web personnel) . Évalué à 2.
Merci pour tout tes liens.
Je vais tenter d'approffondir l'experience JSF (qui m'avait bien plu quand même, mais vraiment gachée par ce maudit Sun Creator)...
Sinon hibernate revient assez souvent aussi, j'vais donc aller jeter un oeil, histoire de voir ce qu'il en est.
Merci.
# Du libre !
Posté par clearstream . Évalué à 3.
Un petit article pour avoir une idée de l'avancement des travaux (c'est un peu vieux...) :
http://www.redhat.com/magazine/012oct05/features/java/
gcj avec classpath fait aujourd'hui tourner "out of the box" Eclipse, Azureus, Tomcat, JOnAS, etc...
Classpath :
http://www.gnu.org/software/classpath/
JOnAS :
http://jonas.objectweb.org/
Fedora a actuellement la meilleur intégration de java (libre). La faq :
http://fedoraproject.org/wiki/JavaFAQ
# jsf c'est de la daube
Posté par kraman . Évalué à 1.
Lourd, chiant a developper, impossible a debugger.
Le code HTML genere est imbittable avec moult javascript de partout.
Le modele n'est pas si propre que ca.
Tu perds la navigation back/next (ca depend surement de l'utilisation que tu en fait ca).
Bref, j'en garde un plutot mauvais souvenir.
Perso, j'ai vraiment pas apprecie et je le deconseillerais fortement au taff si on me demande mon avis.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.