Bonsoir,
Je n'ai jamais développer une application WEB en java donc je ne sais pas trop si la liste des avantages ci-dessous sont acceptables. (Dommage que ce soit obligatoirement en JAVA)

1. - Java est aujourd'hui un langage aussi rapide que le c++ pourvu qu'on ne l'utilise pas pour une application très lourde (jeux en ligne, logiciel de traitement d'image, encodage vidéo etc...)
2. - Java est organisé, il contient des classes bien conçu et bien reparties.
3. - Java est connu et donc plus de chance de trouver des développeurs java; pour concevoir ou amélioré une application.
4. - Java est gratuit et permet les mêmes avantages que le point 3
5. - Java est portable
(liste non exhaustive)

Mais évite de comparer java au php. Ils ne sont pas vraiment comparables plutôt java / .NET / C++ / Ruby

En espérant t'avoir aidé.

c++ et encore de loins et surtout pas le C

aussi rapide que le C++ tant qu'on ne fais pas de la merde avec
c'est tres permissif comme langage mais on le paye vite en perf si on fais des betises

+1

Citation : daedric

c'est tres permissif comme langage [...]

Je ne le savais pas ça, en est tu sûr ?

disons que tu as beaucoup de maniere de faire, tu peux 'jouer' assez facilement

comme j'ai vu une source sur ce site ou il y avais tous les champs de la classe qui etais dans une interface.... enfin voila c ce que je veux dire

Je crois que le coup de cette fameuse interface restera dans les anales...

je savais meme pas que c'etais possible :s

On peut voir cette interface ?

Sinon pour moi, l'intérêt de java c'est qu'il est très documenté comparé à d'autres langages, il offre des classes pour faire la plupart des choses simplement et rapidement, la gestion de la mémoire est aussi un vrai plus.

Citation : Ga3L

c'est qu'il est très documenté ...

Oui, Sulimo tu devrais mettre ceci dans ta liste très important.

N'hésite pas à mettre ce que tu as trouvé...

tu oublis les IDE java Netbeans et Eclipse qui ratatine les IDE des langages concurrents!

Nous en deuxieme année on a des cours d'Eclipse.
En premiere année on nous conseille Scite pour linux et notepad ++ pour Windows
Je trouve qu'ils sont pas mal, mais c'est vrai que c'est parfois fatidieux. Mais bon je trouve qu'on a plus de mérite.
Sinon pour moi Java, c'est la portabilité qui prime

Citation : Sulimo

Tout stage s'accompagne évidemment d'un rapport et je dois justement indiquer dans celui-ci pourquoi le langage Java a été choisit. Cependant cela ne plaira pas si j'écris qu'il m'a été imposé par l'entreprise. Demander les raisons à l'entreprise ? C'est déjà fait et les raisons sont purement fondées sur du bouche à oreille comme quoi Java est bien. Alors écrire cela dans le rapport de stage ne plaira pas non plus.

Si c'est la stricte vérité, pourquoi mentir ? Ta démarche est mauvaise : tu cherches à justifier le choix de personnes à leur place, alors que ces personnes n'avaient, à te lire, pas de vraie justification.

Ça serait certainement plus intéressant de te poser la question de la pertinence de ce choix, retrospectivement - et alors ton avis aurait nettement plus d'importance.

Il faudrait au moins savoir les autres contraintes imposées par l'entreprise :

• type d'environnement (solaris, windows, linux, autres)
• contrainte au niveau des charges (load balancing, ...)
• utilisation d'autres applications Java à distances (via rmi par exemple)

AMHA, "justifier le choix de Java" c'est déjà très biaisé comme démarche. "Chercher des arguments postifis et négatifs" ça ressemble plus à "Pourquoi Java"/"Pourquoi pas Java", et c'est toujours plus riche et intéressant.

Et tu vois, plutôt que de chercher au hasard des qualités que Java possède, faire une liste de certaines contraintes (tu viens de parler de Windows et de la montée en charge) est plus intéressant : déjà, la portabilité que quasimment tout le monde t'a servi sans réfléchir, tu t'en fous.

Pour la montée en charge, c'est une piste intéressante : que vaut Java dans ce domaine, est-ce que les solutions mises en avant par SUN pour le web sont fiables à ce niveau ?

Citation : iPoulet

déjà, la portabilité que quasimment tout le monde t'a servi sans réfléchir, tu t'en fous.

Qu'il s'en foute de ça et les examinateurs s'en foutront de sa note aussi.

Bien que ce soit quelque chose de connu de tellement connu qu'on estime qu'on peu s'en foutre "java portable" reste une des phrases qui ont lancés java et je dirais même que c'est grâce à cette portabilité que java a sa place où il est aujourd'hui.
Si tu omets de cité la portabilité de java les ou l'examinateur risque d'omettre une chiffre à ta note. Bien qu'IPoulet s'en fou, je te conseil d'indiquer cette information.

oui mais la portabilitees c'est bien beau mais ca se fait pas tout seul non plus dans le code ... ne serais ce que pour les separateur de path (\\ sous windows, / sous linux)

portable c'est beau, mais c'est inutile si tous les pc de la boîte son sous windows. Là où est le problème c'est: pourquoi on a besoin d'un outil portable? C'est assurément un point dont pas mal de logiciels internes à une boîte se foutent.

De toute façon, il ne faut pas de voiler la face. Le fait d'utiliser Java était une contrainte dès le début du stage (probablement même défini dans ton sujet de stage).

Comme l'a déjà indiqué iPoulet, il vaut mieux voir pourquoi le choix de l'entreprise sur ce projet pour cette technologie était intéressante/pas intéressante.

Il y a des choses évidentes mais que les gens ne pensent pas forcement comme : tous les développeurs de la boite connaissent java donc ça sera plus maintenable par la suite. Si t'avais proposé une solution et une implémentation en Ruby, je ne sais pas si ça aurait été subtile si personne n'avait entendu parler de ce langage.


Certains parlent de la portabilité, Java n'est pas si portable que ça.

Pour Java SE,

Sur une même plateforme, il y a des problèmes de compatibilité entre différente spécifications de Java SE (d'une inférieur à supérieur, il y a souvent une extension des méthodes (par exemple apparition d'une surcharge avec un paramètre long dans Java 6 et absent dans JDK 1.4 => impossibilité d'exécuter le code compilé avec 6 sur le 1.4)
Sur une même plateforme, utilisation de méthode qui ont disparu avec des versions plus récentes (souvent notés depreciated)

Sur des plateformes différentes. Certains ont parlé de Linux et de Windows, mais tous les deux utilisent en général le JDK de Sun. Il y a d'autres JDK comme le JDK d'IBM qui fonctionne sur z/OS (l'utilisation des fichiers est bien plus problématique dans ce cas). L'utilisation d'un même binaire entre le JDK de sun et le JDK d'IBM peut poser pas mal de soucis.


Avec Java EE,

On utilise Java EE avec un serveur d'application et changer de serveurs d'applications peut être un sacré bordel.

Il peut y avoir des différences liées à l'environnement dans lequel s'exécute l'application : une application déployée sur un seul serveur d'application et une application répartie sur 5 serveurs d'applications et un serveur Web peut donner des comportements totalement différents (par exemple si certaines parties nécessites des mutex qui ne seront évidemment pas distribués entre les machines). Autres exemples s'il est nécessaire que des données soient partagés entre les machines (caches distribués).

Il peut y avoir l'utilisation de solution non portable (utilisation d'un scheduler lié au serveur d'application)

Il peut y avoir des différences au niveau de l'implémentation des Stub et des Tie des EJB (utilisation d'ejbdeploy sous WAS et souvent d'une solution à base de xdocklet sous Jboss) : les conteneur EJB des différents serveurs d'applications ne tournent pas forcement de la même manière.

Certaines bibliothèques nécessitent des dépendances différentes suivant les serveurs d'applications (par exemple IceFaces)

Millie pour sûr tu as raison.
Mais quand on parle de la portabilité de java c'est surtout au niveau d'implantation sur tout type de support.
Ce qui permet de répondre à Alanis, Java n'est pas utiliser que sur des systèmes d'exploitation Mac, Linux Windows etc... Mais aussi sur des produits direct; Robots, appareils mobile etc...

une incompatibilite entre version c'est tres tres rare un copain a eut des pb avec SwingUtilies qui a change de package je crois dans la 1.6
mais c'est tout ...
si vous voulez voir des pures incompatibilite regardez le .NET

Citation : daedric

une incompatibilite entre version c'est tres tres rare un copain a eut des pb avec SwingUtilies qui a change de package je crois dans la 1.6
mais c'est tout ...
si vous voulez voir des pures incompatibilite regardez le .NET

Alors il y a eu relativement de la chance. Tous les problèmes cités ci dessus, je les ai tous eu (et souvent plus d'une fois).

Mais si on se contente de passer d'un Java sur une même plateforme avec le même type de JVM (par exemple de Sun) d'une version à une autre. Les risques se limitent. Par contre, quand on utilise le même binaire avec des JVM différentes, des environnements différents ou lorsque l'on migre vers d'autres serveurs d'applications pour du Java EE, ça se passe jamais sans douleur.

Citation : Sulimo

<position valeur="justifie">En plus je n'utilise pas d'IDE ! J'utilise le bloc note (notepad ++).

Pas d'IDE pour J2EE? J'ai beaucoup de mal à me l'imaginer. Ca veut dire que tous les taglibs, xml de configuration des applications, définitions de beans et paramétrages du serveur java tu te les tapes à la paluche? Tu dois perdre un temps dingue, ou alors tu arrives à tout faire fonctionner dès le premier coup et t'es vraiment un surdoué...