Java est loin d'être mort, je développe quotidiennement des applis pour serveur Web (Servlet ou jsp) qui tappe dans des bases de données. Dans ce cadre d'utilisation ce langage est trés bien adapté. PHP peut aussi servir dans ce contexte, après c'est une question de choix personnel et du matériel qu'on utilise.
-Comme on utilise les librairies standard sun, c'est trés portable (enfin entre solaris, linux et windows, les 3 OS supporté par sun, ça marcherait peut être sous des JDK sous d'autres OS mais on s'en fout, il faut être honnête).
-Il y a bcp de librairies standard, on a pas besoin de reinventer la roue, et on gagne bcp de temps en développement.
-Comme on fait toujours le même type d'applis, on a un squelette déjà fait ce qui nous évite de repartir de zéro à chaque fois.
-On ne se fait pas chier comme en C a gérer la mémoire, ça fait gagner bcp de temps aussi. Bon le fait aussi de faire moins de boulot en aval (programmation) fait que la jvm sera plus chargée en amont.
-avec le jdbc, un accés à une base de donnée c'est "finger in the noize", et tu peux standardiser ton code pour n'importe quelle type de base, il suffit de changer le driver.
Non java est trés agréable à programmer, tu fais trés rapidement du code sale portable et qui reste lisible et maintenable. Surtout la jvm permet d'avoir une certaine stabilité, et en truffant le code de try, catch, tu es sur d'avoir une appli qui ne plantera pas (c'est pas pour autant qu'elle va reagir comme on le voulait :-).
Je compare Java a des lego, c'est facile à monter, c'est amusant, c'est robuste, mais une voiture en lego ne sera pas trés aérodynamique (je parle des briques classiques, pas avec des piéces moulées profilées des nouvelles boîtes).
Le C++ serait un mécano, en théorie plus puissant, mais les boulons se deserent tout le temps. Et tu n'obtiens jamais un montage robuste (c'est pour ça que c'est chiant).
Mais Java reste lent quand même, on ne peut pas comparer une émulation software avec du hardware.
On a quand même des problèmes de perfs de temps en temps.
Mais pour une entreprise ce n'est pas trop grave, ça coute moins cher d'acheter un gros serveur que de developper du code C ou C++ que personne n'arrivera à maintenir et qui sera plus fragile.
Par contre à titre personnel, ça me fait un peu chier de devoir me contenter d'un jeu en 256x256 au lieu de l'avoir en 1024x768.
C'est comme UAE, sur mon duron 650, il arrive enfin a faire tourner des jeux amiga500 à la frame rate. C'est marrant, c'est nostalgique, mais je ça me gonfle de jouer à un jeu "récent" comme si le jeu avait 10 ans avec une machine a 10000FF. Déjà qu'on se plaint que les OS modernes sont gros et bouffeurs de ressources, si tu rajoute une couche java dessus.
Java est dans une niche, et il est trés bien adapté, vouloir le rendre universel serait une erreur. Personnellement, je prefere programmer en C sur mes petits programmes personnels (en général c'est plûtot du calcul math) parce que c'est plus simple.
Mais des qu'il faut faire "moulte" malloc et free, il vaut mieux passer à autre chose, on perd trop de temps à se prendre la tête sur un dépassement de pointeur, sans parler de faire une fonction de sortie propre alors qu'en Java le boulot est maché au détriment de la performance.
Quand a swing, et bien, ça devient vite lourd a programmer, mais ça c'est le problème de tout ihm moderne. Quand a sa rapidité, ben à part Jbuilder qui répond bien, je n'ai pas vu un seul prog java agréable à utiliser en ihm. ça répond pas au quart de tour, et ça devient enervant.
Les applets, c'est un autre problème, ie5.5(d'accord c'est du crosoft, mais dans la philo java, il faut faire des applets qui tournent sur le plus de navigateurs possible) est toujours en 1.0, donc ça reste limité. Mais c'est la solution la plus simple pour faire un programme java qui pourra être lancé sur 80% des ordis de la planéte sans rien connaître aux lignes de commandes et sans faire un .bat ou un .sh en fonction du système.
Il n'y a pas de solutions miracle, la ou sun a vraiment été trés con, c'est qu'ils ont crées un proc virtuels qui étaient un peu trop compliqué à créer dans la réalité. Parce que si on avait des procs bytecode java a 500mhz, le langage aurait pu servir de base solide a un vrai os "multimedia". Ou alors faire du code morphing sur un proc style "transmeta", mais comme il n'y a pas de vai os java, ça ne sera jamais fait (enfin pas tout de suite).
Le plus simple c'est d'utiliser l'OS et le langage adapté à une utilisation particulière et éviter de s'enfermer dans une solution unique, même si à titre personnele, il faut quand même se spécialiser un peu plus dans peu de langages si on veut évoluer et arrêter de butiner à droite ou à gauche sans rien faire de concret.
C'est un peu comme le tunning du systéme, a force de vouloir choisir on ne fait rien.
# Java ça reste lent, mais c'est simple comme les lego.
Posté par Anonyme . En réponse à la dépêche Décompresseur mpeg4 en Java. Évalué à 0.
-Comme on utilise les librairies standard sun, c'est trés portable (enfin entre solaris, linux et windows, les 3 OS supporté par sun, ça marcherait peut être sous des JDK sous d'autres OS mais on s'en fout, il faut être honnête).
-Il y a bcp de librairies standard, on a pas besoin de reinventer la roue, et on gagne bcp de temps en développement.
-Comme on fait toujours le même type d'applis, on a un squelette déjà fait ce qui nous évite de repartir de zéro à chaque fois.
-On ne se fait pas chier comme en C a gérer la mémoire, ça fait gagner bcp de temps aussi. Bon le fait aussi de faire moins de boulot en aval (programmation) fait que la jvm sera plus chargée en amont.
-avec le jdbc, un accés à une base de donnée c'est "finger in the noize", et tu peux standardiser ton code pour n'importe quelle type de base, il suffit de changer le driver.
Non java est trés agréable à programmer, tu fais trés rapidement du code sale portable et qui reste lisible et maintenable. Surtout la jvm permet d'avoir une certaine stabilité, et en truffant le code de try, catch, tu es sur d'avoir une appli qui ne plantera pas (c'est pas pour autant qu'elle va reagir comme on le voulait :-).
Je compare Java a des lego, c'est facile à monter, c'est amusant, c'est robuste, mais une voiture en lego ne sera pas trés aérodynamique (je parle des briques classiques, pas avec des piéces moulées profilées des nouvelles boîtes).
Le C++ serait un mécano, en théorie plus puissant, mais les boulons se deserent tout le temps. Et tu n'obtiens jamais un montage robuste (c'est pour ça que c'est chiant).
Mais Java reste lent quand même, on ne peut pas comparer une émulation software avec du hardware.
On a quand même des problèmes de perfs de temps en temps.
Mais pour une entreprise ce n'est pas trop grave, ça coute moins cher d'acheter un gros serveur que de developper du code C ou C++ que personne n'arrivera à maintenir et qui sera plus fragile.
Par contre à titre personnel, ça me fait un peu chier de devoir me contenter d'un jeu en 256x256 au lieu de l'avoir en 1024x768.
C'est comme UAE, sur mon duron 650, il arrive enfin a faire tourner des jeux amiga500 à la frame rate. C'est marrant, c'est nostalgique, mais je ça me gonfle de jouer à un jeu "récent" comme si le jeu avait 10 ans avec une machine a 10000FF. Déjà qu'on se plaint que les OS modernes sont gros et bouffeurs de ressources, si tu rajoute une couche java dessus.
Java est dans une niche, et il est trés bien adapté, vouloir le rendre universel serait une erreur. Personnellement, je prefere programmer en C sur mes petits programmes personnels (en général c'est plûtot du calcul math) parce que c'est plus simple.
Mais des qu'il faut faire "moulte" malloc et free, il vaut mieux passer à autre chose, on perd trop de temps à se prendre la tête sur un dépassement de pointeur, sans parler de faire une fonction de sortie propre alors qu'en Java le boulot est maché au détriment de la performance.
Quand a swing, et bien, ça devient vite lourd a programmer, mais ça c'est le problème de tout ihm moderne. Quand a sa rapidité, ben à part Jbuilder qui répond bien, je n'ai pas vu un seul prog java agréable à utiliser en ihm. ça répond pas au quart de tour, et ça devient enervant.
Les applets, c'est un autre problème, ie5.5(d'accord c'est du crosoft, mais dans la philo java, il faut faire des applets qui tournent sur le plus de navigateurs possible) est toujours en 1.0, donc ça reste limité. Mais c'est la solution la plus simple pour faire un programme java qui pourra être lancé sur 80% des ordis de la planéte sans rien connaître aux lignes de commandes et sans faire un .bat ou un .sh en fonction du système.
Il n'y a pas de solutions miracle, la ou sun a vraiment été trés con, c'est qu'ils ont crées un proc virtuels qui étaient un peu trop compliqué à créer dans la réalité. Parce que si on avait des procs bytecode java a 500mhz, le langage aurait pu servir de base solide a un vrai os "multimedia". Ou alors faire du code morphing sur un proc style "transmeta", mais comme il n'y a pas de vai os java, ça ne sera jamais fait (enfin pas tout de suite).
Le plus simple c'est d'utiliser l'OS et le langage adapté à une utilisation particulière et éviter de s'enfermer dans une solution unique, même si à titre personnele, il faut quand même se spécialiser un peu plus dans peu de langages si on veut évoluer et arrêter de butiner à droite ou à gauche sans rien faire de concret.
C'est un peu comme le tunning du systéme, a force de vouloir choisir on ne fait rien.
DARKLEON