En quoi JEE6 a simplifié le dév d'appli ?

[Romain Pelisse]

Bonjour à tous,

Je prépare une conférence sur le thème en quoi JEE 6 a réduit la "souffrance" du développement par rapport au précédentes (oui, le titre n'est pas super, mais il rend un peu mieux en anglais). J'étais parti pour faire ça comme "un homme, un vrai", avec ma "bite et mon couteau", quand je me suis dis que ça serait beaucoup plus intéressant en fait de demander un peu de feedback - en autres sur cette liste. 

En effet, plutôt que de sommairement décrété ceci ou cela, c'est beaucoup mieux en JEE 6 - parce que je le pense, il est probablement plus intéressant de voir ce que vous tous trouvez de mieux. Bref, si vous ne deviez retenir que une chose des améliorations que JEE 6 a apporté, laquelle retiendriez vous ? 

--
Romain PELISSE,
"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it" -- Terry Pratchett
Belaran ins Prussia (blog)     (... finally up and running !)

[ehsavoie]

Salut,
<autopromo>Si tu étais venu voir ma conférence J2EE m'a tuer tu le
saurais ;)</autopromo>
1/ presque plus de descripteurs de déploiement en XML : moi qui doit
maintenir des EJBs 2.0 et maintenant 2.1 je galère - surtout que 90%
ne sert à rien ou presque.
2/ des conteneurs embarqués (je ne sais pas si c'est la JSR ou la
mode) mais ça c'est vraiment cool. Respect pour Cactus mais
franchement pouvoir tester ses composants dans leurs conteneurs pour
pas grand chose c'est juste de la balle.
3/ des profiles : pas besoin de se prendre toute la pile pour
développer et déployer une application.
4/ des performances en termes de démarrage du serveur qui sont sans
communes mesures avec avant. Qui se souvient du temps de démarrage
d'un Weblogic ou d'un Websphere ?
5/ Franchement les EJBs ne sont plus ce qu'ils étaient : plus de home
de remote ou de local interface avec les deux descripteurs (le
normalisé et l'autre) , bref fini XDoclet
6/ Convention over configuration : ne pas avoir à tout définir mais
que ce qui t'intéresse.
Bref c'est pas encore le Nirvana du développeur mais on entend le
chant des Walkyries :op



----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie


2012/8/26 Romain Pelisse <bel...@gmail.com>:

> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes
> lescastcodeurs.
> Pour envoyer un message à ce groupe, adressez un e-mail à
> lescast...@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
> lescastcodeur...@googlegroups.com.
> Pour plus d'options, consultez la page de ce groupe :
> http://groups.google.com/group/lescastcodeurs?hl=fr

[Romain Pelisse]

2012/8/26 ehsavoie <emmanuel...@gmail.com>

Salut,
<autopromo>Si tu étais venu voir ma conférence J2EE m'a tuer tu le
saurais ;)</autopromo>

Elle est pas en ligne quelques part, cette super conf ?  ;) 

 

1/ presque plus de descripteurs de déploiement en XML : moi qui doit
maintenir des EJBs 2.0 et maintenant 2.1 je galère - surtout que 90%
ne sert à rien ou presque.
2/ des conteneurs embarqués (je ne sais pas si c'est la JSR ou la
mode) mais ça c'est vraiment cool. Respect pour Cactus mais
franchement pouvoir tester ses composants dans leurs conteneurs pour
pas grand chose c'est juste de la balle.
3/ des profiles : pas besoin de se prendre toute la pile pour
développer et déployer une application.
4/ des performances en termes de démarrage du serveur qui sont sans
communes mesures avec avant. Qui se souvient du temps de démarrage
d'un Weblogic ou d'un Websphere ?

Je n'ai pas connu, mais j'ai entendu dire 45 minutes ...

 

5/ Franchement les EJBs ne sont plus ce qu'ils étaient : plus de home
de remote ou de local interface avec les deux descripteurs (le
normalisé et l'autre) , bref fini XDoclet
6/ Convention over configuration : ne pas avoir à tout définir mais
que ce qui t'intéresse.
Bref c'est pas encore le Nirvana du développeur mais on entend le
chant des Walkyries :op

:D 

[Bruno Margerin]

2012/8/26 ehsavoie <emmanuel...@gmail.com>

Salut,
<autopromo>Si tu étais venu voir ma conférence J2EE m'a tuer tu le
saurais ;)</autopromo>
1/ presque plus de descripteurs de déploiement en XML : moi qui doit
maintenir des EJBs 2.0 et maintenant 2.1 je galère - surtout que 90%
ne sert à rien ou presque.
2/ des conteneurs embarqués (je ne sais pas si c'est la JSR ou la
mode) mais ça c'est vraiment cool. Respect pour Cactus mais
franchement pouvoir tester ses composants dans leurs conteneurs pour
pas grand chose c'est juste de la balle.
3/ des profiles : pas besoin de se prendre toute la pile pour
développer et déployer une application.
4/ des performances en termes de démarrage du serveur qui sont sans
communes mesures avec avant. Qui se souvient du temps de démarrage
d'un Weblogic ou d'un Websphere ?
5/ Franchement les EJBs ne sont plus ce qu'ils étaient : plus de home
de remote ou de local interface avec les deux descripteurs (le
normalisé et l'autre) , bref fini XDoclet
6/ Convention over configuration : ne pas avoir à tout définir mais
que ce qui t'intéresse.
Bref c'est pas encore le Nirvana du développeur mais on entend le
chant des Walkyries :op

D'accord pour les grandes lignes ci dessus.

Pour les petits details, j'aime:

 - @Lookup et l'unification du nomage des ressources (EJB en particulier).

 -  Les amelioration notables au niveau injection et annotations pour JSF.

 - Et bien sur, comme mentionne si dessus, de gros progres des serveurs implementant la spec JEE6, meme chez ibm parait-il?

Pour les petis regrets:

 - I'idee d'un singleton EJB est interessante, je regrette part contre qu'elle ne s'applique pas "Cluster wide". J'ai "la chance" de travailler avec une base de donnees qui n'accepte pas plusieurs update simultanees sur une meme table. Un singleton a travers le cluster, ca aurait ete bien. Ou alors c'est moi qui est foire mon code, mais il me semblait bien que sous glassfish 3.1.2, mon singleton au sein de mon cluster, n'etait pas garanti. il me semble que ce soit possible avec Jboss, mais ca aurait ete bien si ca faisait partie de la spec.

 -  J'aurais aimer une methode "officielle (Spec JEE)", pour specifier une "Connection Factory" a associer avec un MDB. Pour l'instant ca ma l'air d'etre propre a chaque Server d'Application. Une fois encore, c'est peu etre que ca existe, et que je suis ignorant.

Bruno

[Benoit Perroud]

> Elle est pas en ligne quelques part, cette super conf ? ;)

http://www.slideshare.net/ehsavoie/j2ee-ma-tuer

<trollDuLundiMatinAvantDeMangerUneGrenouille>
j'aime bien le titre
</trollDuLundiMatinAvantDeMangerUneGrenouille>

[ehsavoie]

Ce qui me permet de rester en mode autopromotion ;)
Un point essentiel à rappeler est qu'en Java et en J(2)EE on est
retrocompatible (ou presque).
Ainsi le code écrit en 1998 sur de l'EJB 2 tourne dans un JBoss 6 !!!
Le seul problème pour un JBoss 7.1 est que les descripteurs d'EJB de
JBoss ne sont plus compatibles avec ceux ecrits pour JBoss 3.2 et le
nommage JNDI qui n'est pas surchargeable (et comme indiqué plus haut
maintenant c'est 'normalisé').
Pour voir ce miracle technologique www.silverpeas.org ;)
Fin du mode autopromotion

----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie

2012/8/27 Benoit Perroud <ben...@noisette.ch>:

[Antonio Goncalves]

Hello,

Il manque un petit truc à la liste d'Emmanuel qui fait que Java EE 6 nous facilite la vie : déployer une application dans un war (si on reste dans le profile web). C'est tout con mais on n'a plus d'ear à se taper (plugin ear ou assembly de Maven) et surtout une gestion du classloader normée avec les war, donc pas de surprises (l'ear c'est toujours le bazard entre serveurs d'appli).

Et puis il y a l'injection de dépendances qui peut être faite de manière extrêmement simple (avec un simple @Inject) ou plus élaborée si besoin (qualifier, alternatives...). 

<troll>Et puis de toute façon, avec le départ de Rod et la mort annoncée (par moi) de Spring, on n'a plus trop le choix</troll>

Antonio (de retour de vacances ;o)

2012/8/26 ehsavoie <emmanuel...@gmail.com>

--
Antonio Goncalves
Software architect and Java Champion

Web site | Twitter | LinkedIn | Paris JUG | Devoxx France

[Emmanuel Lécharny]

Le 8/27/12 10:45 AM, Antonio Goncalves a écrit :

> <troll>Et puis de toute façon, avec le départ de Rod et la mort annoncée
> (par moi) de Spring, on n'a plus trop le choix</troll>

Je partage complètement ta vision sur Spring, et ça date pas d'hier.
Quand à savoir s'il y a d'autre choix, je dis oui : un simple container
de servlet. Pas besoin de plus...


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[Nicolas Delsaux]

2012/8/27 Emmanuel Lécharny <elec...@gmail.com>:

>
> Je partage complètement ta vision sur Spring, et ça date pas d'hier. Quand à
> savoir s'il y a d'autre choix, je dis oui : un simple container de servlet.
> Pas besoin de plus...
>

Tu prends jamais de vacances, hein ?
Perso, dans mon contexte, ça suffira sans doute pas : il me faut des
MDB, du JMS, du remoting, j'en passe et des meilleures ...
--
Nicolas Delsaux

[Thomas Recloux]

2012/8/27 Nicolas Delsaux <nicolas...@gmail.com>

Tu prends jamais de vacances, hein ?
Perso, dans mon contexte, ça suffira sans doute pas : il me faut des
MDB, du JMS, du remoting, j'en passe et des meilleures ...

Ne serait ce que pour la gestion des transactions.

--
Thomas Recloux

[ehsavoie]

Oui avec les ressources externes comme un conteneur JCR ;)

----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie

2012/8/27 Thomas Recloux <thomas....@gmail.com>:

[Emmanuel Lécharny]

Le 8/27/12 11:08 AM, Nicolas Delsaux a écrit :

> 2012/8/27 Emmanuel Lécharny <elec...@gmail.com>:
>> Je partage complètement ta vision sur Spring, et ça date pas d'hier. Quand à
>> savoir s'il y a d'autre choix, je dis oui : un simple container de servlet.
>> Pas besoin de plus...
>>
> Tu prends jamais de vacances, hein ?

:)

> Perso, dans mon contexte, ça suffira sans doute pas : il me faut des
> MDB, du JMS, du remoting, j'en passe et des meilleures ...

Rien ne t'empêche de faire du JMS sans J2EE... Pour du MDB, JMS suffit.
Remoting, y a plein de solutions pas mal aussi...

[Nicolas Delsaux]

2012/8/27 ehsavoie <emmanuel...@gmail.com>:

> Oui avec les ressources externes comme un conteneur JCR ;)

Ou alors ... un broker JMS, une base Neo4j en même temps (bon, on va
peut-être pas faire la liste des back-ends fournis par JCA, hein).


--
Nicolas Delsaux

[Nicolas Delsaux]

2012/8/27 Emmanuel Lécharny <elec...@gmail.com>:

>
> Rien ne t'empêche de faire du JMS sans J2EE...

Tu peux (je le fais quand j'envoie des messages depuis mon client),
mais à quoi bon se fatiguer quand tu dispose de JEE complet ?

> Pour du MDB, JMS suffit.
> Remoting, y a plein de solutions pas mal aussi...
>

Et de la même manière pourquoi, mais POURQUOI irais-je m'embêter à
utiliser une solution personnalisée quand la solution normalisée est
disponible et semble fonctionner correctement ? Je changerais
peut-être d'avis plus tard, hein, mais pour l'instant, je m'en
contente assez bien (enfin, je crois).

--
Nicolas Delsaux

[Emmanuel Lécharny]

Le 8/27/12 11:28 AM, Nicolas Delsaux a écrit :

Moi, je dis ça, je dis rien... J'aime pas les usines à gaz. J'ai trop
fait de J2EE depuis 13 ans et à chaque fois, la solution aux problèmes
que l'on avait était de couper dans le gras tout ce qui était fait par
le serveur, pour utiliser des éléments de base. On terminait
généralement avec qq chose stye tomcat + driver JDBC de base...

Mais, bon, chacun son plaisir :)

[Nicolas Labrot]

En lisant ton message j'ai trouvé approprié le terme "réduit la souffrance".

On n'aura plus trop le choix ce qui est un risque d'être prisonnier et de devoir subir.

2012/8/27 Antonio Goncalves <antonio....@gmail.com>

[Antonio Goncalves]

"être prisonnier", ah, la peur du développeur Java et de ses 42 frameworks de log qui lui procure de la liberté. Pas de soucis à se faire de ce coté là : déjà se mettre d'accord sur une API, puis ensuite avoir le choix parmis les 5/6 implémentations (ce qui permet d'avoir une phase de POC, de test, et de stress test équivalente à 1/3 de la durée du projet). 

Depuis qques mois je bosse à coté d'un développeur .Net et je commence à comprendre les bienfaits d'une dictature ;o)  

Antonio (démocrate dans l’âme... mais quand même)

2012/8/27 Nicolas Labrot <nit...@gmail.com>

[Nicolas Labrot]

Comme si avoir un JSR et N implémentation était synonyme de simplification et d'absence de poc et de stress test. En attendant un certain nombre de JSR sont le fruit d'un n ème framework mais qui était pour le coup innovant.

L'ensemble de ce fil n'a fait pour l'instant que montrer que JEE 6 réduit la souffrance. On est encore loin de la dictature éclairée. Si tant est que celle de Microsoft est éclairée.

2012/8/27 Antonio Goncalves <antonio....@gmail.com>

[Antonio Goncalves]

Ah non, justement, ce n'est pas ce que j'ai dit. Le monde Java est déjà suffisamment compliqué avec une API et n implémentations, alors lorsqu'on cumule les 1001 fwk qui "font pareil mais en mieux" on n'est pas sortie de l'auberge. Après, je n'ai pas suffisamment d’expérience et je ne dis pas que les projets .Net sont plus simples ou si le taux d'échec est plus faible. Tout ce que je vois c'est que les développeurs .Net se font moins chiés que nous.

Dans ma jeunesse, mes premières missions se résumaient à faire du RAD sous Visual Basic. J'ai même fait comme ça une grosse appli de gestion des sinistres automobiles pour une boite d'assurance (toujours en prod d'ailleurs !). Depuis que je fais du Java (et je ne compte plus les années) je n'ai jamais réussi à avoir le même niveau de productivité. Alors, oui, c'est vrai, mes applis VB étaient "moches" (car le code métier était directement codé dans le bouton, pas de couche, pas de découplage...) mais on développait vachement plus vite.

Donc, Java EE 6 simplifie les dev (réduit la souffrance), mais ça reste des dev Java, donc, compliqués et qui font souffir

2012/8/27 Nicolas Labrot <nit...@gmail.com>

[Emmanuel Lécharny]

Le 8/27/12 5:51 PM, Antonio Goncalves a écrit :

> Ah non, justement, ce n'est pas ce que j'ai dit. Le monde Java
> est déjà suffisamment compliqué avec une API et n implémentations, alors
> lorsqu'on cumule les 1001 fwk qui "font pareil mais en mieux" on n'est pas
> sortie de l'auberge. Après, je n'ai pas suffisamment d’expérience et je ne
> dis pas que les projets .Net sont plus simples ou si le taux d'échec est
> plus faible. Tout ce que je vois c'est que les développeurs .Net se font
> moins chiés que nous.
>
> Dans ma jeunesse, mes premières missions se résumaient à faire du RAD sous
> Visual Basic. J'ai même fait comme ça une grosse appli de gestion des
> sinistres automobiles pour une boite d'assurance (toujours en prod
> d'ailleurs !). Depuis que je fais du Java (et je ne compte plus les années)
> je n'ai jamais réussi à avoir le même niveau de productivité. Alors, oui,
> c'est vrai, mes applis VB étaient "moches" (car le code métier était
> directement codé dans le bouton, pas de couche, pas de découplage...) mais
> on développait vachement plus vite.

Mais c'était vachement plus du client lourd sans avoir de logique métier
sur le serveur... Ca change aussi vachement la complexité des
développements...

Mois aussi, quand je codais sans me préoccuper de la scalabilité, de la
concurrence d'accès, de la sécurité, etc... ça allait vachement plus vite !
Bref, comparer des Apple avec des Samsung...

[Nicolas Labrot]

2012/8/27 Emmanuel Lécharny <elec...@gmail.com>

C'est quoi le rapport? :D
 

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

[Nicolas Labrot]

Je suis d'accord sur la stack JEE. A coté de cela il y a les stacks Grails, Play... qui s'approchent bcp d'une piqure de morphine.

2012/8/27 Antonio Goncalves <antonio....@gmail.com>

[Emmanuel Bernard]

Le problème de la morphine, c'est l'overdose. Et c'est là que s'arrete la métaphore... ou pas? :)

2012/8/27 Nicolas Labrot <nit...@gmail.com>

[David Screve]

>
> Depuis qques mois je bosse à coté d'un développeur .Net et je commence à
> comprendre les bienfaits d'une dictature ;o)

Effectivement, pendant que l'un passe 30% de son temps à choisir le
framework top moumoute qui fait papa maman, mais pas trop, avec une
communauté pas trop petite pour être sûr que le produit sera maintenu
encore pendant une éternité (soit environ 2 ans..), l'autre produit du
logiciel dès le début.....

Dans un contexte où on recentre le métier de développeur sur la
production pure et dure de logiciel avec un time to market non
négociable, les environnements fermés sont un vrai plus.

Un développement .Net est très très balisé et ne laisse pas de place
aux surprises : pas de choix de l'OS, pas de choix du serveur
d'application, pas de choix de langage.

Après, on aime ou on aime pas, c'est une question de goût...mais
personnellement, je n'aurais pas été contre payer 300 ou 400 euros
pour avoir un IDE Java de la classe de Visual Studio.

David

[Patrice Trognon]

ben la heureusement que je suis assis, si meme toi Antonio tu en viens à rejoindre le mouvement des vieux cons

blasés par les n framework on n'est pas arrivé !

tu as résumé ce que je pense de l'écosystème java depuis plusieurs années, ton sentiment de 'bien être' dans le monde

.NET est le mien dans le monde Cocoa, c'est vrai que quand on a un vrai chef d'orchestre qui joue son rôle et qui tranche

franchement cela simplifie grandement notre travail de pauvre mortel.

Pat

[David Screve]

+1000

Je n'ai jamais atteint un niveau de productivité suffisant à mon goût
en Java...et c'est pas une question d'expérience, parce qu'en 6 mois
je me suis trouvé plus productif en Objective-C.

On 27 août, 17:51, Antonio Goncalves <antonio.goncal...@gmail.com>
wrote:

[Stephane Maldini]

Je peux pas m'empecher de jouer le fanboy modele et je me permet de repondre au <troll> d'Antonio. 

Printemps est loin de la mort annoncée par Oracle and friends, d'ailleurs je comprends meme pas pourquoi on voudrait  voir un framework mort, a moins d'avoir été victime de violences brutales par ce dernier. Il me semble que Rod ne touche plus a quoi que ce soit depuis perpete (faudrait checker entre autres sur https://github.com/SpringSource/), ce qui franchement limite les consequences de son depart a la presse a scandale et a deux ou trois potes investisseurs. 

2012/8/27 Antonio Goncalves <antonio....@gmail.com>

--

Stéphane MALDINI

--

[Antonio Goncalves]

Bon, "vieux", pas encore, "con", peut-être un peu ;o)

Oui, je suis plus que blasé par les 1001 frameworks Java qui font "pareil que le petit copain mais en mieux" tout ça parceque le lead developeur a un égo surdimensionné et qu'il veut faire mieux que le voisin. Je suis tellement blasé que j'ai même eu l'idée folle de proposer à l'expert group Java EE 7 une API de logging pour toute la stack Java EE (http://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2012-03/message/39). Tout le monde trouve l'idée superbe... mais maintenant faut trouver le mec assez malade pour être spec lead. Bref.

Je vous envie tous de faire des applis Twitter-like, des Google-like et des Facebook-like avec 900 millions d'utilisateurs, des contraintes de sécurité, de scalabilité, d'ergonomie et d'accessibilité tout ça en 24/7 et 18 langues. Moi je ne croise que des clients qui font des applis CRUD (+ un peu de logique métier) sur une base de donnée avec qques milliers d'utilisateurs et qui, dans 80% des cas, se bananent. Non, je ne dis pas que l'unique faute revient à l'écosystème Java (loin de là), mais ça y contribue. Chez un client j'ai même vu passer une note européenne pour essayer de comprendre pourquoi les projets Java coutaient si cher (et pour rassurer Emmanuel Lecharny, cette note ne parlait même pas de Scale, les DIs sont c... mais pas à se point là ;o)

Bref, Java EE 6 simplifie, mais il rationalise surtout : tout le monde égal devant la même API (c'est pas mal pour trouver du developpeur à 350€/j). Après, si Twitter ou Facebook n'utilisent pas Java EE 6, c'est qu'ils ont tout compris. Ensuite, si votre pauvre appli CRUD utilise les derniers fwk en version alpha pour faire plaisir au tech lead, c'est un autre pb (un pb d'égo à priori).

Antonio

2012/8/27 Patrice Trognon <ptro...@gmail.com>

[Nicolas Labrot]

Il s'appelle Intellij et c'est de la balle. Et de mon experience de Visual (qui s'arrete à la 2003) ce n'était pas la panacé

[Nicolas Labrot]

Faire du JEE pour faire une pauvre appli CRUD c'est effectivement couteux :)

2012/8/27 Antonio Goncalves <antonio....@gmail.com>

[Antonio Goncalves]

Lorsque je bossai pour BEA j'étais pas mal en contact avec l'équipe R&D qui developpait le serveur d'appli. Je peux te dire que j'ai pas mal discuté avec les gars qui developpaient le connecteur JTA et j'avais accès aux sources. Bah effectivement, pour faire un pôv commit dans Oracle, t'es bien content d'avoir JTA qui te cache toute la plomberie dégueux, et JTA fait partie de Java EE (et puis comme on est des gros feignants, un petit JPA sur JDBC ça aide aussi pour une pauvre appli CRUD)

2012/8/27 Nicolas Labrot <nit...@gmail.com>

[David Screve]

Oui, faut que je l'essayer depuis des mois (années...)

[Patrice Trognon]

plus généralement le soucis viens du manque de leadership, dans les écosystèmes a la .NET ou Cocoa c'est clair

tu as un boss bien désigné tout le monde va se mettre au pas derrière et n'a pas le choix, si ce n'est dégager. c'est ainsi

tu vas prendre ce qui est proposé point.

Ce genre de monde est en effet très rassurant, je ne connais pas celui de .NET, j'ai côtoyé longtemps celui de Qt avant que

ça ne parte en sucette, celui de Cocoa est parfait car la le chef est absolu.

Sans tomber dans ces approches très dirigistes le monde java opensource est dans le totale inverse, et le grand nombre

de développeur sur ces technos n'arrange pas le problème bien sur, c'est en effet plus qu'usant car le dev devient de 

l'assemblage et non du développement. quand j'ai commencé a bosser ce monde n'existait pas et tu avais une opposition

entre deux autres mondes : les devs et les intégrateurs. Aujourd'hui ceux qui font du dev java me font souvent penser

à des intégrateurs, ils vont piocher dans des produits a la pérennité douteuse et au mieux développer un peu de glue pour 

les faire fonctionner ensembles.

Ces frameworks en reviennent a gérer toutes les parties intéressantes, c'est a dire les parties techniques, qu'est ce qui reste

au dev si ce n'est de l'intégration. perso ce genre de dev ne m'interesse pas du tout.

C'est en ce sens que je dis toujours que le dev java des années 2000 / 2010 est le développeur cobol des années 70 / 80,

un executant qui ne fait que du SI, et le SI ç'est du SQL point. bref rien de bien excitant.

La seule expertise qui reste est celle qui consiste a connaitre les 1001 frameworks afin de faire le choix de celui qu'on va 

utiliser. Cela a été largement débattu ici j'ai même souvent ironisé sur la durée de vie de ces frameworks :)

tout cela est du a une chose : le manque flagrant de leadership dans le monde java, en effet le comité de certification devrait

être beaucoup plus directif et dire clairement : bon pour le Logging l'api c'est la notre, les autres sont a proscrire, et les logiciels

qui n'utilisent pas notre api ne seront certifiés ! ainsi de suite pour chaque api technique.

Cela remettrait un peu les pendules à l'heure et éviterait ces guerres d'ego a la noix dont tu parles.

au lieu de s'exciter le neurone sur des features réservées a quelques barbus cela serait plus profitable de clarifier ce gros boxon.

Pat

[David Screve]

Certes, mais comme antonio, l'immense majorité des appli que je croise
sont de ce type....et les seules que j'ai croisées qui n'en n'étaient
pas, ben elles avaient tellement besoin de performance et d'eviter
tout overhead vers la base de données que ça s'est fini en jdbc parce
que Hibernate et Spring...heu, comment dire...c'était juste pas
possible..'

David

On 27 août, 22:31, Nicolas Labrot <nith...@gmail.com> wrote:
> Faire du JEE pour faire une pauvre appli CRUD c'est effectivement couteux :)
>

> 2012/8/27 Antonio Goncalves <antonio.goncal...@gmail.com>

>
>
>
>
>
>
>
> > Bon, "vieux", pas encore, "con", peut-être un peu ;o)
>
> > Oui, je suis plus que blasé par les 1001 frameworks Java qui font "pareil
> > que le petit copain mais en mieux" tout ça parceque le lead developeur a un
> > égo surdimensionné et qu'il veut faire mieux que le voisin. Je suis
> > tellement blasé que j'ai même eu l'idée folle de proposer à l'expert group
> > Java EE 7 une API de logging pour toute la stack Java EE (

> >http://java.net/projects/javaee-spec/lists/jsr342-experts/archive/201...).

> > Tout le monde trouve l'idée superbe... mais maintenant faut trouver le mec
> > assez malade pour être spec lead. Bref.
>
> > Je vous envie tous de faire des applis Twitter-like, des Google-like et
> > des Facebook-like avec 900 millions d'utilisateurs, des contraintes de
> > sécurité, de scalabilité, d'ergonomie et d'accessibilité tout ça en 24/7 et
> > 18 langues. Moi je ne croise que des clients qui font des applis CRUD (+ un
> > peu de logique métier) sur une base de donnée avec qques milliers
> > d'utilisateurs et qui, dans 80% des cas, se bananent. Non, je ne dis pas
> > que l'unique faute revient à l'écosystème Java (loin de là), mais ça y
> > contribue. Chez un client j'ai même vu passer une note européenne pour
> > essayer de comprendre pourquoi les projets Java coutaient si cher (et pour
> > rassurer Emmanuel Lecharny, cette note ne parlait même pas de Scale, les
> > DIs sont c... mais pas à se point là ;o)
>
> > Bref, Java EE 6 simplifie, mais il rationalise surtout : tout le monde
> > égal devant la même API (c'est pas mal pour trouver du developpeur à
> > 350€/j). Après, si Twitter ou Facebook n'utilisent pas Java EE 6, c'est
> > qu'ils ont tout compris. Ensuite, si votre pauvre appli CRUD utilise les
> > derniers fwk en version alpha pour faire plaisir au tech lead, c'est un
> > autre pb (un pb d'égo à priori).
>
> > Antonio
>

> > 2012/8/27 Patrice Trognon <ptrog...@gmail.com>

>
> >> ben la heureusement que je suis assis, si meme toi Antonio tu en viens à
> >> rejoindre le mouvement des vieux cons
> >> blasés par les n framework on n'est pas arrivé !
>
> >> tu as résumé ce que je pense de l'écosystème java depuis plusieurs
> >> années, ton sentiment de 'bien être' dans le monde
> >> .NET est le mien dans le monde Cocoa, c'est vrai que quand on a un vrai
> >> chef d'orchestre qui joue son rôle et qui tranche
> >> franchement cela simplifie grandement notre travail de pauvre mortel.
>
> >> Pat
>

> >> Le 27 août 2012 à 17:51, Antonio Goncalves <antonio.goncal...@gmail.com>

> >> a écrit :
>
> >> Ah non, justement, ce n'est pas ce que j'ai dit. Le monde Java
> >> est déjà suffisamment compliqué avec une API et n implémentations, alors
> >> lorsqu'on cumule les 1001 fwk qui "font pareil mais en mieux" on n'est pas
> >> sortie de l'auberge. Après, je n'ai pas suffisamment d’expérience et je ne
> >> dis pas que les projets .Net sont plus simples ou si le taux d'échec est
> >> plus faible. Tout ce que je vois c'est que les développeurs .Net se font
> >> moins chiés que nous.
>
> >> Dans ma jeunesse, mes premières missions se résumaient à faire du RAD
> >> sous Visual Basic. J'ai même fait comme ça une grosse appli de gestion des
> >> sinistres automobiles pour une boite d'assurance (toujours en prod
> >> d'ailleurs !). Depuis que je fais du Java (et je ne compte plus les années)
> >> je n'ai jamais réussi à avoir le même niveau de productivité. Alors, oui,
> >> c'est vrai, mes applis VB étaient "moches" (car le code métier était
> >> directement codé dans le bouton, pas de couche, pas de découplage...) mais
> >> on développait vachement plus vite.
>
> >> Donc, Java EE 6 simplifie les dev (réduit la souffrance), mais ça reste
> >> des dev Java, donc, compliqués et qui font souffir
>

> >> 2012/8/27 Nicolas Labrot <nith...@gmail.com>

>
> >>> Comme si avoir un JSR et N implémentation était synonyme de
> >>> simplification et d'absence de poc et de stress test. En attendant un
> >>> certain nombre de JSR sont le fruit d'un n ème framework mais qui était
> >>> pour le coup innovant.
>
> >>> L'ensemble de ce fil n'a fait pour l'instant que montrer que JEE 6
> >>> réduit la souffrance. On est encore loin de la dictature éclairée. Si tant
> >>> est que celle de Microsoft est éclairée.
>

> >>> 2012/8/27 Antonio Goncalves <antonio.goncal...@gmail.com>

>
> >>>> "être prisonnier", ah, la peur du développeur Java et de ses 42
> >>>> frameworks de log qui lui procure de la liberté. Pas de soucis à se faire
> >>>> de ce coté là : déjà se mettre d'accord sur une API, puis ensuite avoir le
> >>>> choix parmis les 5/6 implémentations (ce qui permet d'avoir une phase de
> >>>> POC, de test, et de stress test équivalente à 1/3 de la durée du projet).
>
> >>>> Depuis qques mois je bosse à coté d'un développeur .Net et je commence
> >>>> à comprendre les bienfaits d'une dictature ;o)
>
> >>>> Antonio (démocrate dans l’âme... mais quand même)
>

> >>>> 2012/8/27 Nicolas Labrot <nith...@gmail.com>

>
> >>>>> En lisant ton message j'ai trouvé approprié le terme "réduit la
> >>>>> souffrance".
>
> >>>>> On n'aura plus trop le choix ce qui est un risque d'être prisonnier et
> >>>>> de devoir subir.
>

> >>>>> 2012/8/27 Antonio Goncalves <antonio.goncal...@gmail.com>

>
> >>>>>> Hello,
>
> >>>>>> Il manque un petit truc à la liste d'Emmanuel qui fait que Java EE 6
> >>>>>> nous facilite la vie : déployer une application dans un war (si on reste
> >>>>>> dans le profile web). C'est tout con mais on n'a plus d'ear à se taper
> >>>>>> (plugin ear ou assembly de Maven) et surtout une gestion du classloader
> >>>>>> normée avec les war, donc pas de surprises (l'ear c'est toujours le bazard
> >>>>>> entre serveurs d'appli).
>
> >>>>>> Et puis il y a l'injection de dépendances qui peut être faite de
> >>>>>> manière extrêmement simple (avec un simple @Inject) ou plus élaborée si
> >>>>>> besoin (qualifier, alternatives...).
>
> >>>>>> <troll>Et puis de toute façon, avec le départ de Rod et la mort
> >>>>>> annoncée (par moi) de Spring, on n'a plus trop le choix</troll>
>
> >>>>>> Antonio (de retour de vacances ;o)
>

> >>>>>> 2012/8/26 ehsavoie <emmanuel.hugon...@gmail.com>

> >>>>>>> 2012/8/26 Romain Pelisse <bela...@gmail.com>:

> ...
>
> plus de détails »

[Cédric Beust ♔]

2012/8/27 Patrice Trognon <ptro...@gmail.com>

tout cela est du a une chose : le manque flagrant de leadership dans le monde java, en effet le comité de certification devrait

être beaucoup plus directif et dire clairement : bon pour le Logging l'api c'est la notre, les autres sont a proscrire

Non merci, je préfère infiniment laisser le marché décider et seulement à ce moment, essayer de standardiser sur la solution qui a émergé.

Et... surprise ! C'est exactement comme ça que le monde Java fonctionne !

-- 

Cédric

[Nicolas Labrot]

On est bien d'accord que Hibernate/Spring et JEE c'est blanc bonnet et bonnet blanc ?!

2012/8/27 David Screve <david....@gmail.com>

[Nicolas Labrot]

Si on suit ta vision, les devs java sont de gros lemmings avides de nouveauté préférant la découverte technologique à la création de valeurs et à la pérennité...

A vous entendre on croirait que seul le monde Java est confronté à des situations résolues par des pattern implémentés par des frameworks et non pas par le SDK de "base". Suis je bete, je suis en face de personnes ne comprenant pas l’intérêt de l'IoC, des DI et autre pattern de haut niveau. Forcement le SDK de base .Net / O-C est suffisant ;) (taunt).

Une simple recherche sur google montre qu'en faite sur ces thématiques la situation semble identique à celle de Java : pléthore de réponse à un problème.

2012/8/27 Patrice Trognon <ptro...@gmail.com>

[Patrice Trognon]

Bon, si tu le prend au niveau de l'affect restons en la aucun intérêt, et de toute façon cela a déjà été très longuement débattu donc, bref.

Antonio a exprimé les choses de façon moins catégoriques donc moins blessantes que moi et je suis totalement en phase avec lui, je dis juste que c'est un problème de l'écosystème java et que si rien n'est fait pour clarifier les choses cela ne fera que s'amplifier.

Après tu l'entend ou pas ce n'est pas mon prob, mais alors pas du tout :)

Patrice

[David Screve]

Non, on n'est pas d'accord....

On 28 août, 00:07, Nicolas Labrot <nith...@gmail.com> wrote:
> On est bien d'accord que Hibernate/Spring et JEE c'est blanc bonnet et
> bonnet blanc ?!
>

> 2012/8/27 David Screve <david.scr...@gmail.com>

[Thibaud Vibes]

Je suis d'accord: on est pas d'accord

[Nicolas Labrot]

Il manque cruellement le chargement à chaud des modifs

[Nicolas Labrot]

Mes propos étaient très (trop?) provocateur mais sans "affect".

C'est peut être parce que je suis un utilisateur de Spring mais que malgré tout je commence à mettre des inject à la place des autowired... ;)

2012/8/28 Patrice Trognon <ptro...@gmail.com>

[Nicolas Labrot]

Il va falloir m’éclairer sur quoi tu n'es pas d'accord, parce que Hibernate implemente JPA et Spring et CDI/EJB (désolé Antonio) c'est plus ou moins kif kif.

2012/8/28 David Screve <david....@gmail.com>

[Nicolas Delsaux]

2012/8/28 Nicolas Labrot <nit...@gmail.com>:

> Il va falloir m’éclairer sur quoi tu n'es pas d'accord, parce que Hibernate
> implemente JPA et Spring et CDI/EJB (désolé Antonio) c'est plus ou moins kif
> kif.
>

Oula
oula
la première partie de ta phrase ne me pose pas vraiment de problème,
mais la seconde a un côté "c'est bon, un pickup US et une midjet
japonnaise, c'est pareil, c'est des bagnoles" (ceci était une
métaphore à la con A NE PAS FILER).

--
Nicolas Delsaux

[Nicolas Labrot]

J'en suis conscient mais conceptuellement cela rend le même service (DI) par plus ou moins les mêmes moyens

2012/8/28 Nicolas Delsaux <nicolas...@gmail.com>

[David Screve]

Ben dire que faire du JEE c'est faire du Spring/Hibernate, je ne suis
pas d'accord....On vit très bien sans tout en faisant du JEE.

On 28 août, 10:03, Nicolas Labrot <nith...@gmail.com> wrote:
> Il va falloir m’éclairer sur quoi tu n'es pas d'accord, parce que Hibernate
> implemente JPA et Spring et CDI/EJB (désolé Antonio) c'est plus ou moins
> kif kif.
>

> 2012/8/28 David Screve <david.scr...@gmail.com>

[Stephane Maldini]

C'est franchement une bonne nouvelle que JEE permette de standardiser une pratique presente depuis longtemps (Spring/Hibernate) : Des frameworks un peu moins attachés aux JCP qui drivent les JCP avec une paire d'année d'avance, exactement ce que les industriels ont besoin (des technos avec 2/3 ans de lag). C'est un peu comme bétonner la base, maintenant on a une pratique commune vulgarisée, le DI et les ORMs.

 Bon maintenant les memes frameworks et de nouveaux veulent se passer d'ORM en mappant les query plutot que les objets comme Spring Data - de DI en utilisent des singletons et des methodes statiques a la scala/play ou en injectant les methodes (Groovy AST, Mixins) . En plus ils sont la sur le point de se demander l'interet de Servlet API (Vert.x, Play), de la messagerie Java vs une messagerie plus polyglotte, d'une securite etendue aux services webs (oAuth and co), de hadooptruc, de cloudmachin, de reloading, de plus de web, de plugins et d'integration. Je suis pas sur que ca vaille le coup de standardiser tout sauf si ca va plus ou moins vite. Les nouveaux standards ressemblent plus a des patterns : rien embarquer dans la session server, manipuler des streams , templater cote client, distribuer la charge horizontale avec un broker, ne pas hesiter a avoir d'autres langages et plateformes (combinaisons de CRUD et realtime), distribuer les données dans des stores en memoire etc.

Des tas de trucs qui semblaient encore chiant a faire y'a une paire d'année a moins d'etre une grosse web entreprise, mais qui semble a la portee de tous grace aux nouveaux frameworks et des pratiques eprouvees.

2012/8/28 David Screve <david....@gmail.com>

--

Stéphane MALDINI

--

[Nicolas Labrot]

Ok j'ai finalement compris ce que tu disais

2012/8/28 David Screve <david....@gmail.com>

[Nicolas Labrot]

Je remets 1€ dans la machine à débat!

Je m’apprêtais à migrer de JPA 1 à JPA 2 et notamment à passer des requêtes paramétrées Criteria Hibernate en Criteria JPA 2.

Erreur! La syntaxe est devenue illisible et le nombre de ligne double. C'est à n'y rien comprendre... ;)

2012/8/28 Nicolas Labrot <nit...@gmail.com>

[Pierre-Yves Ricau]

:) sinon, il y a http://www.querydsl.com/

Pierre-Yves Ricau

http://www.piwai.info

[Nicolas Labrot]

Oui, je l'utilisais déjà sur un projet JDBC, je crois que je vais aussi l'utiliser avec un projet JPA... :)

2012/8/30 Pierre-Yves Ricau <py.r...@gmail.com>

[ehsavoie]

Tu as querydsl intégré avec spring-data-jpa (anciennement Hades)

----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie

2012/8/30 Nicolas Labrot <nit...@gmail.com>: