Java est-il un choix coûteux pour les entreprises ?

Citation:

---

Envoyé par benzoben

Pour paraphraser bon nombre de post, ce n'est pas Java en tant que langage qui est en cause. En même temps c'est peut être Java en tant que langage qui est en cause!
Java a simplifié pas mal de choses. Je développe depuis longtemps avec ce langage donc peut être que mon regard n'est pas objectif, mais objectivement, développer une appli en Java est beaucoup plus simple qu'en C/C++ (probabilité troll 85%) : pas de pointeur, pas de virtual, pas de destructeur ou de malloc...
En plus, le monde Java (et pas Java, la différence est importante) a apporté de la doc, standardisée, des normes. Que de boulot prémaché (je ne critique pas au contraire)! Plus besoin de formation, un bouquin à la fnac et je suis architecte JEE! Java a permis a plein de boites de se monter en recrutant du pas cher, du copier coller sur internet, de l'offshore (ah l'offshore).
En revanche, la gestion de projet, les budgets, les formations ça ne se code pas en Java!
Une dernière remarque : si .NET était si bien, ce débat n'aurait pas lieu vu qu'on bosserait tous dessus!

---

Mon problème avec Java/JEE, c'est surtout ce qui tourne autour.
Quand je veux mener un projet avec Java/JEE en contrainte, je me pose des questions :
- démarche ?
- Serveur ? Il y en a tant...
- outils ?
- interop avec d'autres outils ?
- API, Framework...

Bref, des questions ordinaires.
Avec .NET
- démarche idem mais je me base sur des modèles plus facilement puisqu'intégrés dans les outils
- Serveur IIS (permet montée en compétence et spécialisation car ne change pas)
- Outils : Visual Studio Team Studio/ALM pour gérer le projet
- Interop avec toute la suite MS
- API/Framework : idem java... faut chercher mais on a pas mal de choses dispo en natif dans .NET avec les WPF, Silverlight...)

On voit donc que l'environnement d'une plateforme outre le côté gratuit/payant permet de réellement cerner les coûts de formation des équipes.

Citation:

---

Envoyé par hwoarang

.Le probleme, c'est que ton postulat de base, c'est :
- Developper Java = aime perdre du temps dans des architectures inutiles, compliquées et onereuses.
- Developper Access = va a l'essentiel

---

Non, c'est que tu as lu et compris. Nul part je n'ai dit ou écrit qu'Access prévaut sur Java. C'est ton interpretation, pas la mienne. Donc c'est TON postulat:mrgreen:

- Aimer perdre du temps dans des architectures inutiles, compliquées et onereuses.= Possible en Java; avec les exemples donnés dans ce post, comme en .Net ou en C++ ou en C ou en PHP ou en RUBY et peut couter cher, même en libre.
- Aller a l'essentiel = Pas nécessairement le meilleur choix, mais souvent basé sur un raisonnement de bas prix qui est dangereux

Aller à l'essentiel pour moi, c'est prendre la techno et l'archi la plus appropriée au sujet que je traite, ne pas passer du temps à imaginer des cas tordus d'application (règle des 80/20) ou à ré-inventer la roue, et surtout rester proche du besoin du mec qui s'en servira tous les jours.

Et dans les technos récentes (hormis un peu de cRAD en .Net, et encore); il est très facile de dériver.

Il y a des gens aujourd'hui qui passe un temps dingue à faire des choses simples en .Net. Et pourtant, aux techdays, ils l'avaient vu :mouarf::mouarf:

Et un L4G comme Access, je trouve malgrè ses défauts qu'il comble / a comblé un grand vide, qui est l'application jetable; que toutes les technos actuelles ne rendent pas simple. d'ailleurs je ne sais plus quel grand mag il n'y a pas longtemps publié un article ou les DSI fustigent les architectes actuels qui de part leur entêtement à appliquer des process de développement lourds et longs provoquent justement l'apparition de développement de proximité en L4G.

Avec du recul (sur plus de 20 ans), .Net et Java ne sont pas les technos les plus productives que l'on a pu voir. Ca n'empêche pas qu'elles disposent de leurs qualités (je ne fais pas dans l'élitisme) - et notamment surtout d'une richesse impressionante - mais que leur usage puisse être dans le temps controversé. Quand un éditeur se rend compte après migration en retard de 2 ans, que le développement prendra un facteur de 0.75 du fait de la techno; c'est un constat économique à considérer. Ca change le chiffre d'affaire, la rentabilité, les RH...
Car souvent, sur un existant, il y a la version de l'époque; donc les tests et toussa, c'est super, mais il faut les faire, les intégrer, faire l'IC; administrer une plateforme de dev là où existe avant un serveur unique...
Tout ça a un coût. L'ignorer, c'est prendre le risque de gréver un projet.

Citation:

---

Envoyé par ALCINA

L'avantage de dotnet, c'est qu'il y a les briques de microsoft et ça suffit,
DAL => entity, couche de communication => WCF, validation => dataannoration, presentation => xaml/asp/mvc, analyse => reporting services, repository => TFS.
Et c'est tout, du coup n'importe quel archi utilise les même outil ce qui n'est pas vrai pour java.
Et dotnet n'est au final pas plus cher, maintenance plus facile, dev moins cher cf prix du marché.
Les couts d'infrastructure son identique, aucune grossr entreprise prends une distribution linux gratuite, trop de risque.
Les couts d'infra de windows ou de ibm, sun, red hat, sont relativement identique.
Au final un projet dotnet coutera moins cher qu'il soit de 1500/10000/100000 jour/homme.
En dessous les entreprises prennent php.

---

ta des statistiques ou donnée contrète sur le sujet ? ou bien c'est comme les propos de bush sur les armes de destruction massive en irak?

Citation:

---

Envoyé par batataw

D'autant plus qu'un Dev Java coûte plus cher que les autres développeurs à expérience équivalente (Encore une fois, je parle du Web).

---

Source?

Citation:

---

Envoyé par batataw

C'est bête mais rien qu'installer son environnement de travail demande un temps fou. J'ai passé 1/2 journée sur Tomcat.

---

il y a comme un problème là, c'est genre de tâche qui prend même pas 30 minutes

Citation:

---

Envoyé par B.AF

La seule partie sur laquelle .Net a pour moi un avantage non discutable de productivité c'est la partie client lourd (Forms vs Swing).

---

Ca fait un bail que la communaité demande à sun (et maintenant oracle) de nous pondre un swing2 ou autre chose n'assurant pas la compatibilité, histoire d'avoir quelque chose de propre, léger et facile à gérer :mrgreen:

Certains disent que les développements java sont lourds, en partie oui, mais il faut comparer des choses comparables.

S'il s'agit de faire une application autonome (client lourd), la différence se fera plutôt dans la connaissance de Swing ou d'un Delphi/C++ Builder (ou équivalent). En pratique, c'est presque équivalent.

S'il s'agit d'un développement web, c'est une autre histoire.
La question est plutôt : qu'est ce qui fait que ces applications sont plus difficiles à réaliser.
Les différentes couches y sont pour beaucoup. Et la couche présentation tout particulièrement.
Là, on peut gagner en productivité en choisissant un framework plutôt qu'un autre (par exemple JSF+RichFaces vs Struts+Struts-Layout).
Avec ces architectures distribuées sont venues des problématiques nouvelles, l'interopérabilité devient un besoin (chose qu'on ne faisait pas trop il y a 10 ans) etc...

Le problème est peut-être dans le choix des framework. Ça bouge tout le temps, une solution arrive à peine à maturité qu'elle est remplacée par autre chose... Trouver des vrais experts devient de + en + difficile et ça peut être un frein quand il s'agit de décider.
Une fois le choix établi, encore faut-il former des équipes correctement.
Hibernate (ou les ORM plus généralement) est un outil intéressant, mais tout faire à coup d'entité peut se révéler désastreux en terme de performance (surtout si elles sont mal pensées).

Bref, les discours à l'emporte pièce ne servent pas à grand chose et ne font rien avancer... dire que java n'est pas un bon langage me semble franchement déplacé et pour moi, le problème n'est pas là.

Citation:

---

Envoyé par tchize_

Ca fait un bail que la communaité demande à sun (et maintenant oracle) de nous pondre un swing2 ou autre chose n'assurant pas la compatibilité, histoire d'avoir quelque chose de propre, léger et facile à gérer :mrgreen:

---

Cela semble être le cas avec JavaFX 2.0 ;)

a++

Citation:

---

Envoyé par lequebecois79

Source?

---

http://www.itjobswatch.co.uk/default...d=900&lid=2618

C'est le moteur de recherche que j'utilise, regarde bien les salaires des Devs Java. De plus c'est pas un secret regarde les offres d'emplois.

Citation:

---

Envoyé par lequebecois79

Citation:

---

C'est bête mais rien qu'installer son environnement de travail demande un temps fou. J'ai passé 1/2 journée sur Tomcat.

---

il y a comme un problème là, c'est genre de tâche qui prend même pas 30 minutes

---

Tu as extrait le bout qui t'arrange de mon message, c'est pas très cool. Ca veut dire que tu es un génie??? Prends un mec qui n'a jamais touché à Tomcat et dis lui de faire une installation manuelle de son site avec les permissions en lecture et écriture qui vont bien, l'ajout des librairies externes, modifier le port (8080), la pile d'erreur est illisible...Tu me diras s'il a mis 30min. L'interface Web de Tomcat est tout sauf claire et ergonomique.

Je me répète mais c'est vraiment le Framework Play qui m'a réconcilié avec le développement Web en Java.

Citation:

---

Envoyé par batataw

Prends un mec qui n'a jamais touché à Tomcat et dis lui de faire une installation manuelle de son site avec les permissions en lecture et écriture qui vont bien, l'ajout des librairies externes, modifier le port (8080), la pile d'erreur est illisible...Tu me diras s'il a mis 30min. L'interface Web de Tomcat est tout sauf claire et ergonomique.

---

Déjà si l'entreprise prend un mec qui n'a jamais touché à Tomcat et qui semble n'avoir jamais touché à Java non plus (i.e. les traces illisibles), je doute de la réussite du projet. Cela cache du "policy-driven development", dans lequel un projet est conduit par les humeurs du manager, et non les compétences des ressources ^_^


Plus sérieusement, on peut comparer les technos mais sur le même postulat de départ alors. D'après toi, la courbe d'apprentissage est meilleure avec .net qu'avec java. C'est tout à fait possible (je ne connais rien à .net), mais ce n'est qu'un seul point de comparaison parmi d'autre.

Citation:

---

Envoyé par bugsan

Plus sérieusement, on peut comparer les technos mais sur le même postulat de départ alors. D'après toi, la courbe d'apprentissage est meilleure avec .net qu'avec java. C'est tout à fait possible (je ne connais rien à .net), mais ce n'est qu'un seul point de comparaison parmi d'autre.

---

Il y a effectivement une différence simple qui est que le contenu de l'éditeur côté microsoft fourni des guidances et des standards.

Après aujourd'hui, quand je vois NetBeans, ce n'est plus si vrai. Ce le fut.

.Net a un avantage sur le tooling qui est un politique d'éditeur, et force est de reconnaitre que VS 2010 est très bon, TFS aussi.
En même temps, il y a aussi des inconvénients, qui sont souvent des cas d'utilisation poussée.

Au niveau langage, je pense qu'aujourd'hui du fait d'une richesse plus importante, C#en .net 4.0 est plus complexe à aborder que Java pour les particularités du langage. Après sur le paradigme objet, c'est strictement similaire. C'est très facile de passer de l'un à l'autre. Peut être cependant qu'en Java il faut chercher le framework qui va bien pour ajouter un peu plus; mais ça ne fait pas de mal non plus de se confronter à un écosystème riche.

Citation:

---

Envoyé par bugsan

Déjà si l'entreprise prend un mec qui n'a jamais touché à Tomcat et qui semble n'avoir jamais touché à Java non plus (i.e. les traces illisibles), je doute de la réussite du projet. Cela cache du "policy-driven development", dans lequel un projet est conduit par les humeurs du manager, et non les compétences des ressources ^_^

---

Je n'ai pas parlé d'embaucher qui que ce soit. Quoique tu peux très bien réussir un entretien si la configuration du conteneur Web n'est pas requise.
Tomcat manuellement, c'est la misère à configurer (et c'est pas une demi heure). Bien sûr que l'on peut s'y faire aux traces façon Java mais elles ne sont pas intuitives.

Citation:

---

Envoyé par bugsan

Plus sérieusement, on peut comparer les technos mais sur le même postulat de départ alors. D'après toi, la courbe d'apprentissage est meilleure avec .net qu'avec java. C'est tout à fait possible (je ne connais rien à .net), mais ce n'est qu'un seul point de comparaison parmi d'autre.

---

Ca tombe bien moi aussi je n'en sais rien. Si tu me demandes mon avis je pense que oui car Microsoft maitrise de bout en bout son environnement de travail. Ca me fait penser, dés qu'on parle de Java, .NET est forcément évoqué comme si il n'existait qu'eux sur le marché du développement. Je ne suis ni anti, ni pour Java, un bon développeur se doit d'être polyglotte et maitriser des principes applicable à tous langages.

Citation:

---

Envoyé par batataw

Tomcat manuellement, c'est la misère à configurer (et c'est pas une demi heure). Bien sûr que l'on peut s'y faire aux traces façon Java mais elles ne sont pas intuitives.

---

Il faut juste dézipper et ton histoire de librairies additionnelle, ce n'est pas requis par tomcat. Quand au port, non seulement il est bien documenté dans la doc (server.xml) mais cette partie de la configuration est aussi accessible à partir de l'interface d'admin. Tout le reste dépend de facteur extérieurs à tomcat (la base de données utilisateurs demandée par l'application si elle ne l'embarque pas elle même, la configuration AJP si on t'as imposé de passer derrière un serveur apache avec du ajp, etc). Donc évidement si on t'as filé une webapp mal concue qui nécessite plein de config additionnelle et qu'elle est pas fournie avec les outils de config ou une doc clair, je vois pas comment le reprocher à tomcat :/

Citation:

---

Envoyé par tchize_

Il faut juste dézipper et ton histoire de librairies additionnelle, ce n'est pas requis par tomcat. Quand au port, non seulement il est bien documenté dans la doc (server.xml) mais cette partie de la configuration est aussi accessible à partir de l'interface d'admin. Tout le reste dépend de facteur extérieurs à tomcat (la base de données utilisateurs demandée par l'application si elle ne l'embarque pas elle même, la configuration AJP si on t'as imposé de passer derrière un serveur apache avec du ajp, etc). Donc évidement si on t'as filé une webapp mal concue qui nécessite plein de config additionnelle et qu'elle est pas fournie avec les outils de config ou une doc clair, je vois pas comment le reprocher à tomcat :/

---

Bah, d'un autre côté, quand on connait pas, on touche pas ! :bug:

(C'est souvent ceux qui ont fait le moins d'efforts pour comprendre qui critiquent le plus :mouarf:)

Citation:

---

Envoyé par tchize_

Il faut juste dézipper et ton histoire de librairies additionnelle, ce n'est pas requis par tomcat. Quand au port, non seulement il est bien documenté dans la doc (server.xml) mais cette partie de la configuration est aussi accessible à partir de l'interface d'admin. Tout le reste dépend de facteur extérieurs à tomcat (la base de données utilisateurs demandée par l'application si elle ne l'embarque pas elle même, la configuration AJP si on t'as imposé de passer derrière un serveur apache avec du ajp, etc). Donc évidement si on t'as filé une webapp mal concue qui nécessite plein de config additionnelle et qu'elle est pas fournie avec les outils de config ou une doc clair, je vois pas comment le reprocher à tomcat :/

---

Okay si je l'utilise sans toucher à rien, il va fonctionner mais bon j'ai besoin d'installer des librairies et régler les permissions et là ça se corse. La gestion des permissions est un vrai délice...L'interface d'admin date et elle n'est pas ergonomique du tout. Il faut comprendre une chose, je n'essaye pas de dénigrer Tomcat, je l'utilise sur un projet mais il n'est pas souple du tout. C'est pas parce que des gens si font sans broncher que l'outil est super. Une refonte de l'interface Web ne serait pas du luxe.

Je ne comprends pas l'emballement autour de ce "papier" : le gars vend des solutions clefs en main, basées sur de l'open source, pour DSI frileux voulant construire sur de l'open source afin de rien payer. Comment faire payer les DSI en question ? en leur disant attention l'open source en réalité ça coûte cher, autant payer mon open source à moi (enfin celui que j'ai packagé). Et ça fait 4 pages de "débat" sur développez...

Comme pour toutes les technos/langages, si tu prends des tocards à bas prix à la fin tu obtiens ce pour quoi tu as payé. Java étant le langage le plus visible actuellement c'est celui qui est le plus critiqué, mais ce fut le cas de C++ et C avant en leur temps...

PS : l'article en question, c'est de la pub hein, pas un papier de fond.

Si on parle des vieux langages utilisés en entreprise, moi je pense plutôt à ceux orientés gestion, c'est à dire le RPG ou le Cobol.

Et là, peut-être qu'effectivement, ils sont plus efficace que Java car ultra spécialisés dans leur domaine (la gestion) !

Sinon pour le web, il y a aussi PHP...

Parce que je partage la même conviction que l'auteur de l'article, j'ai développé mon propre Framework. Le mouvement "agile" dans le développement devrait aussi s'appliquer au framework que l'on utilise.





______________________________________________________________________________________________________________
[Mode PUBLI-REDACTIONNEL on]
Les constats :

• 1 les composants Swing de java sont primaires (Incomplet à l'usage ou trop complexe)
• 2 les outils disponibles sont trop nombreux (C'est une jungle technologique)
• 3 les interfaces graphiques sont délicates à maitriser (Multi entrée et Nombreux comportements à gérer)
• Les logiciels de gestion sont simples et répétitifs basés sur le template CRUD

Les objectifs de Abc-wtools sont :

• de faire gagner du temps lors du développement
• d'offrir un cadre de développement simplifié et robuste
• de limiter l'intervention du développeur aux problématiques métier
• d'apporter une solution Lite pour la mise en oeuvre de projet "Client Lourd"

Les services de Abc-wtools :

• Une architecture standard complète, à charge pour le Dev de réaliser la partie métier
• Des entités fonctionnelles nommées Fichier c'est la base de développement des objects métiers
• Des composants graphique unaire, des templates applicatif, des conteneurs pour construire des UI métier
• Des classes de service afin de synthétiser le codage, traitements des chaines, gestion des layout, des dates
• Un DAO SQL multi-SGDB pour la persistance des données métier

Le Développeur se concentre sur trois aspects fondamentaux du développement qui sont :

• le Modele Conceptuel de Données métier : définir les tables, les relations et les identifiants
• le Modele Conceptuel de Traitement métier : définir les transitions et les traitements de données
• les Interfaces Utilisateur : définir l'arborescence des menus et concevoir les écrans

La philosophie du framework Abc-wtools :

• Un framework de production finale (pas une sur-couche qui offre un nouveau potentiel)
• La gestion des packages doit-être une image de l'application métier (faciliter l'extension et le support)
• Un package égale une entité graphique fonctionnelle (Gagner en lisibilité)
• Des objets concrets (Garantir une utilisation intuitive)
• Le développeur manipule directement ses composants graphiques et ses données (Garder la maitrise)
• Ne coder que ce qui est nécessaire (Gagner en productivité)
• Rester Lite (Assurance de performance et de robustesse)
• Rester dans son domaine de définition (Faire peu, mais le faire bien)

Ce que n'est pas Abc-wtools :

• Une vitrine technologique
• Un environnement de travail standard
• L'outils magique

[Mode PUBLI-REDACTIONNEL off]

my 2 cents...

Le Monsieur de l'article, il a pas tout à fait tord, mais personnellement, j'accuserai plus la communauté informatique en général qu'un langage en particulier.
D'une manière générale, on trouve pleins de frameworks pour faire des trucs techniques et ça c'est un bon point. Maintenant, la profusion de solutions est forcément de nature à brouiller la vision d'une personne qui aimerait voir quelque chose de plus simple et clair qu'avant.
"Avant", on avait que notre C ou Cobol et puis c'est tout. Sous une apparence simple, un simple langage à sa disposition, on avait pleins de choses à faire soi-même mais bon ce n'était pas grave, chacun maitrisait son "bébé" et il était plus difficile d'accuser un simple langage qui finalement faisait bien ce que l'on attendait de lui (et on en attendait pas grand chose).
Avec un langage (enfin une plate-forme, une communauté) comme Java, c'est quand même bien moins clair.

Alors pourquoi je parle de la communauté informatique en général ?

Et bien c'est parce que je reste persuadé qu'il n'y a pas encore assez d'efforts réalisés autour de l'outillage pour aider les développeurs et c'est peut être à cause de cela que le Monsieur y dit que c'est compliqué et pas productif.
Avec tous les frameworks que l'on a, il serait vraiment souhaitable que l'on retrouve des L4G comme avant mais s'appuyant sur des solutions ouvertes. De mon point de vue il y a un réel manque de solutions "de bout en bout" outillées (de l'IHM à la base en passant par la couche "services/métier"). De plus des problématiques "éternelles" ne sont toujours pas correctements résolues, prenons un exemple simple :

- La validation des données depuis l'IHM jusqu'à la base de données en ne définissant qu'une fois les choses. Et ne me parlez pas de Seams (encore qu'un effort ait été fait) ou de la JSR "Bean Validation". Quand je dis une fois, je veux dire par exemple que si une données est stockée en VARCHAR(32) dans ma base de données (bon donc on a dit 32 qq part à un seul endroit), je veux avoir par défaut une validation de la longueur de la donnée au niveau de ma couche métier et idem dans la zone graphique de saisie. Et bien entendu si je dois générer un .xsd pour mon WebService, une contrainte "max 32" sera codée automatiquement.

Mais pour avoir cette vision de bout en bout, il faut faire des choix de frameworks et bâtir une solution qui fera forcément des choix d'utilisation de ces frameworks. Et tout le monde dira que c'est du "propriétaire" sauf que l'on devrait quand même arriver un qq chose de plus productif, enfin j'espère.


Bon je m'arrête là, je pars écrire un bouquin sur le futur de l'informatique :aie::mrgreen:

Citation:

---

Envoyé par ego

my 2 cents...

- La validation des données depuis l'IHM jusqu'à la base de données en ne définissant qu'une fois les choses. Et ne me parlez pas de Seams (encore qu'un effort ait été fait) ou de la JSR "Bean Validation". Quand je dis une fois, je veux dire par exemple que si une données est stockée en VARCHAR(32) dans ma base de données (bon donc on a dit 32 qq part à un seul endroit), je veux avoir par défaut une validation de la longueur de la donnée au niveau de ma couche métier et idem dans la zone graphique de saisie. Et bien entendu si je dois générer un .xsd pour mon WebService, une contrainte "max 32" sera codée automatiquement.

Mais pour avoir cette vision de bout en bout, il faut faire des choix de frameworks et bâtir une solution qui fera forcément des choix d'utilisation de ces frameworks. Et tout le monde dira que c'est du "propriétaire" sauf que l'on devrait quand même arriver un qq chose de plus productif, enfin j'espère.


Bon je m'arrête là, je pars écrire un bouquin sur le futur de l'informatique :aie::mrgreen:

---

la JSR 303 defini un standard pour une application en Java (de la couche presentation jusqu'au DAO). Ce n'est pas de la responsabilite de cette specification de gerer des technologies completement differentes (comme une base de donnees). Il faudrait se tourner vers des editeurs qui fournissent ce genre de support. JSF 2 supporte la Bean Validation pour verifier la bonne saisie des champs.

Citation:

---

Envoyé par ego

- La validation des données depuis l'IHM jusqu'à la base de données en ne définissant qu'une fois les choses. Et ne me parlez pas de Seams (encore qu'un effort ait été fait) ou de la JSR "Bean Validation". Quand je dis une fois, je veux dire par exemple que si une données est stockée en VARCHAR(32) dans ma base de données (bon donc on a dit 32 qq part à un seul endroit), je veux avoir par défaut une validation de la longueur de la donnée au niveau de ma couche métier et idem dans la zone graphique de saisie. Et bien entendu si je dois générer un .xsd pour mon WebService, une contrainte "max 32" sera codée automatiquement.

---

Sauf que pour aller au bout, il faut qu'en cas de modif de la bdd, le programme change sa validation. Autrement dit, une simple requete SQL peut necessiter une recompilation. A moins de faire une verification dynamique à chaque demarrage. Mais deja que les applis actuelles sont plutot lentes à demarrer...