Discussion :

[javahasbeen]

Bonjour,

Le titre est provocateur... mais je suis surtout un peu amère.

J'ai 12 ans d'expérience en C++ et Java (principalement en Java).

Pour moi faire du Java c'est rouler en Berline de luxe avec des API de base tout confort (java.util, java.swing...)
Mais là, je me retrouve à chercher du travail... et on ne me propose que du J2EE.

Je n'ai rien contre tous ces Frameworks (Strut, Spring, Hibernate...) mais je ne trouve pas ça très intéressant et surtout faire du Web ça ne me motive pas du tout.

Bref, ce que j'aime c'est faire de vrais applications, du client lourd, de l'informatique industrielle, du Swing, de l'algorithmique, du multi-threading, de l'optimisation mémoire.

Tout ça, on peut le trouver en C++ mais en Java c'est le désert au niveau
travail...

J'ai l'impression qu'il n'y en à que pour du J2EE ou alors du C/C++ ou encore du Cobol...

[dotEden]

Bonsoir,

J2EE est une architecture logiciel, tu peux très bien faire des clients lourds.
Par exemple, au cours de mes études j'ai réalisé une applet Tetris qui envoyait/recevait le score à une Servlet.
Si tu veux faire une application de communication par exemple (du genre TeamSpeak ou Mumble) tu peux très bien concevoir de la faire en J2EE.
Le développement en couche est juste à la mode parce qu'il permet du véritable travail d'équipe.

Cordialement

[paissad]

Bonjour,
et donc, quelle est la véritable question chef ?

[javahasbeen]

Bonsoir,

J2EE est une architecture logiciel, tu peux très bien faire des clients lourds.
Par exemple, au cours de mes études j'ai réalisé une applet Tetris qui envoyait/recevait le score à une Servlet.
Si tu veux faire une application de communication par exemple (du genre TeamSpeak ou Mumble) tu peux très bien concevoir de la faire en J2EE.
Le développement en couche est juste à la mode parce qu'il permet du véritable travail d'équipe.

Cordialement

Ta réponse ne m'étonne pas du tout... et elle me chagrine...
J2EE est effectivement souvent utilisé parce que Struts, Hibernate et compagnie c'est à la mode...

Alors qu'en réalité, souvent ce n'est pas la meilleure solution... On peut très bien travailler en équipe sans ces frameworks qui n'ont pas que des avantages... (ClearCase et compagnie... C'est ça qui permet de travailler en équipe)

Par exemple envoyer les résultats de ton Tétris sur une servlet... Ca n'a juste souvent pas de sens... Un serveur sous PHP est moins cher et le script PHP pour récupérer ton score fait quelques lignes sans avoir un maintenir un serveur Tomcat...

De même, j'ai lu aujourd'hui même le post d'un développeur qui était déçu par Hibernate et la complexification ajoutée par cette sur-couche... Alors qu'en SQL et conception de base de données c'était un pro.

Je crois que je vais plutôt essayer de me trouver un boulot sur Android...

[paissad]

De même, j'ai lu aujourd'hui même le post d'un développeur qui était déçu par Hibernate et la complexification ajoutée par cette sur-couche... Alors qu'en SQL et conception de base de données c'était un pro.

on peut voir le post ?

[dotEden]

Ta réponse ne m'étonne pas du tout... et elle me chagrine...
J2EE est effectivement souvent utilisé parce que Struts, Hibernate et compagnie c'est à la mode...

Alors qu'en réalité, souvent ce n'est pas la meilleure solution... On peut très bien travaillé en équipe sans ces frameworks qui n'ont pas que des avantages... (clearcase et compagnie... C'est ca qui permet de travailler
en équipe)

Par exemple envoyer les résultats de ton tétris sur une servlet... Ca n'a juste souvent pas de sens... Un serveur sous PHP est moins cher et le script PHP pour récupérer ton score fait quelques lignes sans avoir un maintenir un serveur Tomcat...

De même, j'ai lu aujourd'hui même le post d'un développeur qui était déçu par Hibernate et la complexification ajoutée par cette sur-couche... Alors qu'en SQL et conception de base de données c'était un pro.

Je crois que je vais plutôt essayer de me trouver un boulot sur Android...

Je donnais juste un exemple, c'était un TD pour montrer l'intérêt de l'architecture, et comparer le PHP avec un Servlet n'a aucun rapport...
Ce que je décrivais c'était plus de la programmation sur différentes couches logiciels qui permet un travail collaboratif beaucoup plus pertinent. C'est comme si tu disais que le pattern MVC était nul, en réalité il s'agit juste de structurer ton application, si tu n'as pas besoin de couche réseau alors les J2EE n'ont pas grand intérêt.
Mais il faut savoir qu'en entreprise, les applications ont de plus en plus besoin de communiquer à travers un réseau Internet ou Intranet, donc cette évolution est logique.
Que tu fasses des applications Android n'y change rien par ailleurs.
Dernièrement, c'est le métier de développeur de s'adapter aux évolutions technologique.

Cordialement

[javahasbeen]

Je donnais juste un exemple, c'était un TD pour montrer l'intérêt de l'architecture, et comparer le PHP avec un Servlet n'a aucun rapport...

une servlet et un script PHP... A l'origine ca a la même fonctionnalité sur un serveur Internet.
Ca sert à remplir le rôle de script CGI.

Sauf que quand on a un besoin simple, le script PHP, tu l'as écrit en 30s chrono... (et pourtant, je ne suis pas fan de PHP et j'adore java )

[javahasbeen]

on peut voir le post ?

j'avais fait un peu des raccourcis... Mais le post est intéressant ainsi que la discussion qui s'en suit

http://www.developpez.net/forums/d10...ser-hibernate/

Je rejoins assez ce qui a été dit a un endroit; de mémoire les multiples couches tuent les applications.

Savez-vous que chez Yahoo à Grenoble (délocalisé/relocalisé depuis), ils avaient décidé de laisser tomber J2EE et de repasser à PHP...
Ce n'est pas par hasard, J2EE ou cela devrait faire gagner du temps... A l'arrivée on en perd en temps de développement (temps d'apprentissage des multi-couches, perte de temps à naviguer entre les différents fichiers du à l'utilisation systématique du design pattern MVC, complexification du debogage...) et en vitesse d'exécution (pleins de couches = pleins d'indirections)

[paissad]

Très honnêtement, j'apprécie PHP et tout. Mais quand tu auras à faire de très grosses applications web, où tu devras entre autre inter-connecter plusieurs sites de l'extérieur ou en intranet, .. où tu devras faire communiquer plusieurs applications entre elles, tu te rendras compte, de manière incontestable, de la supériorité de JEE sur PHP.
Il ne s'agit pas d'écrire un script ou une page de blog !
Faut comparer les technologies par rapport à des situations ... soyons pragmatiques.

Moi, je suis plus productif en Java et Java Web qu'en PHP, mais si je dois faire un blog où je dois faire que des petits posts, y a 9 chances sur 10 que je le fasse en PHP plutôt qu'en Java.
Si je dois faire une application bancaire où je dois faire communiquer plusieurs sites, ... je veux bien voir comment tu vas me le faire en PHP.

voilà voilà ... arrêtons de troller et cette discussion ne m'a pas l'air si productive que cela.
Il y a des moments et situations où même 'sed', 'awk', 'bash', ou 'perl' sont de loin plus appropriés que C/C++ ou Java. (alors qu'on sait pertinemment que c'est possible de le faire avec C ou Java ...)

Il n y a pas de mauvaise technologie, il n y a que des mauvais choix !

En espérant que ce topic soit clos

[javahasbeen]

Très honnêtement, j'apprécie PHP et tout. Mais quand tu auras à faire de très grosses applications web où tu devras entre autre inter-connecter plusieurs sites de l'extérieur ou en intranet, .. ou tu devras faire communiquer plusieurs application entre eux etc ... tu te rendras de manière incontestable de la supériorité de JEE sur PHP.
Il ne s'agit pas d'écrit un script ou d'une page de blog !
Faut comparer les technologies par rapport à des situations ... soyons pragmatiques.

Moi, je suis plus productif en Java et Java Web qu'en PHP, mais si je dois faire un blog où je dois faire que des petits posts, il y a 9 chances sur 10 que je le fasse en PHP plutôt qu'en Java.
Si je dois faire une application bancaire où je dois faire communiquer plusieurs sites, ... je veux bien voir comment tu vas me le faire en PHP.

voilà voilà ... arrêtons de troller et cette discussion ne m'a pas l'air si productive que cela.
Il y a des moments et situations où même 'sed', 'awk', 'bash', ou 'perl' sont de loin plus appropriés que C/C++ ou Java. (alors qu'on sait pertinemment que c'est possible de le faire avec C ou Java ...)

Il n y a pas de mauvaise technologie, il n y a que des mauvais choix !

En espérant que ce topic soit clos

Tu as pleinement raison...

Ce qui me chagrine... c'est qu'en discutant autour de moi, je me suis rendu compte que pleins de projets utilisent J2EE ou autres technologies satellites juste parce que ça a été vendu par une SSII à un DSI qui n'y comprenait rien. Alors qu'il existait des solutions bien plus simples. Ceci est particulièrement vrai sur des petits projets où parfois il n'y a même pas de web du tout...

[CyaNnOrangehead]

En fait pour résumer et pour traduire un peu le sens initiale du post, c'est que tu constates que le métier de développeur Java évolue vers de l'utilisation d'API toutes faites.

Je discutais avec un pote qui recrutait pour sa SSII, il me disait que maintenant, si tu ne connaissais pas le framework pouètepouète 54.39 tu ne trouvais pas de boulot.
C'est un peu exagéré, mais ça illustre bien la situation : il faut se mettre à la place des recruteurs.
Les années 2000 ont apporté sur le marché de l'emploi des tas de développeurs, et aujourd'hui, il faut les trier.
Juger un développeur sur ses qualités d'architectes, ce qui me semble pourtant un aspect important du métier, est mission impossible.
Par contre le juger sur les librairies qu'il a utilisées, ça c'est facile.
Donc maintenant on vas te demander si tu sais utiliser le dernier hibernate, le dernier truc à la mode.
Je ne pense pas que ce soit un critère représentatif de la qualité d'un developpeur, mais c'est un critère à la porté du premier RH venu.....

En tous cas c'est mon avis.

[Mat.M]

bonjour;

Par contre le juger sur les librairies qu'il a utilisées, ça c'est facile.

si pour faire un projet informatique tu ne fais qu'utiliser des bibliothèques de code toutes faites à ce moment-là c'est plus du tout du développement ,tu ne crois pas ?

En tout cas je suis totalement d'accord avec toi les gens qui font des recrutements ne semblent juger les candidats que sur les frameworks ou les bibliothèques utilisées.
Selon l'adage bien connu "il ne faut pas réinventer la roue"

Résultat des courses,n'importe quel développeur lambda est incapable de trouver l'algorithme d'un simple tri

[Mat.M]

Bref, ce que j'aime c'est faire de vrais applications, du client lourd, de l'informatique industrielle, du Swing, de l'algorithmique, du multi-threading, de l'optimisation mémoire.

*le client lourd : oui on peut en faire parfaitement avec Java comme avec tout autre outil de développement /langage
*info industrielle : c'est exact, il y a plutôt des projets en C++ bien que Java soit utilisé parfois
*algorithmique et multithreading , possible avec Java.L'algorithmique est indépendante de tout langage info.
Le problème en entreprise comme je l'ai écris c'est qu'il faut tout faire "éviter de réinventer la roue" donc utiliser des classes toutes faites...pour des projets infos.
*l'optimisation mémoire : on n'y touche pas trop en Java

[mala92]

En fait pour résumer et pour traduire un peu le sens initiale du post, c'est que tu constates que le métier de développeur Java évolue vers de l'utilisation d'API toutes faites.

Je discutais avec un pote qui recrutait pour sa SSII, il me disait que maintenant, si tu ne connaissais pas le framework pouètepouète 54.39 tu ne trouvais pas de boulot.
C'est un peu exagéré, mais ça illustre bien la situation : il faut se mettre à la place des recruteurs.

Ca ne date pas d'aujourd'hui.
En 2005, un collègue me disait (on avait 5 ans d'expérience) : "si je démissionne, je ne trouverai pas de boulot, je ne connais que Java, toutes les offres sont J2EE".

[CyaNnOrangehead]

bonjour;



si pour faire un projet informatique tu ne fais qu'utiliser des bibliothèques de code toutes faites à ce moment-là c'est plus du tout du développement ,tu ne crois pas ?

....

Résultat des courses,n'importe quel développeur lambda est incapable de trouver l'algorithme d'un simple tri

En effet ça a un nom, c'est de l'intégration.
J'ai un peu peur que l'informatique suive fatalement le chemin qu'à subi son ancêtre : l'électronique.
Aujourd'hui, dans les pays occidentaux, on ne soude plus, on ne consoit plus, on achète des modules tout fait.
Un transistor, on ne sais plus ce que c'est, on commande une nouvelle carte si y a un problème.

En info j'ai peur que ça devienne comme ça, on achètera des plugins avec des interfaces standardiser que l'on assemblera les unes avec les autres.
Il suffit pour c'en convaincre de voire ce qui ce passe avec les CMS web.

Sinon un algorithme de tri, c'est quoi? Ça sert à quoi ? ok je sort.

[Mat.M]

salut Yann entièrement d'accord avec toi c'est une évolution des choses probable

[CyaNnOrangehead]

salut Yann entièrement d'accord avec toi c'est une évolution des choses probable

Il nous restera alors plusieurs options de replis :
- S'adapter à l'intégration, pour nourrir la petite famille ! mais ne plus compter ce réaliser professionnellement (meeting, blabla et bouts de ficelles).

- Ce retrancher dans la recherche, et essayer d'inventer de nouveaux Algorithmes / Patterns, mais je ne sais pas si ça vous le fait aussi, quand j'ai l'impression d'avoir découvert quelque chose, il y a toujours quelqu'un pour l'avoir découvert avant moi et, force est de le constaté, souvent bien mieux aboutis que je que j'ai pu faire.
Bon en plus la recherche, de réputation, ça ne paye pas.

- Allez à la pèche ou devenir alcoolique, ou encore s'acheter un bateau et partir faire le tour du monde.... quoi que les trois ne soit pas incompatibles.

[zecreator]

J'arrive un peu tard sur le sujet.

Pour moi, qui ait pratiqué autant J2EE que PHP, je dois admettre que mon coeur balance du côté du dernier.

J'aime Java, mais surtout le côté IHM. Je préfère de loin la "simplicité" de PHP coté serveur que Java. J2EE, c'est un peu l'usine à gaz, et souvent vendue 2 à 3 fois plus cher qu'un développement J2SE + PHP. C'est surtout pour ça que J2EE est vendu par les SSII, car c'est plus de boulot, donc plus de temps homme à facturer, et surtout une expertise mieux reconnue que pour PHP et qui se paye au prix fort. Alors que concrètement, PHP peut répondre au mêmes enjeux et objectifs que J2EE.