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 ?

[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)

[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 )

[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

[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